[jdom-interest] Interfaces

[Tom Bradford]

Jason Hunter wrote:
> > Are there any plans to break the JDOM classes into separate interfaces
> > and impl classes?
> 
> No, the price is too high.  With interfaces everything becomes a
> factory, elements have to be "imported" into new documents instead of
> just added, features like long-term serialization cannot be guaranteed,
> and the list goes on.

I don't understand how the price is high.  If you create a set of
interfaces like IElement, IAttribute, INamespace, how would this keep
anybody from just creating an Element that happens to implement
IElement?  The key to interoperable implementations in Java is
interfaces.  It seems pretty silly to have to do a complete override of
every method in the JDOM classes when simply implementing an interface
will suffice, especially when I can create a dual-interface set of
DOM/JDOM classes.

The dbXML implementation of IElement might be CompressedElement, but so
long as people are developing against the interfaces, and internally
your classes are refering to those Interfaces, it shouldn't matter how
its implemented.  If you specify some rigid interoperability guidelines
there shouldn't be a problem with adding an "Element" directly as a
child of a "CompressedElement".  

> > The reason that I ask this is because at some point
> > in the future, we may want to provide JDOM support in dbXML.  The only
> > clean way to create a compatible JDOM implementation while utilizing
> > dbXML's compressed DOM would be to implement against interfaces.
> 
> Please expand on what you're trying to do.

We were considering exposing a jdom interface to our XML database so
that you can create an incrementally (lazy) traversed JDOM tree directly
against our compressed bytestream.  To do it, we need to avoid having to
convert to/from SAX or DOM because the serialization steps pose a
possible scalability problem.

-- 
Tom Bradford
Chief Software Architect
The dbXML Group, L.L.C.
http://www.dbxmlgroup.com