• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

null==something vs something==null in java

 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Bartender
Posts: 3225
34
IntelliJ IDE Oracle Spring Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Both are similar. And in both the cases something is checked if its null.
 
Sheriff
Posts: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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:
 
Saloon Keeper
Posts: 15488
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
Marshal
Posts: 79153
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 79153
377
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 79153
377
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thankyou Campbell. It was very informative.
 
Campbell Ritchie
Marshal
Posts: 79153
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic