RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34

huizhe wang huizhe.wang at oracle.com
Fri Aug 9 23:55:08 UTC 2013

On 8/9/2013 1:51 PM, Alan Bateman wrote:
> On 08/08/2013 22:57, huizhe wang wrote:
>> Hi,
>> The root cause of this issue is that SPECJVM2008 uses a 3rd party 
>> parser XOM 1.1 to convert the output to its canonical form. The XOM 
>> parser directly references to the JDK parser implementation 
>> "SAXParser" with a different configuration than the default JDK 
>> parser, in this case, the DTD-only parser configuration 
>> "DTDConfiguration".  In JAXP 1.5, we added XMLSecurityPropertyManager 
>> that is instantiated in the default configuration 
>> "XML11Configuration".  Since XMLSecurityPropertyManager is not 
>> supported by DTDConfiguration, XOM no longer works.
> I see this has been pushed but just so I understand, but can you 
> expand on what you mean by "directly references JDK parser 
> implementation"? I'm just wondering whether it's using the standard 
> provider interfaces when on the class path or whether it's tied to an 
> old Xerces interface?

It's not using a standard interface.  It goes straight to the 
implementation, here's how it's done:
     class JDK15XML1_0Parser extends SAXParser {

         JDK15XML1_0Parser() throws org.xml.sax.SAXException {

             super(new DTDConfiguration());
             // workaround for Java 1.5 beta 2 bugs
com.sun.org.apache.xerces.internal.util.SecurityManager manager =
             setProperty(Constants.XERCES_PROPERTY_PREFIX + 


SAXParser is com.sun.org.apache.xerces.internal.parsers.SAXParser
DTDConfiguration is 

And of course, if Xerces jars are on the classpath, these would be:
org.apache.xerces.parsers.SAXParser and 

It looks up Xerces, then JDK, if failed, it actually falls back to the 
SAX interface, that is XMLReaderFactory.


> -Alan.

More information about the core-libs-dev mailing list