[jdom-interest] Interface-based JDOM

[Tom Bradford]

Brett McLaughlin wrote:
> We're so far from even considering this, I just can't over-express it.
> No offense to you, personally, Tom, but you are substituting your
> preference and convenience over what is really a simple issue - we want
> concrete classes, and nobody has yet even put together much of a case
> against them.

Show me a Document with a million elements nested in eight different
levels and tell me that for any query, a processing client only needs to
drill into one path five levels down and I'll tell you that you need a
lazy DOM to process it efficiently and with minimal resource
consumption...  It's one thing to have a convenient set of classes to
deal with a document, it's another thing to have a set of classes that
creates an inconvience by chewing up incredible amounts of memory.  The
JDOM implementation, as it stands right now is very convenient, but
doesn't provide the necessary flexibility to allow for customization in
order to implement features like a lazy object model, an underlying
compression system, or anything for that matter.  

Using interfaces doesn't automatically mean that you need to use a
factory model for instantiation, and it doesn't mean that you have to
perform node importing.  If the interfaces are designed correctly and
guidelines are followed (for example, a custom implementation must be
able to consume JDOM classes in addition to its own), you get more
flexibility, the same performance, and the same convenience that you
previously had, but you also allow JDOM clients to use custom
implementations transparently.  

In looking at the code, I only found one place where a class was
directly accessing a field in another class, and only a couple of places
where a protected method was being called, so what value is there in not
providing interfaces?  It allows for compatible customization, and it
keeps people from having to break or fork off the JDOM code in order to
implement special features.  I don't want to fork your code base.  I'd
like to be able to develop a custom underlying implementation using your
foundation that will enable the scalability features we need to make
available in our server while still being totally compatible with any
JDOM client that gets thrown our way.  We can't do that by extending
classes.

Regarding the code that you'd break with the changes, it's no worse than
the code that will break when all of those deprecated methods are
removed before the final release.  Actually, it's less of a pain because
it would pretty much only require a find and replace where classes are
being instantiated.  Having to change method calls where mixed content
manipulation is concerned is far worse of a show stopper.

BTW, my initial email regarding interfaces generated a lot of private
responses, nearly all of them along the line of "We've been trying to
get them to do this for some time, but they're dead set against it." 
Obviously this is something that people have been asking for.  

-- Tom