I’m a little bit disappointed. I try to always assume that I’m in the wrong, and the libraries, carefully selected with an eye to maturity, are in the right. Without trust in one’s foundations, development goes much slower.
In Java 1.5 (1.5.0_06), Sun integrated the JAXP api and an implementation of it (Xalan). I’ve already stumbled on a performance problem in that implementation. This new problem is less serious in real impact, but it’s more of a “real” bug in that it’s not a sliding scale like performance.
There’s very little difference between this program:
public class DomViaDomTransform { public static void main(String[] args) throws Exception { File source = new File(args[0]); File stylesheet = new File(args[1]); StreamResult out; DOMSource src = new DOMSource( DocumentBuilderFactory.newInstance().newDocumentBuilder().parse( new FileInputStream(source))); DOMSource style = new DOMSource( DocumentBuilderFactory.newInstance().newDocumentBuilder().parse( new FileInputStream(stylesheet))); out = new StreamResult(System.out); TransformerFactory factory = TransformerFactory.newInstance(); Transformer xf = factory.newTransformer(style); xf.transform(src, out); } } and this program:
public class StreamViaStreamTransform { public static void main(String[] args) throws Exception { File source = new File(args[0]); File stylesheet = new File(args[1]); StreamResult out; StreamSource src = new StreamSource(new FileInputStream(source)); StreamSource style = new StreamSource(new FileInputStream(stylesheet)); out = new StreamResult(System.out); TransformerFactory factory = TransformerFactory.newInstance(); Transformer xf = factory.newTransformer(style); xf.transform(src, out); } } However, if you run them with the default JAXP implementation in 1.5, the first program will not transform the input XML. You’ll still get output, but the output will be the stylesheet.
For instance, take this stylesheet:
<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <!-- Default copy everything. --> <xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:template> </xsl:stylesheet> which is a direct copy transformation. If we feed in the following as the input XML:
<?xml version="1.0" encoding="UTF-8"?> <foo/> the second program (the one using StreamSource instances), will generate the same XML as output. With the first program (the one using DOMSource instances), you get the stylesheet as the output XML.
Silly bug, minor impact, easily worked around, but definitely broken. However, this is enough to convince me switch to Saxon, a drop-in JAXP replacement. The authour, Michael Kay, I understand to be very passionate and picky about all things XML, which is bad if you want to trade words I guess, but great for me as someone who wants a bug-free implementation of JAXP. I’m writing Java software in my spare time; I don’t have time to distrust my libraries.
Sun hasn’t recognized my bug submission yet, so it may be a duplicate of a known problem (none that I could find using the search engine, though), or I could be using the classes incorrectly. I don’t see how the latter is possible though, as putting Saxon on the classpath to become the new JAXP implementation corrects the problem, without recompilation.
