• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Query: In boxing why == & != both works

 
raul saini
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For e.g.:



In this both == & != works.

How?
 
Pramod P Deore
Ranch Hand
Posts: 632
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this here is only first condition is true, not second one
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raul - what do you mean by both == and != works ?
Are you saying that code prints
Equal
Different
 
raul saini
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually it was given in Kathy sierra SCJP book page no. 254-256, that:




Produces the output:
different objects
meaningfully equal

And,




This example produces the output:
same object
meaningfully equal

But when I executed != failed, But I'm still not able to get what the book meant.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note the difference in the values of the Integers.
What the example is trying to show is how Integer values between -127 and 128 are cached, but values outside that range are not*.

Search the forums. This question crops up a lot.







*Actually they can be but it is not mandatory.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15480
43
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is because of how autoboxing and the Integer class work.

Autoboxing means that the compiler automatically replaces code like this:

with the following:

You know that using == on non-primitive values returns true only if the values on both sides of the == operator refer to the exact same object. (It returns false if you have two different objects, even if those objects have the same value).

So, the question now is, why does this print true:

but why does this print false:


The answer is in the way that Integer.valueOf(...); works. This method does not always return a new Integer object - instead, it manages a cache that contains Integer objects with all the values between -128 and 127. If the value you pass into the method is in that range, it will return the pre-created object in the cache. In the first example with the value 42, the variables i1 and i2 will therefore refer to the same Integer object (that comes from the cache). In the second example with the value 1000, you will get two distinct Integer objects, because 1000 is outside of the range of the cache.
 
Anant Jagania
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does autoboxing work the similar way for other primitive wrapper objects? Does caching happen for other wrapper objects like Long, Double, Boolean, Short, Float, Byte?
 
Raza Mohd
Ranch Hand
Posts: 247
Java MyEclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@jesper thanks for concrete explaination!

Does caching happen for other wrapper objects like Long, Double, Boolean, Short, Float, Byte?


i have same query as Anant.
 
Nikhil Kumar C
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Integer.valueOf(...) does not always return a new Integer object - instead, it manages a cache that contains Integer objects with all the values between -128 and 127.


Is there any specific reason why only integer values between -128 to 127 are being cached?
 
raul saini
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Got it, Thank You Every One.
 
Henry Wong
author
Marshal
Pie
Posts: 21493
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nikhil Kumar C wrote:
Is there any specific reason why only integer values between -128 to 127 are being cached?


The specification defines the types and the ranges that must be cached. It does not define what should happen to the values of other types, or if they are outside of the required ranges.

The current Sun java implementation caches as required, plus... (1) it also caches long values, which is not required, and (2) there is a switch to allow the user to increase the range (caching values which are not required).

Henry
 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To me it seems logical that the reasons the specification would call for cached
values are the usual - space and speed. On average, the code will run faster
and in less space with the cached primitives.

Jim ... ...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic