On 10/08/2013 00:55, huizhe wang wrote:
:
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 =
new
com.sun.org.apache.xerces.internal.util.SecurityManager();
setProperty(Constants.XERCES_PROPERTY_PREFIX +
Constants.SECURITY_MANAGER_PROPERTY, manager);
}
}
where:
SAXParser is com.sun.org.apache.xerces.internal.parsers.SAXParser
DTDConfiguration is
com.sun.org.apache.xerces.internal.parsers.DTDConfiguration
Okay, I see it now:
$ jdeps --verbose-level=class xom-1.2.10.jar |grep "JDK internal API"
-> com.sun.org.apache.xerces.internal.parsers.DTDConfiguration
JDK internal API (rt.jar)
-> com.sun.org.apache.xerces.internal.parsers.SAXParser JDK
internal API (rt.jar)
-> com.sun.org.apache.xerces.internal.util.SecurityManager JDK
internal API (rt.jar)
->
com.sun.org.apache.xerces.internal.xni.parser.XMLParserConfiguration JDK
internal API (rt.jar)
In that case, this is not really a bug, it's that XOM needs to realize
that extending com.sun.org.apache.xerces.internal.** means they have a
dependency on JDK internal classes so they can break at any time. Also
as com.sun.org.apache.xerces.internal.** is on the restricted package
list then I assume they have problems running with a security manager.
I wasn't aware that SPECjvm2008 uses XOM. Unless XOM is fixed then I can
imagine this causing problems in the future, in particular if/when
visibility of JDK internal classes is restricted.
-Alan
