At line 2, Integer literal 13 will be boxed to Integer object and same i will now refer to this new Integer object. You previous Integer object will still be in heap and eligible for GC.
Its not the same object which gets updated. Thats why they are immutable.
Immutability means their content can't be changed. You can call it final object just like final reference variable can't refer to some new Object.
Originally posted by Ernest Friedman-Hill:
And to make this even more concrete: "immutable" means there is no method anything like "setNewValue(int)" which changes the value represented by a given Integer object.
Originally posted by Ken Blair:
Do you agree or disagree?
Originally posted by Ken Blair:
Well, not quite because of a rule in the JLS about values from -128 through 128 I don't think the instance is eligible for GC at all. A later boxing to 13 would be required to box to the same instance of Integer.
Originally posted by Ken Blair:
A class that is declared final has nothing to do with mutability and isn't at all the same as declaring a variable final so I wouldn't call it a 'final object'.
Originally posted by Naseem Khan:
Ken can you please tell me how many object will be created here..
Integer i=5;
Integer i1=(i+1);
Originally posted by Naseem Khan:
Well I have not said anywhere if class is declared final. Then object will be immutable.
Immutability means their content can't be changed.
Tony Morris
Java Q&A (FAQ, Trivia)
Tony Morris
Java Q&A (FAQ, Trivia)
Undefined. The Integer instances they are boxed to may or may not have already been created. The JLS requires that for values between -128 and 127 any two boxing conversions return equal references. I suppose it might be possible for an implementation to do this without literally using the same Integer instance but it's a good bet that almost all of them do. Whether or not the instance is cached eagerly or lazily and whether or not the boxing conversion has occurred before or not would be two factors affecting whether or not any object is actually created.
Originally posted by Naseem Khan:
SOP(i==i2) returns false.
Originally posted by Naseem Khan:
The range -128 to 127 comes into picture if
1. Both objects are created without new.
2. Both objects have same int value.
3. Wrapper object must be of type Byte, Short or Integer.
Originally posted by Naseem Khan:
When all the above conditions apply, then range comes into picture.
Byte b1=5;
Byte b2=6;
Both objects are not same. b1==b2 will return false.
But if..
Byte b1=5;
Byte b2=5;
Then b1==b2 will return true. Here 5 is in the range and type of b1 & b2 is Byte
Naseem
#3 is inaccurate.
"I'm not back." - Bill Harding, Twister
If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.
When you talk about this range (-128 to 127), then two Wrapper objects will be cached only if same primitive is boxed and the wrapper objects are either Byte, Short or Integer. But not Long.
Thats why I just mentioned only three wrappers.
e.g., here is no caching.
Long l1=(long)2;
Long l2=(long)2;
Two different objects will be created here.
Originally posted by Jim Yingst:
[Naseem]: When you talk about this range (-128 to 127), then two Wrapper objects will be cached only if same primitive is boxed and the wrapper objects are either Byte, Short or Integer. But not Long.
Not exactly. Byte, Short, and Integer are the three types that are required to cache instances in the range -128 to 127. (Character is required to cache, but only in the range 0 to 127). However it's possible for classes to cache over a wider range than they are required to. It's also possible for classes which are not required to cache at all, to cache nonetheless. Case in point: in JDK 5, look at the source code for Long.valueOf(). This class caches values from -128 to 127, exactly like Byte, Short, and Int, even though it's not required to. In another JDK you may discover they do something else entirely. You must remember that the JLS gives minimum requirements for caching, but implementations are allowed to exceed that minimum requirement.
[ July 12, 2006: Message edited by: Jim Yingst ]
"I'm not back." - Bill Harding, Twister
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
We had a couple ways to approach "immutable". To paraphrase crudely one said there are no APIs provided to change values (excluding reflection which breaks all rules) and the other said the behavior will be the same for ever and ever, amen.
Are these views both necessary? Both correct?
Would a clock be immutable? I can't change it, but the value it returns changes every millisecond.
I wouldn't say that is correct. Certain classes in the standard API -- such as Integer, Long, and so on -- are object wrappers for primitive values. These particular classes are immutable. And that's what all the discussion in this thread has been about. But it's perfectly possible to write a wrapper class that is mutable, and it's done all the time. There's no relationship between the concepts "wrapper" and "mutable".Originally posted by Daniel McCracken:
Let the admitted (Java) greenhorn rephrase; is this correct?
Wrapper objects are immutable, language theory issues aside, in the same sense that strings are immutable: anytime a greenhorn might _think_ an object is being changed, what actually happens is that a new object is created.
Originally posted by Paul Clapham:
And to hopefully clear up the standard beginner confusion, you can only change an object by calling one of its methods. When you see an assignment being made (by the = operator), you are changing a variable. A variable cannot contain an object, it can only contain a reference to an object. If you change that variable by assigning it a reference to a different object, that does not change either of the objects involved.
Originally posted by Daniel McCracken:
Thanks for the helpful information. Nobody was born knowing all this stuff.
Tony Morris
Java Q&A (FAQ, Trivia)
No they weren't, but it has been known since well before I was born what immutable means (and I'm nearly ready to play in the Masters comp!). All functions are referentially transparent - everything else is a spin, convolution or diversion from this very simple and accurate definition. Additional convolution comes about in the Java context since Java has no such proof of referential transparency (though I've seen some very ambitious (but doomed to fail as per mathematics) attempts).
Originally posted by Daniel McCracken:
Sigh. There are lots of things I don't know. One proven way to learn is to ask questions, risking sounding stupid in the process. I can handle that. I tell my students that the only stupid question is the one they don't ask. If by chance a student asks a question that goes _too_ far back into things they should have known, I talk with the student privately. I never use ridicule or sarcasm, privately or publicly. I kmow of no study demonstrating their effectiveness in teaching!
Tony Morris
Java Q&A (FAQ, Trivia)
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |