• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Autoboxing / Unboxing doubt

 
rakshak rai
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Hello all,

Output of the above code comes as below.

true
false


Can somebody explain me this.

Thanks
 
ranjitsingh thakurratan
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
okay a little work on your program and I found out that it takes all inputs a, b, c, and d as Integers (since they are) and runs the Integer version of compare method.

Long can take input which ends with the L sign , indicating that it is Long number.

check this code i edited.



gives output as Integer long

RJ
 
ranjitsingh thakurratan
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i still dont know why it says false .... hmmm!
 
ranjitsingh thakurratan
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i wud get that there is loss of precision or something!! and so it gets a false..hmm i donno!!
 
ahmed yehia
Ranch Hand
Posts: 424
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Integer literals less than 127 will result true in == comparison.
 
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
I think Ahmed is right. The reason for this is an optimization in the Integer class. Autoboxing is done by calling the method Integer.valueOf(...). The Javadoc of this method explains why it works like this:
Returns a Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values.

It doesn't say exactly what the "frequently requested values" are, but the output of your program demonstrates that 1 is one of the cached values, and 10000 is not.

If you really want to know all the details, you can lookup the source code for class Integer, which you can find in the file src.zip in your JDK installation directory. I looked it up (for JDK 1.6.0 update 2) and it looks like this:

So all numbers between -128 and 127 (inclusive) are cached.

I doubt that you have to know implementation details like this for the SCJP exam.
 
Henry Wong
author
Marshal
Pie
Posts: 21490
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So all numbers between -128 and 127 (inclusive) are cached.

I doubt that you have to know implementation details like this for the SCJP exam.


Actually, this is defined in the specification. Integers between -128 and 127 (inclusive) must be cached (with autoboxing). I believe that there is also a defined range for char, boolean, and short.

Also note that the specification makes no mention of what happens outside of the range -- for example, Longs are also cached with the Sun JVM, but the specification makes no mention of it.

Henry
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic