[jdom-interest] Interface-based JDOM

[Brett McLaughlin]

Tom Bradford wrote:
> 
> 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

I completely agree - one reason a future goal of JDOM is to allow this
lazy instantiation of actual document constructs. But I don't agree that
the neccessary leap given that concession is an interface-based design.
The issue of how things are stored is one that needs to be made at
build-time (in a builder like SAXBuilder, not in code build), not at
process time. In other words, when you build a document you would
specify those things. That means supplying arguments and the like to
SAXBuilder, which doesn't require interfaces to accomplish. I'm not
saying that using interfaces isn't an approach, I'm saying it's not the
/only/ workable approach.

So, yes, we do need some type of deferred reader/builder. But no, that
doesn't require interfaces. Subclasses of JDOM, perhaps, but not
neccessarily interfaces. And I would argue that subclassing is a better
solution in this particular case.

> 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.

Sublassing provides all of these things. And subclassing, over
interfaces, allows for imports of elements/constructs between documents
of differing implementations, it doesn't give us the JAXP problem (we
don't need JAXP because of our non-interface based design, among other
things), and doesn't promote the poor practice of having users directly
instantiate implementation classes. Looking at almost all DOM programs,
you will inevitably see instantations of classes like
org.apache.xerces.dom.DocumentImpl and the like, which is of course
terrible. This would not exist with JDOM. And using simple flags to
SAXBuilder, or a "DeferredBuilder", you would get the same ability to
use different subclasses of JDOM without ever needing to do this sort of
thing. At the same time, you don't lose any of the convenience that you
now have without interfaces.

> 
> 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.

Transparently? Not without a JAXP-like device, and not without a much
more complex code-base. This is from experience, keep in mind. When I
wrote the initial JDOM implementation, and Jason and I reviewed it with
James Davidson at Sun, it was completely interface-based. And
performance was terrible. Now this isn't a bunch of novice programmers
who don't know how to code; this is two authors, experienced developers,
spec leads, etc., and it was a major performance and transparancy (or
lack thereof) issue. And we threw it out. Additionally, the idea of
implementations consuming other implementations results in broken
functionality; your deferred tree craps out in many places, or loses any
advantage, because three levels down a non-deferred/lazy Element was
inserted, and you have to deal with that. So you either give up the gain
in any tree where mutation occurs, or deal with importing nodes and the
like.

> 
> 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.

Not true; you are thinking way out of the box on interfaces, but then
are taking a very limited view on subclassing. You're also missing the
purpose of builders, which are in place for just these sort of
performance enhancements. Consider building JDOM Documents that strip
all ignorable whitespace (upon request) from a document, or that remove
comments, or that replace entities with pure content with those entities
expanded representations. These are all things traditionally associated
with implementations, but that can easily be done in JDOM through the
builders and flags. That is where the power of JDOM for complex,
memory-consumptive documents lies; not a code redesign.

BTW, I do appreciate you not wanting to fork the code base.

> 
> 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.

That's incorrect - for one, those changes have been made, and there is
no need to introduce another wave of them. Second, those changes were
limited to certain methods. Common ones, yes, but not used except in
document interpretation, rather than in reading or writing. Interface
changes would touch every single piece of JDOM code, inside and out. And
if you are recommending to any programmer to do a find-and-replace in
code, I'm very disappointed :( Any author or teacher will plead with
students/readers not to do this sort of thing, because it is incredibly
error-prone.

> 
> 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.

As for this, I'll be blunt. I have no respect, or sympathy, for people
who send those mails and don't speak up on the list. Yes, it's hard to
get us to make a change, because we're pretty far along the design
process, and we have very specific goals. So if you want to stand up and
justify your case (which you are trying to do, and I completely
respect), that's great. But if you aren't willing to do that,
complaining about how dictatorial we are (word?) doesn't make me feel
bad in the least ;-) That said, you're obviously taking the correct
route, arguing your case.

Additionally, we have people at every talk we give (which is fairly
common lately) thanking us for moving away from interfaces; and these
people aren't apparantly sending you private mail ;-)

Tom, thanks for making a good argument. I think your premise of needing
more flexibility in JDOM is certainly valid. However, I don't agree with
the conclusion, that interfaces is the best solution. I think instead
the builders can be expanded (both class-wise and method-wise), and
you'll find more power and customization than you need in them. I, of
course, welcome replies and discussion.

-Brett



> 
> -- Tom