[jdom-interest] (no subject)

[phil at triloggroup.com]

>>>As much as possible we've tried to deprecate public methods so you have a beta cycle in which to migrate<<<
This is not only a pb of deprecated methods, but some architectural points. Let me take some examples that currently had
a cost for us:
* getRootElement() no longer return null but throws an exception
* getText() return a Text object instead of a String
* IOException are being to be thrown since Beta 9 instead of only JDOM exception.
I agree that some of these changes were necessary, but honnestly changing method names right now (while the product is
widely used) is really a bad choice and is frustating the community. Look at the current API available, like JDK,
WIN32... How many methods can be better named? Do you want to see Sun changing these and breaking your current code?

>>> You'd rather we ship 1.0 and then break things in 1.1?  That's no good. We're going to get the API right for 1.0 so
we don't have to break
anything later<<<
I think the pb come from the lack of 2 things:
* A complete specification
Still the beginning, it is always stated "coming soon" in the dedicated web page. How can we agree that the product
matches a set of requirements if these requirements are not specified? What is the right API you're talking about?
"Right" means having a reference.
* According to the spec, some deadlines and milestones.
This is the only way to get a final product, ready for production. Things can always evolve, but it should be frozen
from time to time and people should accept that it may be not as complete as they expect. It will be enhanced with the
next major release. That's the basis of project management.

Think that people are using the library, are sharing things, doing QA... Think about the cost of that, and you'll have
an idea of our pain using JDOM.

Now that JDOM is 3 years old, when can we expect to have a frozen set of functionalities and 100% upward compatible new
release?
Please, we need that information.

Phil.