[jdom-interest] Interface-based JDOM

[Tom Bradford]

Brett McLaughlin wrote:
> 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.

If JDOM were C++, I'd agree that subclassing is a valid approach.  But
forcing subclassing as the only route for customization in Java is very
restrictive, especially when you've already got your own classes (for
example, a DOM implementation) that implements most of the custom
functionality for you.  Multiple inheritence is not an option, writing
an adapter that essentially proxies method calls is a kludge, and you're
left with interfaces.

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

I'm not saying that a custom implementation wouldn't subclass or utilize
existing JDOM classes...  If we (dbXML) were to have a custom
implementation of JDOM, we'd probably only write an Element and Document
class, and leave the rest as is.  The point is, contract based
programming allows the implementor to say "Who cares how it's
implemented."

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

I'm looking at JDOM as an interface for developers, not necessarily as
the only interface.  Right now, they can use SAX and DOM to manage
Documents in our data store.  The underlying representation is not
textual XML, it's a traversable, tokenized tree.  Meaning that once the
document has found its way into the data store, it's never parsed again
(internally), so we can't depend on building the Document up from that
point because it's already built.  The DOM classes we've written plow
into a bytestream to begin decompressing requested branches of the
tree.  We'd need the Element and Document classes to perform on the fly
decompression.  

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

I have enough code to write and maintain, I'd like to avoid more.

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

I didn't mean it literally.  And besides, I skipped college, so I missed
out on the finer points of code editing :)

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

I'm not really arguing... Yet.  And you haven't seen a dictator until
you've seen me in action.

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

We'll see..  In the mean time, I'm putting our JDOM interests in stasis
until I've seen how it progresses and whether it ultimately seems like a
good fit for our architecture.  It's not a priority for us at the
present time, mainly some exploratory.

-- Tom