[jdom-interest] Next JDOM evolution

[Dennis Sosnoski]

Phil's comments illustrate exactly why I made the remark quoted. If JDOM 
is going to continue to be promoted for use in real products I think the 
development team owes it to their users to (1) keep the API stable, 
possibly adding methods but not breaking code in new releases, and (2) 
support and provide fixes to the released version rather than just the 
then-current CVS version.

Otherwise, I feel JDOM should come with the same sort of disclaimer as 
the Sun Early Access releases of other JSRs - evaluation only, 
everything subject to change, not for use in production products, etc. 
As it is right now JDOM sometimes appears to be claiming the stature of 
a standard without accepting the responsibility that goes along with it.

  - Dennis

phil at triloggroup.com wrote:

>After reading the TODO.TXT delivered with beta 8, it appears that CDATA & Text will evolve. This is a good thing, as
>long as these classes appear in the same hierarchy and are not merged in one class. There are currently to much
>applications using JDOM and doing such a change breaks them! For example, both the introduction of Text and the
>exception thrown from Document.getRootElement() really cost us a lot. And we are'nt yet synchronized with our partners,
>who did'nt yet update their code and then are incompatible!
>
>Please, ensure that now the API won't change, just evolve by adding capabilties and enhance the overall performance. We
>really need to have a stable and released API. I'm really afraid when reading artticle like the one written by Denis
>Snososki:
>
>>>>...It also suffers from an API that's still changing every few months with a new beta release (the next version, beta
>>>>
>8, is in preparation as I write this). JDOM does offer a convenient way of building and accessing simple XML documents,
>but the lack of stability makes it difficult to justify for use in production projects....<<<
>
>By the way, it is always the same debate: building a true class hierarchy. Currently, the source code with lots of
>instanceof is really awful, while a base Node class with make it more ellegant with any penality. Moreover, checking a
>node type will be faster when using a getNodeType() like method, instead of using instanceof operator. With the
>introduction of Text class, it is very easy and we should leverage it.
>
>Thanks,
>Phil.
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>