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

[James Strachan]

----- Original Message -----
From: "Jason Hunter" <jhunter at collab.net>
> > 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...

No! You missed the most vital step. Interfaces come with no instance data
baggage - it totally seperates implementation from interface. By insisting
on having a default implementation of Element, Attribute et al that are the
only base class possible for any derivation, you inhibit derivations with
unnecessary instance data. XML trees can often be massive with huge numbers
of instances of Element & Attribute and this simple fact alone is enough to
convince me that I need an 'abstract base class with no instance data' from
which to make facades, proxies, lazily constructed branches and very memory
efficent schema-based implementations.

e.g. today right now the sizes of the Element and Attribute are:

Element has 7 instance variables right now
Attribute has 3 instance variables right now, maybe 4 soon (parent to handle
the sharing / mutation issue).

For a specific schema / DTD Element and Attribute derivations could be code
generated to use *much* less instance data. for example the following XML:-

    <foo bar="1">hello</foo>

could use a FooElement with 2 instance variables and a BarAttribute which
only require 1 String instance.
This is such a huge order of magnitue difference. From the initial
performance testing I did I was quite shocked by the difference in
performance between the singly linked and doubly linked tree implementation
in construction - and thats just a difference of 1 less instance variable in
Attribute and Element.

LinkedList does not inherit from ArrayList. Why? Do you think it should and
that the List interface be scrapped in the JDK as it causes confusion? It
would make things 'simpler' wouldn't it?

    List list = new List()

is much easier than

    List list = ArrayList();


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

I disagree. As it happens the first cut of "the project formerly known as
JDOM+" used abstract base classes which support exactly this - that a class
must be foremost a 'JDOM-like' class. So I'm agreeing with you on this but
disagreeing with why you think interfaces are useful. Interfaces are useful
because the implementation is totally open ended rather than having to use
the bagagge that you decide upfront.

> The price of that interface
> architecture is we can no longer declare final methods like equals().

I don't see that as a big loss.

> Also, we'll have this IElement interface that no one uses because they
> say new Element(),

Only someone who's doing custom building of an XML tree is affected.
Readers, parsers, outputters are not affected at all.

Incidentally I can not find one line of code in any of the samples in CVS do
a "new Element()". When I turned Element, Attribute et al all into abstract
classes, all of the samples compiled and ran correctly without modification.

> and thus an alternate implementation couldn't really
> just "plug-in" anyway unless people took care to say IElement and
> IAttribute.

Yes I'm arguing for an 'interface' of some kind, say Element and a default
implementation of some kind, say DefaultElement.
(whatever you want to call them).

The folks who do

    Element element = new Element( "foo" );

would choose an implementation or use a factory

    // I don't want to use a factory here as its complicated
    // I want an easy life which is a good choice

    Element element = new DefaultElement( "foo" );

like they do with collections

    List list = new ArrayList();
    List list2 = new LinkedList();

or they could abstract this from their code, to make their code more loosely
coupled and configurable..

    // I want to use a factory here as I'm not sure of the
    // usage patterns for the tree I'm building are
    // so I'll let others configure me with a factory

    Element element = factory.createElement( "foo" );

> If you see other advantages, speak up.

The advantages are a plethora of implementation choices for developers
without taking a big hit in memory usage. Here's a couple of examples

* code generate Element and Attribute implementations from a schema that
both enforce the schema and have minimal instance data to massively conserve
data (e.g. 1 String for attributes and PCDATA elements

* allow dual tree implementations

* allow nodes and branches to be reused (caching) for use in multiple
documents by developers who know what they are doing

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

What like?

> 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 can tell ;-)

Using a factory is totally optional. There's nothing to stop Brett or anyone
else using a 'default standard JDOM' implementation of Element and Attribute
throughout his entire code base. e.g.

    Element element = new DefaultElement( "foo" );

You don't have to use a factory when using List and ArrayList and
LinkedList. Its your choice. I'm advocating a similar stance in JDOM.

I'm not allowed to implement an Element or Attribute without inheriting all
the instance data Brett & you decide should be there. So your stance is the
one restricting choice, not mine.

> I want to
> 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.

I'm sure JDOM suits your needs best. We all have different needs and are all
prepared to make different tradeoffs. Unfortunately JDOM doesn't suit mine
though - but a small-ish change and it would! :-(

I don't see that having an 'interface' and a default implementation - i.e. 2
class names - for the tree nodes is such a huge level of complexity. Only
the 'advanced' 20 users need to concern themselves with factories. The 80
can happily carry on using specific implementations - we just have 2 names.

Element element = new DefaultElement("foo");

or

IElement element = new Element("foo");

or

Element element = new ElementImpl("foo");

or whatever.


<James/>


James Strachan
=============
email: james at metastuff.com
web: http://www.metastuff.com



If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited. Views expressed are those of
the author and do not necessarily represent those of Citria Limited.