Enthuware

Either I am seriously not getting it, or else there is an error here and the authors of this question intended to use at least one variable of type byte instead of both being int or Integer. Why else would the assignments back and forth be limited to 127 (the max byte value)?

Aha, type first, think later, that's my motto. I am re-reading the explanation about Java "re-using" the wrapper objects for values up to 127 -- is that the answer? This seems really obscure to me. At any rate, if ...

wrapper2 = wrapper1;
wrapper1--;
wrapper1++;
System.out.println(wrapper2 == wrapper1);

if I understand this right, then because of this re-use-the-wrapper-object feature, I will get true if wrapper1 started out <= 127, but false otherwise? Holy moly.

You got it right

Thanks, but I have confused myself further! It turns out that I get different results when assigning the value different ways.

Integer x = new Integer(127);
Integer y = x;
x--;
x++;

evaluates (x == y) to false.... whereas....

Integer x = 127;
Integer y = x;
x--;
x++

evaluates (x==y) to true!!!! What the heck? Is there something about boxing/unboxing instead of using the Integer constructor? Does "Integer x = 127" tell the compiler, hey, you are only using eight bits here, so feel free to reuse that danged wrapper object, whereas new Integer(val) doesn't?

When you do new Integer(127), there is no "auto" boxing. You are boxing it yourself. Effectively, you are asking the JVM to create a new object instead of reusing an existing one.
However, x++ or x-- uses auto-boxing and so that causes the JVM to assign an interned object, which is different from the one that you created earlier.

HTH,
Paul.

Makes perfect sense; thank you.

Such thing is very tricky. So I prefer to program in an effective and safe way. For example, if int is enough, I would not use Integer. If I want to have access to the int value of an Integer, I would use intObj.intValue().

Explanation says Java re-uses all wrapper objects for Character values from decimal 0 to 127.

I tried

Character i = new Character('1');
Character j = i;
i--;
j++;
System.out.println(i==j);

and it printed false.
Could you please explain?
Thanks

Explained above:

When you do new Integer(127), there is no "auto" boxing. You are boxing it yourself. Effectively, you are asking the JVM to create a new object instead of reusing an existing one.

Got it,
Thanks.

I understand the rules but let me get this straight...

1. Integer i = new Integer(5); --- i pointing to a new Integer 5 Object
2. Integer j = i; --- j pointing to same new Integer 5 Object
3. i--; --- (what's supposed to happen) i = new Integer 4
4. i++; --- (what's supposed to happen) i = new Integer 5
5. System.out.println((i==j)); --- i and j are now pointing to different objects (false)

However! From testing, I have come to the conclusion that in line 3 and 4 NO new objects are being created. At JVM startup?? Integer -128 to 127 objects(and others) are automatically created and constantly re-used unless explicitly told to create a new object.

Basically my point is, the explanation uses the word "re-uses" but that would mean they would have to be created first at some point in order to be RE-used.

Ad9999 wrote:I understand the rules but let me get this straight...

Basically, new Integer objects are created for values ranging from –128 to +127, only when you use the "new" keyword to create them. Otherwise, cached Integer objects are used. For other values, there is no cache.

1. Integer i = new Integer(5); --- i pointing to a new Integer 5 Object

Yes. Because of the usage of new keyword, even if an Integer object containing 5 already exists in the cache, a new object will be created. If an Integer object containing 5 is not in the cache, this one will NOT go in the cache.

2. Integer j = i; --- j pointing to same new Integer 5 Object

Yes. This is just a reference assignment.

3. i--; --- (what's supposed to happen) i = new Integer 4

Think of i-- as i = i-1;
Since there is no new keyword here, a cached Integer object containing 4 will be assigned to i if such an object already exists in the cache. If not, a new object will be created, put in the cache, and will be assigned to i.

4. i++; --- (what's supposed to happen) i = new Integer 5

Since there is no usage of the new keyword here, an Integer object containing 5 from the cache will be used. If it does not exist in the cash, a new one will be created and put in the cache first.

5. System.out.println((i==j)); --- i and j are now pointing to different objects (false)

Yes, they are pointing to different objects. i is from cache and j is not from cache. See comments above.

At JVM startup??

Possibly, but irrelevant. You don't know and you don't need to know when exactly an object was created. You only care that it is assigned at the time the statement like Integer i = 5 or i++ is executed.

Basically my point is, the explanation uses the word "re-uses" but that would mean they would have to be created first at some point in order to be RE-used.

Yes, it would have to be created at some point. That point could be at startup or could be before the first usage.

Ty for the detailed response! Although I am still curious as to when they are actually created, but that is out of scope of this exam. :p

One could develop a JVM that creates these object at startup or on demand. Both options are valid. To find which option Oracle's JVM uses, you may need to go through their documentation.

For Boolean I don't see how it can use the same wrapper class. Can you give me an example where == returns true?

Boolean b1 = true;
Boolean b2 = true;
System.out.println(b1==b2);

When you do i++, what actually happens is something like this: i = new Integer( i.intValue()  + 1); 

I think it is like this: because constructor always create new object, and only valueOf method use cache.

I agree with Russtam.
The explanation provided by enthuware is misleading, because i++ translating to implies that i and j could never refer the same object

Fixed.
thank you for your feedback!