JDK9 project: XML/JAXP Approachability / Ease of Use

huizhe wang huizhe.wang at oracle.com
Mon Jun 23 19:05:51 UTC 2014


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. Consider the 
following example:

         File file = new File(FILEPATH + "results.xml");
         DocumentBuilderFactory factory = 

         XPathFactory xf = XPathFactory.newInstance();
         XPath xp = xf.newXPath();
         xp.setNamespaceContext(new NamespaceContext() {
             public String getNamespaceURI(String prefix) {
                 return "http://example.com/users/";

             public String getPrefix(String namespaceURI) {
                 return "ns1";

             public Iterator getPrefixes(String namespaceURI) {
                 ArrayList list = new ArrayList();
                 return list.iterator();

         try {
             DocumentBuilder builder = factory.newDocumentBuilder();
             Document document = builder.parse(file);
             String s = (String) xp.evaluate(
                     document, XPathConstants.STRING);
             System.out.println("Company: " + s);
         } catch (ParserConfigurationException e) {
             //creating DocumentBuilder
         } catch (SAXException ex) {
         } catch (IOException ex) {
         } catch (XPathExpressionException ex) {
             //xpath evaluation

The issues reflected in the above sample include:

*1. Too many abstractions*

As shown in the above sample, there are multiple layers of abstraction 
in the DOM and Xpath API: factory, builder, and document, XPathFactory 
and XPath.

*2. Unnecessary Pluggability*

The pluggability layer allows easily plugging in third party 
implementations. However, in many use cases where pluggability is not 
needed, it becomes the performance bottleneck for the applications.

*3. Too many unrelated checked exceptions*

There are four unrelated checked exceptions in the above example. None 
of them is recoverable. ParserConfigurationException actually reflects a 
design flaw in the DocumentBuilderFactory that allowed setting both a 
Schema and Schema Language. In practice, Exception is often used to 
avoid having to catch each of the checked exceptions.

*4. Lack of integration*

JAXP is an umbrella of several libraries. The sample code above 
demonstrated the lack of integration among them. First of all, A DOM 
Document and XPath have to be created separately. Secondly, as in the 
above case, the Document may be either namespace-aware or unaware, 
depending on the setting on the DOM Factory, which is unknown to XPath 
created later.

This project may have two aspects: one to provide APIs to get straight 
to the objects such as DOM Document, and another to provide convenient 
methods for some common use cases.  (*Note that, there is no intention 
to replace the existing API nor duplicate all of the features.)

For the example above, it could potentially be done in a couple of lines 
(this is just an illustration on how existing APIs could be simplified 
and may not reflect what the API would look like):

         String company =
             XMLDocument.fromFile(FILEPATH + "results.xml")
         System.out.printf("Company: %s%n", company);

We would love to hear from you. Any thoughts, concerns, 
experiences/complaints would be very welcome.


More information about the discuss mailing list