aspose file tools*
The moose likes Java in General and the fly likes Creation of Ineger Wrapper Object Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Creation of Ineger Wrapper Object" Watch "Creation of Ineger Wrapper Object" New topic
Author

Creation of Ineger Wrapper Object

sujith Acharya
Ranch Hand

Joined: Dec 25, 2006
Posts: 60
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
author
Sheriff

Joined: Sep 28, 2004
Posts: 19059
    
  40

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

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19781
    
  20

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
sujith Acharya
Ranch Hand

Joined: Dec 25, 2006
Posts: 60
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
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14420
    
  23

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.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19781
    
  20

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
Sheriff

Joined: Oct 13, 2005
Posts: 40027
    
  28
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
Ranch Hand

Joined: Apr 12, 2009
Posts: 449

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).

http://muhammadkhojaye.blogspot.com/
Payel Bera
Greenhorn

Joined: Jan 28, 2010
Posts: 10
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
Sheriff

Joined: Oct 27, 2005
Posts: 19781
    
  20

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
Greenhorn

Joined: Jan 28, 2010
Posts: 10
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
Ranch Hand

Joined: Jul 27, 2009
Posts: 84
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


Thanks
Sathish kumar
SCJP, SCWCD
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19781
    
  20

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
Ranch Hand

Joined: Oct 02, 2003
Posts: 164
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
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14420
    
  23

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
Ranch Hand

Joined: Jul 27, 2009
Posts: 84
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
Sheriff

Joined: Oct 13, 2005
Posts: 40027
    
  28
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
Ranch Hand

Joined: Jul 27, 2009
Posts: 84
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
Sheriff

Joined: Oct 13, 2005
Posts: 40027
    
  28
Thank you for clearing that up.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14420
    
  23

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:

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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Creation of Ineger Wrapper Object