what the benefit is by using annotation, like "@Immutable" ?
in [Java Help]
|
Prev: Immediate Start: Need Designer's (Visual/Graphic),Beverly Hills,California,
Next: a question about alias of reference
From: Lew on 17 Jul 2010 10:42 On 07/17/2010 05:36 AM, Lew wrote: >> String is the most basic immutable class in the API. Tom Anderson wrote: > Object? You're tardy to the party on that one. Asked and answered and driven to the depths of absurdity upthread already. -- Lew
From: Arved Sandstrom on 17 Jul 2010 13:47 Lew wrote: > Lew writes: >>> Object doesn't have attributes, so describing it as "immutable" >>> runs into a triviality exception. There's nothing to change, so >>> there's nothing to be immutable. String actually has attributes for > > Jukka Lahtinen wrote: >> This makes me wonder.. if you extend an immutable class, does it require >> the extending class also being immutable? > > No. It isn't classes that are immutable, it's instances. We say > "such-and-such class is immutable" as a shamefully inaccurate > colloquialism for "such-and-such class guarantees that all its instances > are immutable". I expect I'd be more insistent on that distinction in an OOP (or OOP-capable) language if the language being discussed were more object-centric, rather than being class-centric like Java (*). Sure, in Java it is actually the instances that are (im)mutable, but we enforce that in how we declare the _class_. >> If so, and Object were immutable, then EVERY class should be immutable. > > Object isn't immutable, objects are immutable. So when we say, "[An] > Object [instance] is immutable", clearly that imposes no restrictions on > subtype instances. > AHS * Becomes a moot point in OOP languages that don't have classes at all. -- We're surrounded. That simplifies our problem of getting to these people and killing them. -- Lewis B. Puller, North Korea, 1950
From: Mike Schilling on 17 Jul 2010 14:19 "Eric Sosman" <esosman(a)ieee-dot-org.invalid> wrote in message news:i1qchg$2pa$2(a)news.eternal-september.org... > On 7/16/2010 2:27 PM, Lew wrote: >> [...] >> >> String is the most basic immutable class in the API. > > More basic than Object? It's illogical, IMHO, to call a non-final class immutable, unless you can (somehow) ensure that all of its subclasses are immutable.
From: Jim Janney on 17 Jul 2010 14:35 Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: > On 7/17/2010 7:09 AM, Screamin Lord Byron wrote: >> On 07/17/2010 03:33 AM, Eric Sosman wrote: >>> On 7/16/2010 9:09 PM, Eric Sosman wrote: >>>> [...] For example, Map.Entry does not satisfy the JCIP >>>> notion of "immutable," although *I* (a person I consider reasonable) >>>> would categorize it as such. >>> >>> Well, *that's* a crock, isn't it? Map.Entry is not a class at >>> all, but an interface -- hence, neither "mutable" nor "immutable," >>> but just "ineffable." Still: According to the JCIP criteria, no >>> concrete Map.Entry implementation could be considered immutable, >> >> Are you saying that it's impossible to implement that interface in such >> a way that resulting class satisfies the JCIP notion of immutable? Is it >> only because of the setValue() method (for which documentation states >> it's optional operation)? >> >> >>> while I (still semi-reasonable) think most implementations should >>> in fact be considered so. >> >> I don't see any reason why those implementations wouldn't be considered >> as such according to JCIP definition. > > I'm so deep in the hole now that the only thing to do is > keep on digging ... Just forget my nonsense about Map.Entry -- > I blundered, and then I blundered again, and my next move will > probably be to drive the blunder bus right off a cliff. > > The bit of JCIP's "immutable" definition that I was trying > to call into question is the requirement that the object hold no > (accessible) references to mutable objects. That is, JCIP thinks > of an object's "state" as including not only the fields belonging > to the object itself, but all other objects that can be reached > via those fields. In JCIP's view, an object is mutable if it holds > a reference, direct or indirect, to any other mutable object; the > entire network of objects reachable from any one object is part of > that object's "state." > > I think JCIP's definition is over-broad, at least in some cases. > For example, in JCIP's view an unmodifiable Set (as created, say, by > Collections.unmodifiableSet()) is mutable if the elements contained > in the set are mutable. The membership of the unmodifiable Set can't > change -- you can't add() or remove() on it -- but if a member itself > changes its own state, JCIP says this changes the Set's state. That's > a view that makes sense in some applications, but (I believe) not in > all. We can imagine a Family class, say, that we'd like to consider > immutable because our application is not concerned with births and > deaths: > > class Family { > private final Set<Person> members; > Family(Person... members) { > Set<Person> set = new HashSet<Person>(); > for (Person p : members) > set.add(p); > this.members = Collections.unmodifiableSet(set); > } > ... > } > ... > Person dad = new Person("Dad"); > Person mom = new Person("Mom"); > Person junior = new Person("Junior"); > Person sis = new Person("Sis"); > Family fam = new Family(dad, mom, junior, sis); > > Now: Does `sis.earnDegree(new MBA())' change the "state" of the > Family? Is the degree an attribute of the Family, or is is solely > hers? JCIP's view is that it's both, that the Family "inherits" > (or "is contaminated by") all the attributes of all its members. > > In some applications that view makes perfect sense. Sis' new > degree could affect the result of `fam.estimatedEarningPower()', for > example: it's an asset that could influence the economic outlook of > the Family as a whole. But in a genealogical application, say, the > Family may just be a repository of its Persons, and the degrees its > members hold may be of no concern -- they'll show up when you print > out the bios of a Family's members, but they're not thought of as > being familial attributes. That is, the exact same Family class can > be thought of as "mutable" in one application and "immutable" in > another, without a single line of code having changed. > > I just wish I hadn't disgraced my own Family by picking such a > ridiculously bad example to start with ... When I think about immutability, it's usually in terms of objects that represent values: strings, numbers, geometric points, that kind of thing. Immutability is convenient here since it lets you ignore the difference between reference and value semantics. Allowing public references to mutable objects would interfere with that, but I don't know that my point of view is the right one. The JCIP people are interested in thread safety. They even claim that immutability implies thread safety, but that's not automatically true for lazily computed values. Java.lang.String is only thread safe because hashCode() is carefully written. -- Jim Janney
From: Lew on 17 Jul 2010 15:04
Jim Janney wrote: > The JCIP people are interested in thread safety. They even claim that > immutability implies thread safety, but that's not automatically true > for lazily computed values. Java.lang.String is only thread safe > because hashCode() is carefully written. This is significant - 'String#hashCode()' was very carefully written. <http://en.wikipedia.org/wiki/Idempotent> One wonders whether 'String#hashCode()' needed to be lazily loaded, but one forgives the Implementors on two counts: they were perhaps correct to think it would optimize such an ubiquitous class, and they gave us a good example of thread-safe-despite-unsynchronized-mutation, pseudo-immutable lazy loading. It is clear from the gestalt of comments in this discussion that the definition of "immutable" is mutable, needs must to adapt to different analytic purposes. -- Lew |