# Thread: fundamental question about Integer (for example)

1. Member
Join Date
Jun 2010
Posts
5
Rep Power
0

## 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:

Java 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:

Java 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:
Java 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?
Java Code:
```Integer x = new Integer(97);
Integer y = 97;```
Does the difference arise from the "=" itself?

Thanks for helping me think this through.

Kman

2. 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:
Java Code:
```    if (x.equals(y)) {
System.out.println("x.equals(y)");
} else {
System.out.println("!x.equals(y)");
}```

3. Is there any boxing going on here?
Does the compiler generate the new Integer() for you or some such code.

4. Member
Join Date
Jun 2010
Posts
5
Rep Power
0
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

5. Member
Join Date
Jun 2010
Posts
5
Rep Power
0
Norm,

Sorry, not sure what you mean by boxing?

6. Senior Member
Join Date
Feb 2010
Location
Ljubljana, Slovenia
Posts
470
Rep Power
5
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:
Java 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
Java Code:
`Integer a = new Integer(5);`
Autoboxing is the compiler being lenient towards you by using primitives and their wrapper classes almost interchangably.

7. Member
Join Date
Jun 2010
Posts
5
Rep Power
0
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

8. Senior Member
Join Date
May 2010
Posts
436
Rep Power
4
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.

9. Member
Join Date
Jun 2010
Posts
5
Rep Power
0
thanks curmudgeon

10. Moderator
Join Date
Apr 2009
Posts
11,302
Rep Power
18
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:
Java 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
Java 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:
Java 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.

11. Feeling a bit more confident about autoboxing and caching? You won't be after reading this:

Java 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 ;-)

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•