In the Java language, dealing with null Pointers is often a headache, and if you’re not careful, you could end up with an online Bug that will give you a 3.25 performance review.

NullPointerException is a NullPointerException that can be handled by Java14. (There are benefits at the end of the article!!)

1. Traditional NullPointerException

In our coding process, we often use the chain call method to write code, which is easy and clear to write, but when NullPointerException occurs, it’s very difficult to know when the exception started.

For a simple example, such as the following code, to find the domicile of an employee in the company, we call

String city = employee.getDetailInfos().getRegistryAddress().getCity();  Copy the code

During the chain call, if employee,getDetailInfos(), or getRegistryAddress() is null, the JVM throws a NullPointerException

So what is the root cause of the anomaly? Without using a debugger, it is difficult to determine which variable is null. Also, the JVM simply prints the method, filename, and line number that caused the exception, and that’s it. Now, I’ll take you through how Java 14 solves this problem with JEP 358.

2. Enhanced NullPointerException

SAP implemented an enhanced NullPointerException for its commercial JVMS in 2006. In February 2019, it was proposed as an enhancement to the OpenJDK community, and soon after, it became a JEP. As a result, this feature was completed and released in JDK 14 in October 2019.

In essence, JEP 358 aims to improve the readability of “NullpointerExceptions” generated by the JVM by describing a variable as “null.” JEP 358 brings a detailed NullPointerException message with variables described as NULL next to the method, filename, and line number. It works by analyzing the bytecode instructions of the program. Therefore, it can determine exactly which variable or expression is NULL. Most importantly, detailed exception messages are turned off by default in JDK 14. To enable it, we need to use the command-line option:

-XX:+ShowCodeDetailsInExceptionMessages  Copy the code

2.1 Detailed exception information

Consider in the case of activated ShowCodeDetailsInExceptionMessages sign again to run the code:

Exception in thread "main" java.lang.NullPointerException:  
  Cannot invoke "RegistryAddress.getCity()" because the return value of  "com.developlee.
java14.helpfulnullpointerexceptions.HelpfulNullPointerException$DetailInfos.
getRegistryAddress()" is null    at com.developlee.java14.helpfulnullpointerexceptions.
HelpfulNullPointerException.main(HelpfulNullPointerException.java:10)  Copy the code

This time, from the additional information, we know that the loss of the employee’s personal details to the registered address is causing our exception. The information gained from this enhancement can save us time for debugging.

The JVM consists of two parts for a detailed exception message. The first part represents the failed operation as a result of the null reference, and the second part represents the reason for the null reference:

Cannot invoke "String.toLowerCase()" because the return value of
 "getEmailAddress()" is null  Copy the code

To generate exception messages, JEP 358 reconstructs a portion of the source code that pushes empty references onto the operand stack.

3. Technology

Now that we have a good understanding of how to use the enhanced NullPointerException_s identifier _NULL reference, let’s look at some of its technical aspects.

First, the detailed message calculation is only performed when the JVM itself throws a NullPointerException, and if we show a NullPointerException thrown in our Java code, the calculation is not performed. The reason is this: in these cases, it is likely that a meaningful message has already been passed in the exception constructor.

Second, **JEP 358 ** calculates messages lazily, which means that the enhanced NullPointerException is called only when we print an exception message, not when it occurs. Therefore, there should be no performance impact on the normal JVM flow, where we can catch and rethrow exceptions, because we don’t just want to print exception messages.

Finally, detailed exception messages may contain local variable names in the source code. Therefore, we can consider this a potential security risk. However, this only happens when you run code compiled with the active -G tag, which generates debugging information and adds it to the class file. Consider a simple example that we have compiled to include the following additional debugging information:

Employee employee = null;  employee.getName();  Copy the code

When the above code is executed, the local variable name is printed in the exception message:

"com.developlee.java14.helpfulnullpointerexceptions.
HelpfulNullPointerException$Employee.getName()"  
because "employee" is null  Copy the code

Instead, without additional debugging information, the JVM provides only the variables it knows in the verbose message:

Cannot invoke    "com.developlee.java14.helpfulnullpointerexceptions.
HelpfulNullPointerException$Employee.getName()"  because "<local1>" is null  Copy the code

The JVM prints the compiler-assigned variable index instead of the local variable name (EMPLOYEE).

This is the end of NullPointerException processing. With Java14 enhanced NullPointerException, we can quickly locate the cause of code problems, debug the code faster, save time and improve efficiency.

If you have already installed Java14, you can try it

Want to learn more
Java
Architecture technologyI will also sort out more knowledge points about architecture technology to share: Spring, MyBatis, Netty source code analysis, high concurrency, high performance, distributed, microservice architecture principle, JVM performance optimization, concurrent programming these become necessary knowledge systems for architects.