I was watching the Mark Reinhold talk from JavaPolis 2006 on XML integration with Java, which is being considered for Java 7. If you’re interested in what this would mean (and if you use Java, you almost certainly use XML, so you should be), then I would definitely take the time to watch the video.

Mark lays out some of the crucial aspects of a Java / XML library with examples from some of the more popular libraries of the day, then lays out the highlights of a proposal to build support directly into Java through a combination of java.lang.XML (like String) and a companion package java.xml. Specifically, he talks about construction, type conversion, navigation, and streaming.

I know there will be cries that this is putting too much into the core Java libraries. But these days, given the ubiquity of XML and its intrinsic ties to so many of our most frequently used libraries (for better or worse), I think the inclusion of XML-handling in the library is worth considering. Mark is right that a lot of the XML apis suck. (He’s more polite, of course.) Maybe it is time to take everything we’ve learning from DOM, JDOM, dom4j, XOM, etc and put something great into Java itself.

I think including literal XML syntax in Java could easily be confusing, particularly something that doesn’t look like XML (the #-based syntax shown in the talk). If there is going to be a literal syntax, I can’t see how you could do it without angle brackets. Without that, you’re breaking the whole benefit of having a literal syntax, which can leverage all that experience developers have looking at XML in the first place. I’d rather stick to method calls than use the # syntax -yuck. My worry is that XML-y syntax will break down once you start to include namespaces, comments, and all the other parts of XML.

Having spent some quality time with XQuery and looking at the examples in the talk, I am struck by how the problems being solved (especially regarding construction) share an awful lot with the work done for XQuery. Now that XQuery is a standard, and some of the XQuery engines (like Michael Kay’s Saxon) are actually compiling XQuery to bytecode, maybe it’s worth considering whether building a library is really the right direction. Maybe integrating XQuery as a scripting language through JSR 223 and standardizing (via JSR) a standard way to communicate across the scripting interface (interfaces, bridging Java objects with schema types, calling Java as external functions, etc) would be a better solution. It seems like something like this approach could:

• Leverage the best standard way to do xml construction, navigation, etc
• Avoid further expanding the Java APIs
• Continue pushing the development of world-class high-performance XQuery engines

What do you think?