atom feed17 messages in org.jdom.jdom-interestRE: [jdom-interest] Java 5 planning
FromSent OnAttachments
Jason HunterMar 4, 2008 1:39 pm 
Victor ToniMar 4, 2008 2:55 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:36 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:04 am 
Jason HunterMar 8, 2008 12:43 am 
Michael KayMar 8, 2008 1:58 am 
Jason HunterMar 8, 2008 2:49 am 
Michael KayMar 8, 2008 9:49 am 
Timothy MarcMar 8, 2008 12:26 pm 
Mattias JiderhamnMar 12, 2008 2:03 am 
Tatu SalorantaMar 12, 2008 9:41 am 
Subject:RE: [jdom-interest] Java 5 planning
From:Michael Kay (
Date:Mar 5, 2008 1:36:03 am

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, 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, mary.html