• Post Reply Bookmark Topic Watch Topic
  • New Topic

Autoboxing madness... perhaps  RSS feed

 
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Sorry to be asking such a question, not sure where else to ask it.
A friend sent me the below code as it was performing oddly (she is a tester trying to pick up Java).

I think there is some strange autoboxing thing going, now I avoid autoboxing as much as possible.

in the first two comparisons, I think the comparison is being autoboxed so that it is comparing the
value of the Integers.
In the third one I think it is comparing the addresses of foo and bar.
So far so good, the next two comparising I think are autoboxed.

Now here is where the madness kicks in, the final comparison returns true, foo1 and bar1 are equal.
So is it autoboxing, well I dont think so. As it turns out, in InteliJ the reference for foo1 and bar1 are the same!!!
Is this the result of a widening operation?

Any help or suggestions would be great.
Thanks.

Gavin

 
author & internet detective
Marshal
Posts: 37518
554
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gavin Tranter wrote:Now here is where the madness kicks in, the final comparison returns true, foo1 and bar1 are equal.
So is it autoboxing, well I dont think so. As it turns out, in InteliJ the reference for foo1 and bar1 are the same!!![/code]

Yes. Java pools autoboxed integer constants below a certain value. I think it is 256, but not sure. 100 is definitely below that value.
 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Java pools auto boxed values Boolean, Byte, Character(from \u000 to \u007f), Short and Integer from -128 to 127.
 
Sheriff
Posts: 21136
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
-128 to 127 (inclusive) are guaranteed. Since a recent version you can increase this with system property java.lang.Integer.IntegerCache.high.

@Dinakar: you forgot Long, that's also cached. Integer is the only with a possible increased maximum with the above property.
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys, esp for the quick response.
That clears that up, I wasnt aware that the values where cached at all.

G
 
Dinakar Kas
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Rob,

I got to know something new
 
Dinakar Kas
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rob

Caching of Long values is not guaranteed.


Why do separate autoboxing conversions sometimes return the same reference?

Two autoboxing conversions of a primitive value p will yield an identical reference (that is, the == comparison will return true) if p is:

* true or false
* a byte
* a short or int in the range of a byte (-128 to 127)
* a char in the range of \u0000 to \u007f (0 to 127)

Note: The Java Language Specification does not explicitly guarantee this behavior for long values within the range of a byte.



SCJP FAQ at Javaranch
 
Rob Spoor
Sheriff
Posts: 21136
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dinakar Kas wrote:I got to know something new

So did I
 
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It works that way because autoboxing is converted to a call to the method valueOf(). For example:

It's the valueOf() method that does the caching. If you want to see it yourself, lookup the source code of class Integer in the file src.zip which is in your JDK installation directory.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!