[jdom-interest] Last call: getChild/getChildren versusgetChildElement/getChildElements

Robin Rosenberg robin.rosenberg.lists at dewire.com
Mon Feb 9 16:19:55 PST 2004

On Monday 09 February 2004 23.57, Jason Hunter wrote:
> Robin Rosenberg wrote:
> > The name Parent/Child do not break anything, but having the method
> > addContent return Parent instead of Element as it did in b9 breaks a lot of my code. 
> > The fact that these methods returned the type Element was very convenient (and I
> > see no reason for them to return anything, other than as a convenience measure.
> > -- robin
> I've been contemplating the idea of, after shipping JDOM 1.0, following 
> it with a J2SE 1.5 enabled alternate version.  The J2SE 1.5 version 
> would take advantage of generics and "covariant return types".  This way 
> the Lists returned would be Lists of Element or Lists of Content. 
> Covariant return types are even cooler, and let you return a specific 
> subclass of the parent's return type.  So for example getParent() on 
> Text could return an Element even though the inherited getParent() only 
> says it returns a Parent.  There's lots of neat options.
My interest in JDOM is not so much experimentation in modeling, but getting work done. My
experimentation interest is in handling very large DOM's, although this is orthogonal to my
concerns with the Parent/Content interfaces it becomes a practical problem to have both
1.0 and b9 at the same time. The Parent/Content reminds me of design mistakes I've
made when I've forced internal mechanisms into the external interface. 

The b9 was good in that respect. It help med writing a lot of code which would
be ugly with other DOM's, simply because JDOM supported short code, and it couldn't me
automated either.

The 1.0 interface is far away into the ugly direction (for me). I gave some examples in a previous
post.  I have many instances of the same pattern. Inserting casting destroys the pattern making 
each case a few lines that has to be interpreted in detail to understand.

> What do people think?  Perhaps call it Generic JDOM.  :-)  If nothing 
> else, it'd be a great playground to learn about J2SE 1.5 features and 
> actually could be a textbook case for the use of covariant return types. 
>   I'm planning in my SD West conference talk in March to delve into 
> these possibilities.

I suspect I will go with 1.4 compatibility for a year after it's release for deployment reasons.

For one thing, I believe JDOM was good enough to use in production codee with b8, so I
really didn't expect a nice interface to change that much. Sure that's the risk you pay when using
beta code, although I'm more accustomed to encountering bugs and possibly redesigns necessary
to solve bugs, but usually not in the interfaces and rarely in beta code (alpha & pre-alpha, yes).

-- robin

More information about the jdom-interest mailing list