In the post “Better Default NullPointerException Messages Coming to Java?“, I summarized background details related to a draft JEP (at that time) regarding making some types of NullPointerException‘s (NPE’s) messages more useful. It was nice to see last week that this JEP is now a candidate JEP (JEP 358: “Helpful NullPointerExceptions”). In this post, I highlight aspects of JEP 358 that I find particularly interesting.
What is JEP 358?
JEP 358‘s current “Summary” succinctly describes this JEP: “Improve the usability of NullPointerExceptions generated by the JVM by describing precisely which variable was null.”
The “Motivations” section of JEP 358 includes this paragraph: “The entire Java ecosystem would benefit if the JVM could give the information needed to pinpoint the source of an NPE and then identify its root cause, without using extra tooling or shuffling code around. SAP’s commercial JVM has done this since 2006, to great acclaim from developers and support engineers.”
Example of Community Contribution to OpenJDK
One aspect of JEP 358 that interests me is its background. The “Testing” section of JEP 358 currently states that “a predecessor implementation has been in SAP’s commercial JVM since 2006 and has proven to be stable.” The intention of this statement is to demonstrate that some testing has already taken place for the feature, but it also points out that SAP and its personnel are the major contributors of this proposed JDK enhancement. The authors of the JEP, Goetz Lindenmaier and Ralf Schmelter (credited as original author), are or have been affiliated with SAP. My understanding is that the SAP OpenJDK release (SapMachine) does not include this feature yet, but the commercial SAP does. This proposed JDK enhancement is a nice example of how having multiple vendors delivering implementations of OpenJDK might benefit OpenJDK for everyone in the future.
The Downside of More Details
JEP 358 addresses a potential security risk introduced by more detailed NPEs. It states that “the null-detail message may contain variable names from the source code … if debug information is included in the class file (javac -g)” and “these have not previously been available to other programs via Java’s reflection APIs.”
Enabling Detailed Null Messages
The “Alternatives” section of JEP 358 outlines three reasons that one might not want the newer more detailed NPE messages (performance, security, and compatibility). It states, “The null-detail message is switched off per default and can be enabled by command-line option -XX:+SuppressCodeDetailsInExceptionMessages.” That section adds that “there is no way to specify that only some NPE-raising bytecodes are of interest” (in other words, it’s an all-or-nothing option). The section concludes with this statement, “We intend to enable the null-detail message by default in a future release.”
More Detailed Messages Are Not for All NullPointerExceptions
JEP 358 points out types of NullPointerExceptions to which the more detailed messages will apply and contrasts that with the types to which the more detailed messages will not apply. It states (I added emphasis), “Only NPEs that are created and thrown directly by the JVM will include the null-detail message. NPEs that are explicitly created and/or explicitly thrown by programs running on the JVM are not subject to the bytecode analysis and null-detail message creation described below. In addition, the null-detail message is not reported for NPEs caused by code in hidden methods, which are special-purpose low-level methods generated and called by the JVM to, e.g., optimize string concatenation. A hidden method has no filename or line number that could help to pinpoint the source of an NPE, so printing a null-detail message would be futile.” As the text states, there is no reason to attempt to provide details for “hidden methods.” As for NPEs our own code explicitly throws, we have the ability to add useful context to those exceptions’ messages already when we construct them.
Conclusion
The responses to this JEP have been enthusiastic and I think there are many Java developers who look forward to the availability of more detailed NullPointerException messages in future OpenJDK distributions. JDK-8218628 (“Add detailed message to NullPointerException describing what is null.”) is associated with JEP 358 (JDK-8220715) and is currently associated with JDK 14 as the “Fix Version.” Here’s hoping for JEP 358 to be officially targeted to JDK 14!
Published on Java Code Geeks with permission by Dustin Marx, partner at our JCG program. See the original article here: JEP 358: Helpful NullPointerExceptions Opinions expressed by Java Code Geeks contributors are their own. |
