[jdom-interest] (no subject)

[phil at triloggroup.com]

> That's a huge loss. Do you realize how much change that is to the users? I
> know you think JDOM is beta, and huge changes are ok until JDOM is 1.0 (3
> years after the original start). But you know what, at some point its not.
> You're just alienating users who really liked JDOM in the beginning,
> thought it was a great replacement for DOM, and chose to use it for their
> apps. Now you telling them to change in very significant way.

I completly agree with that view.
The introduction of the new interfaces does'nt seem to change the code, while the methods renaming is a huge change that
breaks exiting code.

As Vadim said, we are part of the early JDOM adopters. We trust JDOM and try to promote it to our customers. Most of
them already developped code that uses JDOM, based upon our framework. So, when a new incompatible JDOM is to be
released, what should we do? Stay with the old version or move to the new one?
This is beyond annoyance, but really weird!
I noticed that each time a new Beta is to be released, we have to do significant changes to our code. This is not the
definition of a beta release, where things should be improved and corrected, but not changed. Especially when the beta
step is 10!! Else, call it JDOM 0.9x, but not 1.0.

Jason, here's what you wrote last january:
> It's widely used, and we really should have called it 1.0 before now.
> There's several people who volunteered to help push to 1.0, so we'll do
> that as soon as we get CVS.
So, how can you let people doing such changes to CVS, and not waiting for 1.1, 2.0 or later?
Renaming methods is not something absolutely necessary because it does'nt correct anything, just breaks existing code.

Finally, I suggest to add a static field to JDOM that gives the current API version. A specific application can then
check it and find if it can run or not. As JDOM is now distributed with many products (WebSphere, JBuilder...), we
should be able to know which release we are running. This is particularily problematic with Web App Servers, where JDOM
is systematically installed in the a shared directory.

Phil.