• Post Reply Bookmark Topic Watch Topic
  • New Topic

null==something vs something==null in java  RSS feed

 
Rajeev roushan sharma
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All, I saw some java code like null==something, but could not understand the concept and also want to understand how it is different than something==null. Please help me to understand the same. Thanks in advance!
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Both are similar. And in both the cases something is checked if its null.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you would have searched you would have found a few earlier topics about this. The short answer is that they are the same.

The long answer is that this is a remains from the old C days where everything could be treated as a boolean. If you forgot one of the = signs you would get an assignment. With something = null that assignment would succeed and the result would be equal to false. With null = something the compiler will give you an error because you cannot assign anything to null.

These days there is only one case where this is relevant, all thanks to auto boxing:
 
Stephan van Hulst
Saloon Keeper
Posts: 7983
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Still, I would consider it bad practice. Convention is to compare a variable against a value, not the other way around.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only exception being comparing against String constants: "value".equals(var). But that's only because that's faster than the alternative: var != null && var.equals("value").

Edit: I should of course use the same constant value...
 
Campbell Ritchie
Marshal
Posts: 56540
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Prime wrote:. . . that's faster than the alternative: var != null && var.equals("value"). . . .
that means "faster to write", I presume? I would have thought any difference in execution speed would be so small as to be undetectable.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Faster to write, yes. It will probably also be slightly faster in execution speed because it has only one null check instead of two (there's also one inside the equals method) but the difference will be microseconds at most, probably more like nanoseconds.
 
Naresh Shanmugam
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could you please tell me how does the below code throws NullPointerException

I couldnt understand how auto unboxing works here.
 
Campbell Ritchie
Marshal
Posts: 56540
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Naresh Shanmugam wrote:Could you please tell me how does the below code throws NullPointerException

I couldnt understand how auto unboxing works here.
Well, it won't compile because the constructor call should be preceded by new. Actually, you are better off saying Boolean.TRUE and not creating a new object.
Inside the round brackets you are assigning null to b. Then you attempt to use it (if takes a boolean, not a Boolean), which means it is unboxed. If you try to unbox null, you will suffer a NullPointerException
 
Naresh Shanmugam
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks For the explanation Campbell I got your point. Just one question, Is there any difference in performance between

and

Because in the Boolean class i could some thing like this

Similary is there any difference in performance between

and
 
Campbell Ritchie
Marshal
Posts: 56540
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is easier to understand for Strings and Booleans. All String literals are cached in the heap; if you write "Campbell" once and "Campbell" again, the JVM will recognise the same String has been used twice, and reuse the original object.
For Booleans, you would have to look in a file called src.zip, which is in your Java™ installation folder. Unzip it, look in the "java" folder, then the "lang" folder, then the Boolean.java file, and you will indeed find something similar to what you wrote (public static final etc). What you guessed is more or less what you will find . Since Booleans are immutable, there is usually no point in creating new objects; it uses up memory. The difference is very very slight, but you might as well reuse the objects. Remember, for control structures and assigning, you will usually use the primitive boolean, not the object Boolean.

It is more complicated for Integers. You find this method, which is overloaded to take String and String, int, as its parameters. If you look in the Java™ Language Specification, you find that a range of commonly-used values can be cached. So for Booleans, there are two values cached (TRUE and FALSE). For Integers, however, at least 256 values are cached. So saying new Integer(5) creates a new object, probably unnecessarily (Integer is also immutable), which the others don't.
Try applying System.identityHashcode() to the different objects, and see which have the same identity hash codes, or use the == operator. Try it with the method I linked to, as well as the two examples for Integer you gave. Change it so you try a non-cached number (eg 123456789) and see whether the results are different.

 
Naresh Shanmugam
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thankyou Campbell. It was very informative.
 
Campbell Ritchie
Marshal
Posts: 56540
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!