[jdom-interest] Next JDOM evolution

[Jason Hunter]

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

Here's the text from the CHANGES.txt file from b7 to b8...

REMOVED CLASSES
---------------
None.

REMOVED METHODS
---------------
Removed the methods deprecated in beta7.

DEPRECATED METHODS
------------------
Deprecated the DOMBuilder.build() methods that build from a File, URL,
or
InputStream.  This helps people understand those methods are for testing
only.
DOMBuilder.build(org.w3c.dom.Document) and such are still undeprecated.


Beta7 to Beta8 was a big improvement, but you don't see a whole lot of
churn in backward compatability.  We keep the option open to break
compatability, but we don't churn needlessly.  We also deprecate in Beta
N before removal in Beta N+1, so if you're upgrading beta by beta you
won't have problems and will have plenty of time to adjust your method
calls.

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

It has the word "Beta" on it.  The download page gives all kind of
warnings.

-jh-