autoboxing questions.

[James Quinton]

I got confused with Autoboxing feature in jdk5.
K&B book Chapter 3.4 says

two instances of the following wrapper objects will always be == when their primitive values are the same:
1. Boolean
2. Byte
3. Character from \u0000 to \u007f (7f is 127 in decimal)
4. Short and Integer from -128 to 127

This raised two questions:
1. what happens to integer value bigger than 127, say 1000? What is the underlying reason causing the difference (the book didn't say)?

2. What happened to following code:

--code piece 1 (my code):
Integer i1 = Integer.valueOf("10");
Integer i2 = Integer.valueOf("10");
if(i1!=i2) System.err.println("not same");
if(i1==i2) System.err.println("same");
>>output: not same

If according to K&B's book, it's a like this:
--code piece 2 (K&B's code):
Integer i1 = 10;
Integer i2 = 10;
if(i1!=i2) System.err.println("not same");
if(i1==i2) System.err.println("same");
>>output: same

what makes the difference? I assume valueOf() method only does the manual boxing for compiler, but looks like it does something else.

[marc weber]

Originally posted by James Quinton:
...what happens to integer value bigger than 127, say 1000? What is the underlying reason causing the difference (the book didn't say)? ...

According to JLS - 5.1.7 Boxing Conversion...

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

...

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise...

Maybe I'm wrong on this, but my interpretation is that there are no guarantees for values outside the byte range (-128 and 127).

Originally posted by James Quinton:
...what makes the difference? I assume valueOf() method only does the manual boxing for compiler, but looks like it does something else.

Integer's valueOf methods return a new instance of Integer, so there is no autoboxing in this example. Perhaps you're thinking of the parseInt method, which returns an int?

[James Quinton]

fair enough. then my question is:
Integer i1=100;
Integer i2=100;

if i1==i2, how many Objects the above code created in total? Only one being referenced by both i1 and i2?

[marc weber]

Originally posted by James Quinton:
fair enough. then my question is:
Integer i1=100;
Integer i2=100;

if i1==i2, how many Objects the above code created in total? Only one being referenced by both i1 and i2?

Yes.

[James Quinton]

Originally posted by marc weber:

Yes.

If the answer is yes, it's really not convincing.

how come
Integer i1=1000;
Integer i2=1000;
creates two seperate Objects referenced by i1 and i2 (since i1!=i2), while
Integer i3=100;
Integer i4=100;
only creates one Object?

The way JVM creates the objects is determined by the primitive value of the objects? This sounds awful.

[Keith Lynn]

It's not awful. This is the discussion from the Java Language Specification, Section 5.1.7.

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly.

For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all characters and shorts, as well as integers and longs in the range of -32K - +32K.

[James Quinton]

ok, now I got the whole ideas.
but still, personally i don't like the boxing idea in jdk5. It creates lots of confusion, while doesn't introduce too much value other being than more like C#.
[ October 04, 2006: Message edited by: James Quinton ]

[Keith Lynn]

I like the boxing and unboxing idea. I think if you only use it to avoid excessive use of wrapper constructors and parse methods, it's a really nice way to keep from cluttering your code.