[jdom-interest] Opinion Poll: - JDOM2 and minimum-required Java - Java5 or Java6

[Rolf]

Hi all.

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 
utility class
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 
harness. http://java.net/jira/browse/SJSXP-38
6. Java5 has a major bug in org.xml.sax. 
https://issues.apache.org/bugzilla/show_bug.cgi?id=38316 and 
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, 
I think.

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: 
http://hunterhacker.github.com/jdom/jdom2/performanceJDK.html

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 
now...
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 
JDKs.

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.

Rolf

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
> implementation.
>
> 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
> maintained.
>
> 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).
>
> Rolf
>
>