[jdom-interest] Announce: JDOMPlus a flexible XML framework for Java

[Jason Hunter]

> Though from Bretts responses such as...
> 
> I think its pretty clear that interfaces, factories, multiple tree
> implementations ('dual' trees), read only & reusable branches and 
> the like are not going to make it into JDOM. Period. 

I don't agree.  I think read-only trees have their place.  However, I
lean toward having them implemented the same way Collections do, with
facade classes.  

I also remain open minded about some interface use.  But here's how I
see it.  With the interface design (the one that doesn't depend on
factories for every object creation) the only advantage interfaces offer
that I can't replicate with base classes is support for implementing the
JDOM API in a class that wasn't designed foremost as a JDOM class, and
that sounds like a questionable design.  The price of that interface
architecture is we can no longer declare final methods like equals(). 
Also, we'll have this IElement interface that no one uses because they
say new Element(), and thus an alternate implementation couldn't really
just "plug-in" anyway unless people took care to say IElement and
IAttribute.  If you see other advantages, speak up.

Now, the other interface model (where factories are used for all object
creation) has its own set of problems that people who've used DOM are
familiar with.

As for Brett, he's suffered more with DOM than I have, so he's extra
bitter about what factory-style interfaces make you do.  I try to keep
an open mind, but so far I'm confident the current JDOM design is best,
knowing the API as well as I do and taking all aspects into account.

-jh-