[jdom-interest] Opinion Poll: - JDOM2 and minimum-required Java - Java5 or Java6
jdom at tuis.net
Wed Nov 16 22:39:46 PST 2011
I have been looking in to the implications of supporting Java5.
Here is a list of changes I have had to make to get the support in:
1. DescendantIterator uses ArrayDeque - easy fix.
2. Lots of places use Arrays.copyOf(...) - created a new ArrayCopy
utility class - an OK fix.
3. XMLConstants.W3C_XML_SCHEMA_NS_URI - does not exist in Java5 - easy
fix... hard-code it
4. XMLConstants.FEATURE_SECURE_PROCESSING missing
StAX has proven to be the real problem. Specifically, the stand-alone
(pre Java6) StAX library is only specified to have optional support for
the method I use to load up files. It's not a train-smash, there's an
alternative way.... I just have to change all the JUnit tests from
loading from a 'Source' to loading from a FileReader
I think, all being said and done, that the code will work in Java5. The
option of supporting Java6 officially, but having good instructions for
making everything work in Java5 is realistic.
Currently the instructions would be something like:
1. everything except StAX will work just fine.
If you want StAX, it comes in two parts, the official API, and an
The API is available in two places, either the official JSR at
http://sjsxp.java.net/#downloads or alternatively the xml-apis.jar which
is part of apache (and is part of the JDOM2 repository)
The reference implementation of StAX is available from
http://sjsxp.java.net/#downloads as well. You have to download and run a
single .class file SJSXP.class.
Alternatively, download the woodstox StAX implementation.
Conclusion, it all seems to be quite reasonable to make Java5 work. I
still am reluctant to make it officially supported. I think though with
some disciplined development the compatibility can be established, and
I don't particularly like having to re-create the java.util.Arrays
functionality, but its not a deal-breaker.
I think I will commit the code changes though, even if it is just to get
them 'on record' (and clear them out of my development environment so I
can do other things). Committing the code change is not intended to be
an endorsement of Java5 support though! It is a big commit.
I think that's enough investigation to make a more informed decision
about Java5 support. Currently using Java5 about 250 test cases are
failing, but those I believe will pass again if/when I change the tests
to use a FileReader for StAX (instead of the unsupported Source).
On 15/11/2011 11:57 PM, Rolf wrote:
> November 18th is coming up pretty soon.
> Please speak up if you have any comments, suggestions, or concerns.
> On 31/10/2011 9:26 AM, Rolf Lear wrote:
>> I should add a time-line here.
>> I think I will sit on this for a couple of weeks... Say Friday the 18th -
>> three weeks.
>> At that point I will summarize all the responses... and between now and
>> then I will also see if I can come up with a more detailed list of
>> what the
>> implications for supporting Java5 are...
>> Then we can make a more informed decision.
>> A third option would be to only officially support Java6, but also put
>> together a document on how to make it work with Java5.
>> On Sun, 30 Oct 2011 21:56:44 -0400, Rolf<jdom at tuis.net> wrote:
>>> Hi all.
>>> So, as a poll:
>>> * Does anyone have a realistic need to run a future JDOM2 on Java5?
>>> * If so, could you add additional jars to your classpath just to make
>>> JDOM2 work?
>>> * Any comments, suggestions.
>>> Currently I feel that it is reasonable to set Java6 as a minumum and not
>>> even bother trying to think about Java5 issues... anyone disagree?
>>> To control your jdom-interest membership:
> To control your jdom-interest membership:
More information about the jdom-interest