Wrapper Class and ==

[Cole Tarbet]

    public static void main(String... args) {
            Integer a = 1;
            Integer b = a;
            System.out.println(a == b);
            ++a;
            System.out.println(a == b);
    }

Why is the output true, false? The wrapper classes don't seem to behave like regular objects.

[Matthew Brown]

They do. But they're immutable. When you have an Integer and use the ++ operator, this is happening:

- The Integer is auto-unboxed to an int
- The int is incremented
- The int is auto-boxed to a new Integer

So by the end of that code, a and b are pointing at different objects.

[Cole Tarbet]

Just like String... Can't rely on == for comparisons. Thanks!

[Scotty Mitchell]

Cole Tarbet wrote:Just like String... Can't rely on == for comparisons. Thanks!

Well, wrappers are after all a subtype of object are they not instanceof!

[Cole Tarbet]

Scotty Mitchell wrote:Well, wrappers are after all a subtype of object are they not instanceof!

I don't understand what you mean...?

The reason behind my question is that if I used StringBuilder and append then the output would be true, true because both references refer to the same object. I can understand int being immutable, but it would make more sense if Integer behaved like a regular object.

[Scotty Mitchell]

Anyway, what I was thinking is that whenever you arnt looking at non primitives i.e an object of some sort == isnt checking for meaningful equality. Or am I wrong to think this?

Also, StringBuilder is mutable is it not? The immutable thing is pretty important here...isnt that why theirs new object creation?

[Matthew Brown]

It is acting like a regular object. The think that's confusing you is the auto-boxing/unboxing, which was added to the language much later than the wrapper classes. In old-style Java:

++a;

Would be replaced by:

int temp = a.intValue();
++temp;
a = Integer.valueOf(temp);

At which point, you probably wouldn't be surprised that aand b are referencing different objects;

[Cole Tarbet]

@Matthew - That does make it more clear. The special case here is autoboxing.

Scotty Mitchell wrote:Anyway, what I was thinking is that whenever you arnt looking at non primitives i.e an object of some sort == isnt checking for meaningful equality. Or am I wrong to think this?

Also, StringBuilder is mutable is it not? The immutable thing is pretty important here...isnt that why theirs new object creation?

== checks if objects are the exact same instance in memory. It might be useful to make that distinction in some special case.

StringBuilder is mutable.

[Scotty Mitchell]

== checks if objects are the exact same instance in memory. It might be useful to make that distinction in some special case.

Yes, I do agree it would be helpful to make that distinction in some case. What I meant by meaningful equality was meant towards referencing if an objects state values are the same.

Open question:

Is unboxing of Integer why the below code prints out true or is that int 1 is being boxed to Integer? I feel as though if it were latter case the result would mean they would not be equal.

Also since string doesnt have a boxing feature so the false should print out in this case because the string objects are pointing to different references correct?

 if (new Integer(1) == 1) System.out.println("true"); 
 if (new String("hi") != "hi") System.out.println("false");