JDK9 project: XML/JAXP Approachability / Ease of Use

[Michael Kay]

Here are some quick thoughts about the state of XML support in the JDK:

1. XML Parser. The version of Xerces in the JDK has long been buggy, and no-one has been fixing the bugs. It needs to be replaced with a more recent version of Apache Xerces if that hasn't already been done.

2. DOM. From a usability perspective DOM is awful. There are much better alternatives available, for example JDOM2 or XOM. The only reason anyone uses DOM rather than these alternatives is either (a) because they aren't aware of the alternatives, or (b) because of some kind of perception that DOM is "more standard". If we want to address the usability of XML processing in the JDK then an alternative/replacement for DOM would seem to be a high priority. If someone wants a summary of the badness of DOM then I'll address that in a separate thread.

3. JAXP factory mechanism. While the goal of allowing multiple implementations of core interfaces such as DOM, XPath, and XSLT is laudable, the current mechanism has many failings. It's hideously expensive because of the classpath search; it's fragile because the APIs are so weakly defined that the implemntations aren't 100% interoperable (for example you have no way of knowing whether the XPath factory will give you an XPath 1.0 or 2.0 processor, and no way of finding out which you have got); so in practice we see lots of problems where applications get a processor that doesn't work as the applications expects, just because it happens to be lying around on the classpath.

4. XQJ. The XQJ spec never found its way into the JDK, so there is no out-of-the-box XQuery support. The licensing terms for XQJ are also unsatisfactory (the license doesn't allow modification, which purists say means it's not a true open source license).

5. General lack of integration across the whole XML scene, e.g, separate and potentially incompatible factories for different services; a lack of clarity as to whether the XPath API is supposed to handle object models other than DOM, etc; weak typing of interfaces such as setParameter() in order to accomodate variation, at the cost of interoperability.

6. Failure to keep up to date with the W3C specs; if you want support for recent versions of XSLT or XPath then you need to go to third-party products. Even at the DOM level, namespaces are a bolt-on optional extra rather than an intrinsic capability.

7. Inconsistent policy on concrete classes versus interfaces.

Is this project attempting to address the fundamental problems, or only to paper over the cracks?


> We're planning on a jaxp project to address usability issues in the JAXP 
> API. One of the complaints about the JAXP API is the number of lines of 
> code that are needed to implement a simple task. Tasks that should take 
> one or two lines often take ten or twelve lines instead.


Michael Kay
Saxonica
mike at saxonica.com
+44 (0118) 946 5893