[jdom-interest] Opinion Poll: - JDOM2 and minimum-required Java - Java5 or Java6
jdom at tuis.net
Thu Nov 17 16:51:46 PST 2011
As a further update, I have completed the Java5 compatibility for the
code in it's current state.
In order to make the process work I had to make some decisions about
language levels and compile levels. I discovered that my personal coding
style has become fairly Java6 centric especially with respect to
@Override annotations. To make the code fully Java5 compatible I would
have to make code changes to almost every file. I thus took the decision
to maintain Java6 code style which implies the code has to be compiled
with Java6 JDK, but with the bytecode-target of Java5.
I have thus compiled JDOM2 with JDK6 to a JDK5-level byte-code, and then
run that bytecode through the JUnit test harness using Java5, 6, and 7
runtimes. All tests that are expected to pass did (I expect some
Jaxen-related tests to fail). Interestingly, the Jaxen tests that fail
in Java5 and 6 now pass in Java7 ... ;-)
The bottom line is that we can make JDOM2 run in Java5. To make it
compile with Java5 will take more work.
To re-iterate the changes I have had to make because they indicate the
sorts of limitations that we may run in to if we officially support Java5.
1. DescendantIterator uses ArrayDeque - fixed with ListIterator
2. Lots of places use Arrays.copyOf(...) - created a new ArrayCopy
3. XMLConstants.W3C_XML_SCHEMA_NS_URI - does not exist in Java5 -
hard-code it (but issue #38 comes to mind)
4. XMLConstants.FEATURE_SECURE_PROCESSING missing - had-coded it.
5. StAX does not support Source-based input in Java5, need to use
Streams or Readers only - replaced all Sources with Readers in the test
6. Java5 has a major bug in org.xml.sax.
https://issues.apache.org/jira/browse/XERCESJ-1261 which basically meant
that I had to write my own implementation of Attributes2 to get some
tests to run in the SAXHandler.
To make the code compile cleanly with Java5 would be a bigger exercise,
Now that I have done this work I think I am more comfortable saying we
can keep JDOM2 running on Java5 without too much effort, but, I still do
not want to say we officially support Java5. I think we can put together
a how-to on making it all work.
Since I was going through the code versions I thought it would be
interesting to run the performance benchmark against the various
combinations of code compliance and runtime version. I have put together
a web-page for it:
It is very interesting for a number of reasons:
1. Java5 is much slower.
2. I realized that I have been running the perf tests using Java7
runtime for a while... because XPath with Java7 is 3 more than twice as
fast as Java6... which makes my other performance page a little useless
3. There are other minor discrepancies that are interesting none-the-less.
In light of the current state of the code and the results I have, I
think I am comfortable that we can make a good decision about supported
Given that I set tomorrow as a decision deadline though, and that the
ramifications are not going to be massive from a design perspective, I
think I should extend the deadline a little further... perhaps next
Friday, the 25th.
On 17/11/2011 1:39 AM, Rolf wrote:
> 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).
More information about the jdom-interest