Null-safe Type in Java 7: New way to handle NullPointerException

java-logo-cupUpdate: This feature has been removed from the final feature list that is being included in Java 7. Thanks @Stephen and @Stefan for the comments. Please refer to Project Coin for more details. NullPoniterException is one of the most common exception encountered in Java programming. When I searched “NullPointerException” in Google, it gave about 6,130,000 results! This proves how pervasive the exception is and how much effort a developer has to put in writing java code free from null pointer exception. Suppose we have a method to fetch postal code of a person’s address:
public String getPostcode(Person person) { if (person != null) { Address address = person.getAddress(); if (address != null) { return address.getPostcode(); } } return null; }
Code language: Java (java)
Now check the above syntax. We have done lots of if (null != object) checks to avoid NullPointerException. Java 7 (Codename: Dolphine) will change the way we do Null handling in our code. Java 7 will be released in first half of 2010. If we write above code using Java 7 Null-safe Type (also called Null-ignore invocation), it will look like:
public String getPostcode(Person person) { return person?.getAddress()?.getPostcode(); }
Code language: Java (java)
Null-ignore invocation is concerned with dealing with possible null values in calling one or especially a chain of methods. Check the syntax ?. while calling method on an object. This is Null-safe operator in Java 7. Thus, you can avoid lots of if (null != object) checks in Java 7.
Get our Articles via Email. Enter your email address.

You may also like...


  1. Stephen Colebourne says:

    This was rejected by Project Coin.

  2. Stefan Zobel says:


  3. Raminder says:

    Wow !! Its looks great. Certainly helpful.
    @ Stephen Colebourne: Can you provide more details for rejection?

  4. Luciano Fiandesio says:

    This is the way Freemarker handles Null. In Freemarker you can go like:
    ( object.getThis().getThat() )?

  5. Stephen Colebourne says:

    I believe that the opinion is that it would promote the use of null, which is ‘a bad thing’. Personally, I’m more pragmatic and think that avoiding loads of NPEs justifies the change. I know I would have used it all the time. If you don’t like the decision, write to the Coin mailing list.

  6. Pascal says:

    I do not like this. This makes it very difficult to read there is an null check and people will most likely over use it. There are times when it’s valid to do a null check and there are times it’s simply hiding a bug elsewhere. Also, during debugging, it would make it difficult to know which value is null.

  7. Kon Soulianidis says:

    Yes, it was rejected. Whilst it makes sense in Groovy, when actually tried out with real Java codebases as part of project coin testing, it didnt work so well compared to the Groovy implementation. Who knows, if you want it, contribute to the project.

    Javaposse interview with Project Coin is a great resource about the how and why

    I would strongly recommend Viral puts an Edit at the top of the article per Stephan and Stefans comments.

  8. Tim says:

    Null safe checks are useful in large legacy codebase. I personally prefer to fail fast with liberal use of preconditions to fail early in a method call however different processing needs have different requirements.

    This syntax is horrible and I cant thing of something better.

    I do think of C++ and the -> Operator

    public String getPostcode(Person person) {
    return person->getAddress()->getPostcode();

    Or potentially use the .. operator (my own concoction)

    public String getPostcode(Person person) {
    return person..getAddress()..getPostcode();

    Both seem horrible because of c++ nostalga and general eyesore.

  9. Rameez Raja says:

    I am facing the compilation if i do the same and try to work out.

    Can you please help me out??

Leave a Reply

Your email address will not be published. Required fields are marked *