Saxon

The DOM is not thread-safe even for retrieval access.

Saxon will synchronize its own access on the Document object, but if you need to access the document from your own code, that must be synchronized as well.

Does it have to be DOM? Other Java document models such as JDOM2 and XOM work much better.

Michael Kay Saxonica

Thank you for the confirm and your suggestions about using JDOM2 and XOM instead of DOM, Michael.

Indeed, after googling, JDOM2 seems much better than DOM, at least on the performance.

The nice of DOM is that there is also a javascript equivalent on the client side (web browser).

It allows me reusing my java DOM code on the javascript by using a java to javascript compiler (GWT).

Here I have simply replaced the GWT package com.google.gwt.xml.client with java package org.w3c.dom, since both packages are almost identical.

The same thing cannot be done on the JDOM2, since the difference with GWT package is too big.

Sorry to repeat the question again.

Is the read-only document implementation created by net.sf.saxon.dom.DocumentBuilderImpl thread-safe?

From document api:

This class implements the JAXP DocumentBuilder interface, allowing a Saxon TinyTree to be constructed using standard JAXP parsing interfaces. The returned DOM document node is a wrapper over the Saxon TinyTree structure. Note that although this wrapper implements the DOM interfaces, it is read-only, and all attempts to update it will throw an exception. No schema or DTD validation is carried out on the document.

Interesting you should ask this, because a week or so ago I noticed that the net.sf.saxon.dom.DocumentBuilderImpl class was orphaned - there are no references to it from elsewhere in the product or from our test suite, which means we have been releasing it for some years without testing. That gives us three possible courses of action: (1) write tests, (2) drop the class from the product, or (3) continue releasing it untested until someone raises a bug. I decided, perhaps rashly, to do (2), on the basis that it's easy enough to put it back in if someone complains. Perhaps this is the feedback we needed...

But with that proviso, the design of the class means that it should be thread-safe.

Thanks for confirming, Michael.

Indeed, I would like to see that this DocumentBuilderImpl will be kept in the product.

It would be better that the @deprecated signature on method parse(InputSource in) can be removed in the future, since it is not so easy to find a thread-safe DOM (even read-only) implementation elsewhere.

I have reinstated the DocumentBuilderImpl class, and have added some unit tests.