# fundamental question about Integer (for example)

• 06-19-2010, 10:18 PM
kmansj
fundamental question about Integer (for example)
I have a fundamental question about object creation, using an Integer object as an example. This has been bugging me:

Code:

`Integer x = new Integer(97);`
My interpretation of this is, "create an instance x of the class Integer, and call the int constructor to store the value 97."

If I declare again somewhat differently:

Code:

`Integer y = 97;`
I interpret this as, "create an instance y of the class Integer, then store in it the value 97." I'm sure I'm missing some subtlety of the "=," but we'll get to that.

When I put my new instances x and y to the test, they don't quite behave as I expect:
Code:

```Integer x = new Integer(97); //x = 97; Integer y = 97; if (x == y) {   System.out.println("x == y"); } else {   System.out.println("x != y"); }```
...
====> x != y

Now if I uncomment the line which assigns 97 to x, I get a different result:
...
====> x == y

So I guess the fundamental question is, why are these 2 things different?
Code:

```Integer x = new Integer(97); Integer y = 97;```
Does the difference arise from the "=" itself?

Thanks for helping me think this through.

Kman
• 06-19-2010, 10:22 PM
Fubarable
You may be confusing one object being the same object as another vs holding the same value as another. A better test is this one:
Code:

```    if (x.equals(y)) {       System.out.println("x.equals(y)");     } else {       System.out.println("!x.equals(y)");     }```
• 06-19-2010, 10:38 PM
Norm
Is there any boxing going on here?
Does the compiler generate the new Integer() for you or some such code.
• 06-19-2010, 10:38 PM
kmansj
Fubarable, thanks. Basically you're saying I'm abusing the == operator. I was googling around and ran across an explanation pointing out that == compares references, not values. So my test failed because the references x and y are not the same, rather than their values. I think I get it now.

Thanks again.

Kman
• 06-19-2010, 10:41 PM
kmansj
Norm,

Sorry, not sure what you mean by boxing?
• 06-19-2010, 11:08 PM
m00nchile
Java doesn't like primitive types like ints, doubles and so on. Java likes objects, like Integers, Doubles etc. This is where the process of autoboxing comes in. Note this snippet:
Code:

`Integer a = 5;`
And you think nothing of it. But the compiler looks at this and thinks, oh my, I have an Integer variable, but the value assigned to it is of the type int. What to do, what to do... I know, instead of bothering the programmer about this minutea, I'll simply convert this call to
Code:

`Integer a = new Integer(5);`
Autoboxing is the compiler being lenient towards you by using primitives and their wrapper classes almost interchangably.
• 06-19-2010, 11:17 PM
kmansj
So the compiler is essentially casting the int to Integer when it sees the "=" assignment, right? That's what Norm meant by boxing?

Thanks moon.

-Kman
• 06-19-2010, 11:38 PM
curmudgeon
No, it's not a cast, but rather it's creating a new Integer object even though the code isn't specifically telling the compiler to do this.
• 06-19-2010, 11:49 PM
kmansj
thanks curmudgeon
• 06-21-2010, 12:02 PM
Tolls
Quote:

Originally Posted by m00nchile
Java doesn't like primitive types like ints, doubles and so on. Java likes objects, like Integers, Doubles etc. This is where the process of autoboxing comes in. Note this snippet:
Code:

`Integer a = 5;`
And you think nothing of it. But the compiler looks at this and thinks, oh my, I have an Integer variable, but the value assigned to it is of the type int. What to do, what to do... I know, instead of bothering the programmer about this minutea, I'll simply convert this call to
Code:

`Integer a = new Integer(5);`
Autoboxing is the compiler being lenient towards you by using primitives and their wrapper classes almost interchangably.

It doesn't replace it with a "new" call, but with a call to Integer.valueOf(). This allows it to reuse already defined Integer objects, which is why:
Code:

```Integer x = 97; Integer y = 97; if (x == y) {}```
returns true. In fact, this is why you generally shouldn't call "new Integer()", since valueOf() (in cases where you are creating lots of numbers) saves some space.
• 06-21-2010, 01:40 PM
JosAH
Feeling a bit more confident about autoboxing and caching? You won't be after reading this:

Code:

```import java.util.ArrayList; import java.util.List;   public class Autoboxing {         public static void main(String[] args) {                 Object foo = new Long(0xcafebabedeadbeefL);                 List<Object> bars = new ArrayList<Object>();                         bars.add(true ? (Long)foo : (Long)foo);                 bars.add(true ? (Long)foo : (Number)foo);                 bars.add(true ? (Long)foo : (Double)foo);                 bars.add(true ? (Long)foo : ((Long)foo).longValue());                 System.out.print("==    :");                 for (Object bar : bars)                         System.out.print(" "+(foo == bar));                 System.out.println();                 System.out.print("equals:");                 for (Object bar : bars)             System.out.print(" "+foo.equals(bar));                 System.out.println();         } }```
kind regards,

Jos ;-)