No subject

thrown (JDOMException, in our case). I noticed that JDOMException currently has a an 'initCause' method and this should
be used instead of throwing an IOException, which is directly tied to the implementation. JDOMException should also
provide a constructor that takes an embedded exception, to facilitate that pattern.

=> textBuffer is now private
Well, we overriden flushCharacters() to, when needed, suppress all the empty (blanks) elements found in such a document:
     <tag>
       <tag2>mydata</tag2>
     ...
Because of that formating, there is some undesired text between <tag> & <tag2>, which is ignored by most of XML
applications. I know that it is an old debate (I remember talks with Eliot and Denis), but we should keep a way to do
that, if some people want to.
I also have a pb with createContentHandler() , which is also now private. As I'm using my own SaxHandler, this is
weird..


Nevertheless, I can deal with these issues by providing my own JDOM build (making protected things that are private). My
only real concern is with these new IOException, because I already have some customers who use JDOM in production and
they cannot change their code.


For a Beta 9 perspective, I still have 2 old requests:

=> Having a common JDOMNode, for anything that can be put into a content list. I know that this is a very old request
that led to many threads in that forum. But, honnestly, I don't see why it is a problem. It just prevents from passing
non typed Object to methods and replace ugly (and non-performing) instanceof by simple tests and switch.

=> Having ctor & add() method that bypass the checks
As we save our documents in a database, we are sure that they are valid. Moreover, the SAX parser already does some
tests that do not need to be replicated in JDOM.
I did my own implementation of that and noticed a performance enhancement of 20%. Moreover, we are also generating java
code that build a JDOM, and the performance improvement is greater that 200%!!
I would really appreciate to see that capability as a standard, instead of having to do it myself...


For 1.0

Well, we really need to have a stable 1.0 quickly, since the Betas are now living for years... As API details constantly
changing in a way that is not compatible, this really lead to development & deployment problems.
For example, IBM is delivering an old JDOM release with WebSphere 4 & 5, and it is installed as a shared library. Well,
if your application is using a newer JDOM release (and API), you have to first remove it from WebSphere, else it crashes
your app. Fortunatly, WebSphere itself does'nt use JDOM and removing it is safe, as long as no other J2EE applications
rely on it. But you have to tell your customer to do that, before running the app.
Worse than that, JRun is also bundled with an old JDOM and internally use it. As a consequence, any application using a
newer JDOM crashes, and cannot run on that web application server!

Please, as JDOM seems to be adopted as a standard, froze it and then enhance it, while making it compatible with older
releases.

Thanks,

Phil.