Creation of Ineger Wrapper Object

[sujith Acharya]

I read, if we create Integer wrapper object with value from -128 to 127, it will use already existing object to save memory.
Since Integer is immutable object, why it dont use same principle when we create Integer object with value more than 127?

-Thanks & Regards

[Henry Wong]

sujith Acharya wrote:Since Integer is immutable object, why it dont use same principle when we create Integer object with value more than 127?

Well, there is nothing to stop the core libs from doing it... The specification only requires that the cache hold a certain range, and all implementions so far, only seem to hold the specified range.

And BTW, the "same principle", meaning the current implementation, has the objects being created in a cache, regardless of whether they will be used by the program. So, if you make this cache bigger, at a certain point, you will be wasting more memory than you would be saving.

Henry

[Rob Spoor]

sujith Acharya wrote:I read, if we create Integer wrapper object with value from -128 to 127, it will use already existing object to save memory.

Only if you use autoboxing or Integer.valueOf. If you use "new Integer" you will always create a new object. That's why I encourage the usage of Integer.valueOf.

[sujith Acharya]

Thanks both of you for the reply

@Henry Wong
"Cache " are you referring to the pool of constant what we call in general for String?
With your explanation , what I understood is, if the objects are created in cache, it will be alive even if no reference is referring to that object unlike in heap. That's how memory gets wasted. is that correct?


@Rob Prime
This is another doubt I was having. If we use Integer.valueOf(xxx) , it will first check in cache(pool) if the object with same value exists else it will create new object. Same in case of String. String str = "ABC";
So as a developer,what I think is, we should always use Integer.valueOf(xxx) and in case of String String str = "ABC"; instead of using new operator.

My question is, in any scenario , do developer need to instantiate the this wrapper or String object with new operator which definitetly create new object even if the object with same value exist in pool?

[Jesper de Jong]

You should never have to use new Integer(...) or the constructor of class String that takes a String as input. I don't know why these constructors even exist (with public access) in the wrapper classes and class String. Maybe it would have been better if they would have been omitted.

[Rob Spoor]

sujith Acharya wrote:@Henry Wong
"Cache " are you referring to the pool of constant what we call in general for String?
With your explanation , what I understood is, if the objects are created in cache, it will be alive even if no reference is referring to that object unlike in heap. That's how memory gets wasted. is that correct?

There will always be a reference to those 256 Integer objects - from the cache. This cache is basically an Integer[256].

There is a little trick with that Integer that will only create those 256 Integer objects if the first one is needed. If you never need to autobox an int, or never call Integer.valueOf(int), the 256 objects will never be created.

@Rob Prime
This is another doubt I was having. If we use Integer.valueOf(xxx) , it will first check in cache(pool) if the object with same value exists else it will create new object. Same in case of String. String str = "ABC";
So as a developer,what I think is, we should always use Integer.valueOf(xxx) and in case of String String str = "ABC"; instead of using new operator.

My question is, in any scenario , do developer need to instantiate the this wrapper or String object with new operator which definitetly create new object even if the object with same value exist in pool?

A developer should never the new operator anymore for Strings or primitive types. Sometimes a developer may want to have to distinct objects (with == returning false), although I can't see why.

Furthermore, the constructors are still useful when using reflection.

[Campbell Ritchie]

Jesper Young wrote:I don't know why these constructors even exist (with public access) . . .

Because seemed like a good idea at the time. They are library classes, and you can design library classes differently from your own classes. In your own classes, you think, "Will anybody need this method? Can they do it some other way? Do we want them doing it at all?" and unless you can definitely answer "yes, no, yes," to those three questions, you leave that public member out.
In a library class you can think, "Is there any chance that anybody who is not totally bonkers might rarely or occasionally think such a public member might be "cool"? and you implement that member unless everybody shouts you down with, "No, no no!"

That is why you have comments like "unless . . . use of this constructor is unnecessary."

[Muhammad Khojaye]

Jesper Young wrote:You should never have to use new Integer(...) or the constructor of class String that takes a String as input. I don't know why these constructors even exist (with public access) in the wrapper classes and class String. Maybe it would have been better if they would have been omitted.

As said, First of all, string constants are never garbage collected. Second of all, string constants are intern'd, which means they are shared across the entire VM. This saves memory. But it is not always what you desire.

The copy constructor on String allows you to create a private String instance from a String literal. This can be very valuable for constructing meaningful mutex objects (for the purposes of synchronization).

[Payel Bera]

Hi Rob Prime,

I still have a query on this topic :-

Below is my code and the output, kindly comment on the output

public class MyTest {

public static void main(String args[])
{
Integer i1 = new Integer (1000);
Integer i2 = new Integer (1000);
Integer i3 = new Integer (10);
Integer i4 = new Integer (10);
Integer i5 = Integer.valueOf("900");
Integer i6 = Integer.valueOf("900");
Integer i7 = Integer.valueOf("90");
Integer i8 = Integer.valueOf("90");

if(i1 == i2) System.out.println("i1 == i2");
else System.out.println("i1 != i2");
if(i3 == i4) System.out.println("i3 == i4");
else System.out.println("i3 != i4");
if(i5 == i6) System.out.println("i5 == i6");
else System.out.println("i5 != i6");
if(i7 == i8) System.out.println("i7 == i8");
else System.out.println("i7 != i8");


}
}


output:-

i1 != i2
i3 != i4
i5 != i6
i7 != i8

[Rob Spoor]

new Integer(xxx) will always create a new object, so it will never be equal (==) to any other object.
Although Integer.valueOf(int) does use a pool, Integer.valueOf(String) (the one you are using) will also create new objects each time.

[Payel Bera]

Rob Prime wrote:new Integer(xxx) will always create a new object, so it will never be equal (==) to any other object.
Although Integer.valueOf(int) does use a pool, Integer.valueOf(String) (the one you are using) will also create new objects each time.

Thank you ROB for your prompt reply. Highly appreciate your explanation.

[G.Sathish kumar]

Rob Prime wrote:new Integer(xxx) will always create a new object, so it will never be equal (==) to any other object.
Although Integer.valueOf(int) does use a pool, Integer.valueOf(String) (the one you are using) will also create new objects each time.

I feel it the above statement is wrong.

when we use new Integer for the same value it will not create new object because it is wrapper class, when check with hasCode() for two object we can get know (return same value) but when we use == operator it will return false because == operator check the reference value.

ex:
Integer i1 = new Integer(1);
Integer i2 = new Integer(1);

i1==i2 return false
i1.hasCode()==i2.hasCode() return true
i1.equals(i2) obviously return true because if hashcode value same then equals should return true.

rule is
-------
if equals method return true then hascode of two objects same
if hascode is not same then equals method return false
either senorios are vary

[Rob Spoor]

Are you not contradicting yourself? First you say "when we use new Integer for the same value it will not create new object because it is wrapper class", but then you show that i1 == i2 returns false. Wouldn't that return true if they were the same object? Yes the two object are equal according to both equals and hashCode, but they are still two separate object.

If you use new, you always create a new object. No exceptions, not even for String or the wrapper classes.

[Yosi Hendarsjah]

G.Sathish kumar wrote:
i1.equals(i2) obviously return true because if hashcode value same then equals should return true.

Two objects that have the same hash code are not necessarily equal. However, two objects that are equal have to have the same hash code.

[Jesper de Jong]

G.Sathish kumar wrote:when we use new Integer for the same value it will not create new object because it is wrapper class, ...

No, that's wrong. When you use new Integer(...) it will always create a new object, because using the new operator always creates a new object - the compiler does not have any special handling for wrapper classes.

G.Sathish kumar wrote:i1.equals(i2) obviously return true because if hashcode value same then equals should return true.

You are mistaken; when the hash code of two objects is the same, it does not mean that the value of the objects is the same. The hash code rule only works one way: When obj1.equals(obj2) returns true, then obj1.hashCode() == obj2.hashCode(). But not the other way around - two objects that have the same hash code may have different values.

[G.Sathish kumar]

HI

Thanks for your points.
i accept, i am wrong in my one point: i1.equals(i2) obviously return true because if hashcode value same then equals should return true --i feel i have done some typing mistake

but another point
Integer i1 = new Integer(1);
Integer i2 = new Integer(1);

System.out.println("\n first"+(i1==i2)); output is false --here only the reference variable is being checked so when we use new Integer(); it will create difference references but rest of theories(if same value then only one object in memory) about wrapper classes are same.

System.out.println("\n second"+(i1.hashCode()==i2.hashCode()));output is true

Jesper Young, you mentioned my statement (when we use new Integer for the same value it will not create new object because it is wrapper class, ...) is wrong but as per the above example i explained it correct only so i am wrong please explain with yours one example.

[Campbell Ritchie]

G.Sathish kumar wrote: . . . if hashcode value same then equals should return true . . .

No, that is incorrect. If equals returns true then the hashCode method returns the same result, but not vice versa.

[G.Sathish kumar]

Campbell Ritchie wrote:

G.Sathish kumar wrote: . . . if hashcode value same then equals should return true . . .

No, that is incorrect. If equals returns true then the hashCode method returns the same result, but not vice versa.

Sir
I have mentioned that statement in earlier of this thread and i accpted that it is wrong because of typing mistake.

[Campbell Ritchie]

Thank you for clearing that up.

[Jesper de Jong]

G.Sathish kumar wrote:Jesper Young, you mentioned my statement (when we use new Integer for the same value it will not create new object because it is wrapper class, ...) is wrong but as per the above example i explained it correct only so i am wrong please explain with yours one example.

If you do this:

Integer i1 = new Integer(1);
Integer i2 = new Integer(1);

Then you are creating two Integer objects. Variable i1 is referring to the first one, and i2 is referring to the second one. Both those Integer objects hold the value 1, but they are separate Integer objects. Note that the compiler does not do any special "tricks" with regard to wrapper classes - if you use the new operator, a new object will always be created - doesn't matter if the class you are instantiating is a wrapper class or some other random class. There is no special trick so that just one object will be created if there are two wrapper class instances with the same value.

Ofcourse, because the value of the two Integer objects is the same, i1.hashCode() == i2.hashCode() is true. That's because of the hash code rule: when obj1.equals(obj2) == true, then obj1.hashCode() == obj2.hashCode().

But note that that does not have anything to do with whether there is only one object, whether there are two objects, or whether obj1 == obj2. So you example does not say anything about whether there is only one Integer object or whether there are two Integer objects.

== checks if two variables refer to the exact same object.
.equals() checks if two objects have the same value.

What exactly is it that you don't understand yet?