[jdom-interest] Java 5 planning

[Michael Kay]

> Based on discussions earlier, it appears that XPath may be a 
> real problem with Generics. The 'right thing' for XPath to do 
> depends on Jaxen, and, since that is not 'generified' we are 
> stuck. The reason Jaxen is not generified is pretty obvious, 
> because it is a whole lot more complicated to impose generics 
> on a method call like Xpath.newInstance("//@*")....

Also, please don't forget my comments about XPath 2.0. If you're revising
JDOM for Java5, it's surely foolish to do that without thinking about XPath
2.0, with its much richer set of possible return types (and parameter
types). Otherwise you'll have another discontinuity some time over the next
12-18 months.

One approach to doing that is XQJ (JSR 225,
http://jcp.org/en/jsr/detail?id=225) which has just gone out on final
ballot. That's a pretty complex approach, which doesn't fit the JDOM style
very well. However, there's a lot that you can do to make XPath more usable
from Java 5, for example:

(a) introducing a Node class or interface

(b) making a compiled XPath expression Iterable

My own attempt at an XPath 2.0 interface, which also handles XSLT and
XQuery, is s9api, 

http://www.saxonica.com/documentation/javadoc/net/sf/saxon/s9api/package-sum
mary.html

Michael Kay
http://www.saxonica.com/