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

From: Virgil Green (virgil.green_at_bunge.com)
Date: 12/19/03 

Date: Fri, 19 Dec 2003 00:49:17 GMT

"natG" <natgross.rentalsystems@verizon.net> wrote in message
news:TsnEb.85$0Y2.24@nwrdny03.gnilink.net...
>
> "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?
> -nat

The assumption is incorrect. b now points to a new object, but the TreeMap
still points to the object originally used to created the Map entry.
Remember, a *copy* of the reference contained by b was passed to the
tm.put() method (pass by value). The reference contained in b cannnot be
changed by the called method and the reference used by the called method
cannot be changed by altering b. And, since Integer is immutable, you cannot
alter the object that both these references reference either. The sort order
is maintained.

 - Virgil

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: 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: 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 ... You sent a reference to an Integer object (stored in varable ...
    (comp.lang.java.programmer)
  • Re: Indexing by multiple keys
    ... If you have two different keys, say a name string (reference) and a social-security-number string, that retrieve the same value from the same map, both keys need to go away for the value to be removed from the map. ...
    (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)