[jdom-interest] JDOM JSR

[Sven Behrens]

Hi,

philip.nelson at omniresources.com wrote:
> 
> > I would really like to know the design decisions for JDOM and their
> > reasons. Its just because its seems to be contrary to all I
> > have learned
> > and have experienced.
> 
> That statement implies that the only way to do it is with interfaces and
> factories??

Depends what you mean be "it". For example 
- Java Collection Classes: Yes, I think so.
- XML-API for Java: Just wanted to know why not. JDOM seems to have a
big acceptance.

And its not just factories but a lot of GOF-Patterns, that depend on
interfaces.

> These decisions were made a long time ago and *very* publically.  There was
> certainly dissent and a follow up discussion led to dom4j.  The whole thing
> is available in the list archives.

I noticed JDOM quite a while ago, but just started to evaluate it
(without doing any testing myself). I don't think list archives are the
appropriate place for the documentation of design decisions. (At least
the archive are searchable since a few days)

> If you can't live without factories and interfaces, you probably won't be
> happy with JDOM.  Myself, I appreciate every day being able to say
> 
> Element el = new Element("name");

For me it is OK to say:

Element el = new ElementDefaultImplWithAHandyName("name");
or
Element el = FastImplFactory.createElement("name");
or
Element el = MostMemoryEfficientImplFactory.createElement("name");

> 
> Later today I will send out the updated version of Ken Rune Hellend's
> JDOMFactory code which will allow you to say:
> 
>         //override toString for debugging
>         class superElement extends Element  {
>                 public String toString() {
>                         return "a subclass" + super.toString();
>                 }
>         }
>

OK, but if you need MostMemoryEfficientImpl: How can you get it? Don't
you have Element as a super class with all its memory consuming, useless
fields?

> 
>         SAXBuilder builder = new SAXBuilder();
>       //use an inner class to override the element factory with my
> SuperElement
>         builder.setFactory(new DefaultJDOMFactory()  {
>                 public Element element(String name) {
>                         return new superElement(name);
>                 }
>         });
> 
>         Document doc =  builder.build(new FileReader("afile.xml"));
> 
> Viola, easy subclassing.  This still doesn't make JDOM the perfect, most
> flexible api.  While experimenting with decorators, I would have liked an
> interface for each of the base JDOM types so I wouldn't have had an orphaned
> super class.  

I understand this drawback ...

> However, in a year+ of using JDOM myself, and about the same
> time answering questions for users, those use cases have been rare.  On the
> daily basis the concrete classes are exactly what I want.  You will have
> subclassing, decorating, implementation of new interfaces, ability to add a
> vistor, all available to you easily.  To me this is a good compromise.

... and I don't have your experience so I cannot judge about the
importance of that drawback.

But I still did not understand the drawback of an interface approach. I
guess I have to dive into the list archive.

Sven Behrens