4

It looks as though the JDK provides its own shaded version of apache xalan.

I have found a bug in producing XML with an XSLT (bug is a new line and indentation is added within some cdata sections). This is fixed in the unreleased jdk12. I would like to avoid this situation in which I have to both wait for oracle to fix the problem as well as upgrade the JRE used.

I looked into including xalan as a dependency via maven. This does work and seems to fix the issue however it appears that the last time xalan was updated was Jul 24, 2014. That is more than 4 years since the last update.

I would like to be able to depend on xalan or something else that supports XSLT without that dependency coming from the JRE.

  1. Does oracle maintain its own version of xalan for its JRE independent from apache?
  2. Why has xalan not been updated since Jul 2014 on maven?
  3. Will depending on xalan cause all sorts of issues? I did see in Dealing with "Xerces hell" in Java/Maven? that xml-apis was excluded to try and avoid some issues.
  4. Would it be better to use a different XML library that is less likely to be also used by the JVM? What would be a library worth looking into.
Luke
  • 884
  • 8
  • 21
  • Java 12 will be released in March. It might be easier to wait until then. – VGR Dec 17 '18 at 05:06
  • 3
    #4: Check out [Saxon](http://saxon.sourceforge.net/) which also supports XSLT 3.0, as answered in these questions: [How to use XSLT 3.0 from a Java application?](https://stackoverflow.com/q/44796871/5221149) and [How can I use XSLT 2.0 and XSLT 3.0 in Java?](https://stackoverflow.com/q/41317022/5221149) – Andreas Dec 17 '18 at 05:28

1 Answers1

4

Trying to answer as best I can (but some of your questions require inside knowledge):

  1. As far as I can tell, the JRE versions of Xerces and Xalan are modified versions of Apache Xerces and Xalan, but not heavily modified, and there is some effort to port bug fixes across from the Apache version.

  2. Xalan has not been modified because no-one is working on it. Its original sponsors were IBM and Sun (it derives partly from IBM's LotusXSL, partly from Sun's XSLTC). Sun's developers left after the Oracle acquisition; IBM moved its investment into the commercial Websphere XSLT 2.0 processor and the Datapower engine. So Xalan remained as an XSLT 1.0 processor, which means the specification has not changed in 19 years, and the code became correspondingly stable so there has been little need for bug fixing. Users who need more functionality than Xalan offers typically move to Saxon, unless they have the kind of budget that makes Websphere or Datapower affordable.

  3. No, it's quite possible to have an application use the Apache versions of Xalan and/or Xerces without running into any technical problems.

  4. (I have an interest here) Moving to Saxon gives you all the functional and productivity benefits of XSLT 2.0 and XSLT 3.0; the product is continuously developed and maintained and well supported; in some cases you may see a substantial performance improvement; and there's been a lot of incremental improvement over the years in areas such as diagnostics, configurability, and instrumentation. But the benefits have nothing to do with whether or not the code is also used in the JVM.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
  • Thanks for the response! Saxon looks neat, I did notice that when I depended on it it was immediatly put to use with code like 
    TransformerFactory.newInstance()
    I guess that is nice because most places should just use Saxon, although I worry that the JVM expects some other XML implementation and wont work correctly. Perhaps I shouldn't be concerned about that.     – Luke Dec 18 '18 at 02:18
  • 1
    It's a valid concern. If your application relies on `TransformerFactory.newInstance()` then it's saying that it's prepared to use whatever XSLT engine is found on the classpath, and that's a dangerous thing to say if the XSLT hasn't been written and tested for portability. – Michael Kay Dec 18 '18 at 11:12
  • I guess at least now I am in control of what XML parser is used, and if something is wrong I probably have a better chance of getting a fix for it even if I need to make the fix myself. Hopefully it is straight forward to import the code into eclipse. – Luke Dec 18 '18 at 20:20
  • @MichaelKay As far as I can see, moving to Saxon is prohibitively expensive. We distribute a relatively low-cost product and would spend more on XSLT transformations than the final price of the product itself. We're sticking with Xalan and XSLT 1.0, despite its shortcomings. – DAB Apr 12 '23 at 09:12
  • @DAB There is an open source version of Saxon that is free to use and distribute, but you may be referring to other costs that I'm not aware of. It's your choice of course. – Michael Kay Apr 12 '23 at 17:45
  • @MichaelKay, thank you very much for this tip! Could you send me a link to the most reliable version? I'm not sure where to look. – DAB Apr 13 '23 at 09:29
  • www.saxonica.com, look at "products" and "download". – Michael Kay Apr 14 '23 at 14:17