[jdom-interest] Interface-based JDOM

[Brett McLaughlin]

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

Ahh... so now it becomes clearer. What you are wanting to do is not
write a custom implementation of JDOM, but write an implementation of
JDOM that extends something you already have. Your choice of a DOM
implementation is very telling. We explicitly prevent the JDOM codebase
from implementing DOM, even though newbies occasionally ask for it.
That's because JDOM is intended to solve many of DOM's problems, not
provide some sort of thin layer over DOM. So by definition, we think
what you are wanting to do is a bad idea. That makes me even more solid
on not wanting interfaces ;-) You can't have JDOM and DOM in the same
heap of code and expect to get benefit from JDOM, so your entire point
is moot. If for some reason you want the functionality of JDOM but
insist on using DOM underneath, you're on your own ... sorry, but the
good of the many...

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

Builders ... builders ... builders... using builders, you can have it
invisibly use your custom sub-classes, and never worry about it. To
invisibly use an alternate implementation through
interfaces/implementations, you /would/ have to use factories, which is
back to my original point. The contaact you refers to has to be upheld
somewhere, and the factories in this case would have to do that work.
Otherwise you're doing

Document document = new MyDocument;

and in that case, subclasses or innerfaces don't matter; you're
specifying exactly what you want instantiated. It's only in

Document document = factory.newDocument();

that implementation becomes invisible, and we're against that
factory-style approach.

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

Which still doesn't tell me why an implementation works, when a subclass
won't. The only reason is the dual-inheritance thing, which breaks what
JDOM is for anyway (to avoid DOM, among other things, not to work with
it also).

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

Now I'm getting giggly... ;-)

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

Fair enough; I hope you'll at least keep lurking ;-)

-Brett

> 
> -- Tom