JDK-6537167 : XSLTC java.lang.NoSuchFieldError for XSLT that runs OK in Java 5
  • Type: Bug
  • Component: xml
  • Sub-Component: javax.xml.transform
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2007-03-21
  • Updated: 2012-04-25
  • Resolved: 2007-04-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7
1.4.0 1.4Fixed 6u18Fixed 7Fixed
Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Linux d610 2.6.16.27-0.6-default #1 Wed Dec 13 09:34:50 UTC 2006 i686 i686 i386 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
I have some XSLT stylesheets that compile and run fine in Java 5, but are failing in Java 6 with exceptions like this:

java.lang.NoSuchFieldError: acting$dash$user
        at GregorSamsa.main$dash$nav()
        at GregorSamsa.template$dot$28()
        at GregorSamsa.applyTemplates5()
        at GregorSamsa.template$dot$15()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.transform()
        at com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:602)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:711)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)

or

java.lang.NullPointerException
        at com.sun.org.apache.xml.internal.dtm.ref.DTMDefaultBase.getDocumentRoot(DTMDefaultBase.java:1611)
        at com.sun.org.apache.xml.internal.dtm.ref.DTMDefaultBaseIterators$RootIterator.setStartNode(DTMDefaultBaseIterators.java:713)        at com.sun.org.apache.xalan.internal.xsltc.dom.KeyIndex$KeyIndexIterator.init(KeyIndex.java:805)
        at com.sun.org.apache.xalan.internal.xsltc.dom.KeyIndex$KeyIndexIterator.setStartNode(KeyIndex.java:747)
        at GregorSamsa.topLevel()
        at GregorSamsa.transform()
        at com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:602)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:711)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)

While trying to find the source of the problem, I think the problem might narrow down to the way I have some XSLT files which use <xsl:import> to import multiple other files, sometimes importing the same file more than once, eg. root.xsl imports import1.xsl and import3.xsl while import1.xsl also imports import3.xsl, and in import3.xsl it defines a global variable (like $acting-user, from the first exception message).

The XSLT validates without error using XSLT validation applications, and runs without error in Java 5.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I haven't been able to find exaclty the problem, so the easiest way for me to describe how to reproduce is to download the affected application from

http://downloads.sourceforge.net/malbum/matte-0.5.0-livedemo.tbz2?modtime=1173708370&big_mirror=0

This is a stand-alone webapp which you can easily reproduce these two exceptions by starting the application (with ./start.sh or .\start.bat), then going to

http://localhost:8080/matte/add.do
http://localhost:8080/matte/home.do

The XSLT files used by these two URLS are located at

apache-tomcat/webapps/matte/WEB-INF/xsl/upload-media.xsl
apache-tomcat/webapps/matte/WEB-INF/xsl/home.xsl

You can get a sample of the XML being used in the transformation by adding

log4j.logger.magoffin.matt=DEBUG

to the apache-tomcat/webapps/matte/WEB-INF/classes/log4j.properties

file, restarting the application, and looking in the apache-tomcat/logs/catalina.out log file. This will log the XML being used in each request.




EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The XSLT should transform without error (try the same stpes with a Java 5 JRE) and return the transformed XHTML.
ACTUAL -
An exception is thrown.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.NoSuchFieldError: acting$dash$user
        at GregorSamsa.main$dash$nav()
        at GregorSamsa.template$dot$28()
        at GregorSamsa.applyTemplates5()
        at GregorSamsa.template$dot$15()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.applyTemplates()
        at GregorSamsa.transform()
        at com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:602)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:711)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)

or

java.lang.NullPointerException
        at com.sun.org.apache.xml.internal.dtm.ref.DTMDefaultBase.getDocumentRoot(DTMDefaultBase.java:1611)
        at com.sun.org.apache.xml.internal.dtm.ref.DTMDefaultBaseIterators$RootIterator.setStartNode(DTMDefaultBaseIterators.java:713)        at com.sun.org.apache.xalan.internal.xsltc.dom.KeyIndex$KeyIndexIterator.init(KeyIndex.java:805)
        at com.sun.org.apache.xalan.internal.xsltc.dom.KeyIndex$KeyIndexIterator.setStartNode(KeyIndex.java:747)
        at GregorSamsa.topLevel()
        at GregorSamsa.transform()
        at com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:602)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:711)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
The source code is included in the webapp application as described above.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use Java 5.

Release Regression From : 5.0u10
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Comments
EVALUATION There were actually two problems in the attached test case. First, the NoSuchFieldError which was a result of a bug in the dead code elimination algorithm. In particular, when the same stylesheet defining global variables was included more than once via different include paths. Second, there was a simple problem where a root node was being used instead of a root node handle. A handle, represented by an integer, has bits to represent not only the node but also its DTM instance. When there is more than one DTM instance, e.g. when there are result tree fragments, node handles rather than nodes should be used. The problem was, in particular, in the topLevel() method of a translet where variables, parameters and keys are initialized using the root node handle.
06-04-2007