atom feed17 messages in org.jdom.jdom-interestRe: [jdom-interest] Java 5 planning
FromSent OnAttachments
Jason HunterMar 4, 2008 1:38 pm 
Victor ToniMar 4, 2008 2:54 pm 
RolfMar 4, 2008 5:58 pm 
Mattias JiderhamnMar 4, 2008 11:38 pm 
Mattias JiderhamnMar 4, 2008 11:49 pm 
Michael KayMar 5, 2008 1:35 am 
Joe BowbeerMar 5, 2008 5:05 am 
Victor ToniMar 5, 2008 5:24 am 
Michael KayMar 5, 2008 7:15 am 
Mattias JiderhamnMar 6, 2008 12:03 am 
Jason HunterMar 8, 2008 12:43 am 
Michael KayMar 8, 2008 1:57 am 
Jason HunterMar 8, 2008 2:48 am 
Michael KayMar 8, 2008 9:49 am 
Timothy MarcMar 8, 2008 12:25 pm 
Mattias JiderhamnMar 12, 2008 2:02 am 
Tatu SalorantaMar 12, 2008 9:41 am 
Subject:Re: [jdom-interest] Java 5 planning
From:Victor Toni (vict@ebuconnect.de)
Date:Mar 4, 2008 2:54:58 pm
List:org.jdom.jdom-interest

Personally I would like a three stage approach:

Stage 1: Make Java 5 the baseline and clean up code: - Currently there is code e.g. in org.jdom.adapters.JAXPDOMAdapter which has checks for JAXP versions. We could try to get rid off as many special cases as possible. - Convert all StringBuffer to StringBuilder. - Change internal collections to Generics - Clean up JavaDoc etc.

This should give a good starting point for further modifications.

Stage 2: Try to implement Generics for "visible" part of the API. There are some points needing to be clarified on how to apply Generics. Which interfaces/classes should be generified and how far e.g. what about Element<A extends Attribute> etc.

Stage 3: This stage should be used for more radical changes. One change I would like to see implemented would be transactional behavior. Currently collections e.g. of Attributes or Content are added until an error occurs leaving the model in an inconsistent state. These checks should happen before insertion. Collections of Content are somehow trivial to validate. Collections of Attribute are more complex.

Adding support for XPath 2.0 / replacing the current XPath implementation as suggested by Michael Kay. Maybe he could give some insight since he has written some great software on this matter.

Kindest regards, Victor

Jason Hunter wrote:

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 filled?

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?

-jh-