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

From: natG (natgross.rentalsystems_at_verizon.net)
Date: 12/18/03


Date: Thu, 18 Dec 2003 19:44:51 GMT


"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

> Also, for String, allowing it to be changed at any time would be a
> security hazard when used within security-sensitive library
> functions. As an example, I could send in username "guest" and
> password "guest" as Strings to some function and then at some later
> time, after I had been authenticated, change the contents of the
> username String to "root". Unless the library was carefully written,
> this has the potential of being a security problem. As things are, the
> fewer of these pitfalls exist, the better.
>
> How many of your methods take some object instance as parameter, hang
> on to it and expect it not to change thereafter? Any that do are
> vulnerable to malfunction when the instance gets mutated from the
> outside.
>
> >[top posting fixed]
>
> Thank you :-)
>
> Cheers
> Bent D
> --
> Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
> powered by emacs



Relevant Pages