JDK-8021148 : Regression in SAXParserImpl in 7u40 b34 (NPE)
  • Type: Bug
  • Component: xml
  • Sub-Component: javax.xml.parsers
  • Affected Version: 7u40
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-07-23
  • Updated: 2013-08-19
  • Resolved: 2013-07-26
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.
JDK 7 JDK 8
7u40 b36Fixed 8Fixed
Related Reports
Relates :  
Description
The following change in 7u40 b34 causes a P1 problem for NetBeans:

http://hg.openjdk.java.net/jdk7u/jdk7u40/jaxp/diff/4149e4abea17/src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java

Due to a missing check for null for fSAXParser the code raises NPE.

The exception prevents NetBeans IDE from completing creation of user's new project.

Related NetBeans bug:
https://netbeans.org/bugzilla/show_bug.cgi?id=233144

Comments
Is this an issue for jdk6 ?
16-08-2013

These failures aren't JCK tests failures, these tests from our SQE XML testsuite. I added test names for proper failures matching.
25-07-2013

The failures of JCK tests listed above was caused by JDOM that also referenced the JAXP internal parser. I would suggest removing the dependency on the old version of JDOM in the JCK test suite.
25-07-2013

I have test from the NetBeans team. NetBeans is indeed using the JAXP internal parser directly! Although, it's doing so by taking advantage of the jaxp plugin layer, setting org.xml.sax.driver to point to the internal parser, which is why I couldn't see it in the stack trace. While such a usage is not supported by the standard, I will still provide a fix to allow the existing NetBeans to work with the new version of the JDK. For the NetBeans, I would suggest remove setting and use the default parser. The way the internal parser is implemented, it is unsafe to be used directly since JAXP's secure processing is skipped.
24-07-2013

NetBeans bugzilla is back. It appeared that it is not using JAXP internal class, but there's a condition in NetBeans that caused JAXP to unable to return the default parser and fall back to JAXPSAXParser. I can't reproduce the nullpointer situation with a local test, but was able to do that with NetBeans by creating new project as described in the NetBeans bug report. I'm waiting for Antonin to provide a test.
23-07-2013

SQE is ok to take it in 7u40.
23-07-2013

7u40-critical-request: The issue is that NetBeans may be using JAXP internal class directly since inside JAXP the value of fSAXParser can not be null. The JAXPSAXParser class is only called inside JAXP's SAXParserImpl with itself as the parameter, fSAXParser would therefore never be null. This is why the reported issue was not caught by JAXP regression tests. Since this is the NetBeans, we'll fix it. But such usage is discouraged. We had survey before on usages of internal JAXP classes. This was not reported. The fix would be to add a null check where fSAXParser is referenced. The risk is low.
23-07-2013

Hi Antonin, Could you provide a test? The NetBeans Bugzilla gave me a 500 Internal Server Error right now. Thanks, Joe
23-07-2013