Java Mailing List Archive

Home » JDOM Projects »

[jdom-interest] Java 5 planning

Jason Hunter


Replies: Find Java Web Hosting

Author LoginPost Reply
First off, I want to thank Rolf for investing his time in exploring the
technical feasibility of a JDOM migration to a Java 5 baseline. A few
other people have explored the area in the past as well, and it feels
like (especially with JDOM 1.1 now finished) we can look at this in earnest.

What I'd like to do here is take a high level view and ask some
questions of our local Java 5 porting experts -- Rolf, Mattias, Victor,
Gregor, and any others with experience porting widely-adopted projects
to Java 5.

1. I think we can all agree the ideal scenario is to develop a drop-in
replacement, a new JAR which (so long as you're on Java 5+) would let
previously compiled code continue to work. This would let us continue
development as usual with a new release (call it 1.2 or 1.5 or 2.0)
simply having a higher Java version requirement. How far can we go down
the road of embracing Java 5 while still maintaining this?

2. A less ideal scenario would require any previously compiled code to
be recompiled against the new JAR, but wouldn't require any code
changes. This will cause some confusion and effort but to an acceptably
small amount. Rolf, you say your build requires a recompile and in 99%
of cases doesn't require code changes. Where are the gaps? Can they be

3. The fallback scenario is one where people will need to modify
existing code in order to use the new version. This will cause some
pain, and should we follow this path I think we should look at what
steps we can take to mitigate it. Automated upgrade scripts? A new
package, like org.jdom5, so people can choose to use the old version or
the new? Other possibilities?

4. Lastly, I'd like to hear from people on what specific advantages
they're looking for in an upgrade to a Java 5 baseline.

My answers:

I'll start with (4) because you need to know why before you know how. I
think people would most like to improve the return values of methods to
be more specific. For example, getChild() should return Element,
getChildren() should return List<Element>, text.getParent() should
return Element, doctype.getParent() should return Document, and so on.
Are there other "big ticket" items?

On (1) I suspect that without a source recompile we can't adjust the
method return types which is the core value of the upgrade.

On (2) from Rolf's README it looks like there are two areas likely to
require code changes based on his port: the Filter.filter() change and
the AttributeType enum. Both seem like things to do if you're already
requiring code changes but aren't things so valuable in and of
themselves that we should require people do a code change. Are there more?


To control your jdom-interest membership:
©2008 - Jax Systems, LLC, U.S.A.