Update: 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();
}
}
returnnull;
}
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.
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.
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.
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.
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.
This was rejected by Project Coin.
See
http://blogs.sun.com/darcy/entry/project_coin_final_five
Wow !! Its looks great. Certainly helpful.
@ Stephen Colebourne: Can you provide more details for rejection?
This is the way Freemarker handles Null. In Freemarker you can go like:
( object.getThis().getThat() )?
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.
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.
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 http://javaposse.com/index.php?post_id=529403
I would strongly recommend Viral puts an Edit at the top of the article per Stephan and Stefans comments.
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.
I am facing the compilation if i do the same and try to work out.
Can you please help me out??