Re: Why doesn't Integer have a setValue(int i), and is there a way of changing its value.

From: bagbourne (noway_at_noway.com)
Date: 12/20/03 

Date: Sat, 20 Dec 2003 16:03:57 +0000 (UTC)

natG wrote:

> "Bent C Dalager" <bcd@pvv.ntnu.no> wrote in message
> news:brsjhp$t6r$1@tyfon.itea.ntnu.no...
>
>>In article <vu3hd8iad8546c@corp.supernews.com>,
>>Alex Hunsley <lard@tardis.ed.ac.molar.uk> wrote:
>>
>>>natG wrote:
>>>
>>>
>>>>Can you please explain "safer"? Do I practice SAFE Java<g>?
>>>>Seriously, safer in what respect?
>>
>>Two cases spring immediately to mind.
>>
>>If you use instances of the class as keys in a Map, or you have them
>>in a Collection that you expect to always be sorted, then immutability
>>guarantees that your sorting won't inadvertantly get screwed up by
>>someone calling a setter at inopportune times. With immutable keys,
>>the only thing that can mess with your sorting is when the
>>Collection's setters are called. The alternative to immutability would
>>be for the class to fire events whenever you changed something and the
>>Collections classes to be sensitive to such events and be able to
>>auto-resort themselves, but this gets real messy real quick.
>
>
> Question: Suppose:
> Integer a = new Integer(10);
> Integer b = new Integer(20);
> Integer c = new Integer(30);
> TreeMap tm = new TreeMap();
> tm.put(a);
> tm.put(b);
> tm.put(c);
> And then:
> b = new Integer(60);
> Now, I assume that the second Integer added to the Map, will return an int value
> of 60.
> If so, what happens to the sort at that point?

You have a fundamental misunderstanding. I'm surprised nobody picked up
on this. You sent a reference to an Integer object (stored in varable
named "b") to TreeMap.put(). It stored that reference.

Then you create a *totally new instance* of an Integer with 60 in it,
and put a reference to that object into variable b.

That has nothing to do with the reference that you previously put into
the TreeMap.

If it helps, think of object variables as smart pointers that cannot be
corrupted to point to anything else other than what they were declared as.

When you assign using "=", you just change the variable to *reference*
that new object.

Relevant Pages

  • Re: Why doesnt Integer have a setValue(int i), and is there a way of changing its value.
    ... With immutable keys, ... The alternative to immutability would ... Now, I assume that the second Integer added to the Map, will return an int value ... > this has the potential of being a security problem. ...
    (comp.lang.java.programmer)
  • Re: Why doesnt Integer have a setValue(int i), and is there a way of changing its value.
    ... With immutable keys, ... The alternative to immutability would ... > Now, I assume that the second Integer added to the Map, will return an int ... a *copy* of the reference contained by b was passed to the ...
    (comp.lang.java.programmer)
  • Re: Hashtable values seems not probably retrieved...
    ... The reason you're getting the same ... >> object for both keys is because you're STORING the same object for both ... >> doesn't make a copy of the object at the time you add it to the map. ... reference, can change that reference to another object. ...
    (comp.lang.java.programmer)
  • Re: memory leak or not?
    ... Said by probably the record holder of long newsgroups threads. ... The string is immutable what you are showing is not a reference. ... or else you don't really understand references and immutability. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Dangling pointers and saving references to file in C.
    ... But I wouldn't consider keeping absolute indices into an array a good ... Adeo manages reference serialization (which is what we're talking ... a map is loaded, after the entire map is loaded, the engine does a ...
    (rec.games.roguelike.development)