sujith Acharya wrote:Since Integer is immutable object, why it dont use same principle when we create Integer object with value more than 127?
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.
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
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?
@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?
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
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.Jesper Young wrote:I don't know why these constructors even exist (with public access) . . .
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.
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
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.
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.
Thanks
Sathish kumar
SCJP, SCWCD
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
G.Sathish kumar wrote:
i1.equals(i2) obviously return true because if hashcode value same then equals should return true.
G.Sathish kumar wrote:when we use new Integer for the same value it will not create new object because it is wrapper class, ...
G.Sathish kumar wrote:i1.equals(i2) obviously return true because if hashcode value same then equals should return true.
Thanks
Sathish kumar
SCJP, SCWCD
No, that is incorrect. If equals returns true then the hashCode method returns the same result, but not vice versa.G.Sathish kumar wrote: . . . if hashcode value same then equals should return true . . .
Campbell Ritchie wrote:
No, that is incorrect. If equals returns true then the hashCode method returns the same result, but not vice versa.G.Sathish kumar wrote: . . . if hashcode value same then equals should return true . . .
Thanks
Sathish kumar
SCJP, SCWCD
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.