[jdom-interest] Java 5 planning

[Mattias Jiderhamn]

B.t.w. I just tried replacing the JAR on one of our test servers, 
restarting the application *without* recompiling.
So far it seems to work fine; building from file, creating with code, 
XPath, XSLT with JDOMSource/JDOMResult but no Filters.
(Especially note the XPath.selectNodes() - the explicit cast from 
List<?> isn't needed until recompilation)

 /MJ


Jason Hunter wrote (2008-03-04 22:39):
> 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-
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>