what the benefit is by using annotation, like "@Immutable" ?
in [Java Programming]
|
Prev: Immediate Start: Need Designer's (Visual/Graphic),Beverly Hills,California,
Next: Ordering of hashtable keys
From: Andreas Leitgeb on 16 Jul 2010 18:36 Lew <lew(a)lewscanon.com> wrote: > Object doesn't have attributes, so describing it as "immutable" > runs into a triviality exception. While not even displayed by javap on java.lang.Object, it actually does contain a mutable word: the lock. PS: I think I read that somewhere - or maybe my aunt's neighbour's ...'s ... oh, and jvisualvm seems to hint towards it, too. But then again, the monitor may not count as a field... PPS: after agreeing on the monitor not counting, Object is indeed immutable - but unlike String, Object doesn't prevent mutable subclasses.
From: Lew on 16 Jul 2010 19:46 On 07/16/2010 06:36 PM, Andreas Leitgeb wrote: > Lew<lew(a)lewscanon.com> wrote: >> Object doesn't have attributes, so describing it as "immutable" >> runs into a triviality exception. > > While not even displayed by javap on java.lang.Object, it actually > does contain a mutable word: the lock. The lock state is considered independently of the object state /qua/ object state. Otherwise two things: there is no such thing as an immutable instance, and we must always mention monitor state when considering instance state. The definitions of those two things, immutable instance and instance state, in practice always exclude monitor state. We talk about monitor state and its effect on object state, more evidence of conventional separation of the two. So let's agree that inclusion of monitor state trivializes the discussion of immutability and unnecessarily complicates that of instance state, and exclude monitor state from those two conversations as an orthogonal concern. > PS: I think I read that somewhere - or maybe my aunt's neighbour's > ...'s ... oh, and jvisualvm seems to hint towards it, too. > But then again, the monitor may not count as a field... > > PPS: after agreeing on the monitor not counting, Object is indeed > immutable - but unlike String, Object doesn't prevent mutable > subclasses. String prevents any subclasses. Even the immutable subclasses of Object have a monitor. All objects potentially have altered states even when immutable, if certain constructor antipatterns pertain. We'll exclude those as violations. In a related vein, String is immutable in its public interface but not internally with its 'hash' member. Jim Janney pointed out: > even String has a non-final field. The field in question is private, and does not change the externally observable state. So the String instance acts like it's immutable, but has mutable internal state. So in a real sense String is mutable, and just as real, it's immutable. The mutability of String is idempotent, hence its lack of visibility to clients. Not all classes are so designed. Without synchronization or other care, such "externally immutable" classes may incur unexpected states internally. In real life those errors can be discernible, perhaps in performance issues if not correctness. In String's case the lazy-load optimization might actually help; whether noticeably is another matter. -- Lew
From: Eric Sosman on 16 Jul 2010 21:09 On 7/16/2010 6:36 PM, Andreas Leitgeb wrote: > Lew<lew(a)lewscanon.com> wrote: >> Object doesn't have attributes, so describing it as "immutable" >> runs into a triviality exception. > > While not even displayed by javap on java.lang.Object, it actually > does contain a mutable word: the lock. > > PS: I think I read that somewhere - or maybe my aunt's neighbour's > ...'s ... oh, and jvisualvm seems to hint towards it, too. > But then again, the monitor may not count as a field... This gets back to Jim Janney's point that there's no truly solid definition of "immutable" that satisfies every need. If we say an object is "mutable" if it has observable state (that is, something that can cause executable code to behave in different ways at different times), then every Java object is "mutable" in the sense that its monitor can be held or not held, affecting the behavior of any executable code that then tries to acquire it. This encourages us to say things like "Monitors don't count," but then we start thinking about other things that might not quite satisfy a plausible definition of "immutable" -- like String's lazily-computed hash code, for example. And then we get to "If it's not a monitor and not directly observable from outside, it doesn't count," and the short word "immutable" starts to disappear behind a veil of caveats, codicils, and cavils. The cited net.jcip.annotations.Immutable propounds a definition of "immutable" that I think reasonable people would term "sufficient," but that others would think "not necessary:" Surely any class meeting the JCIP criteria would be called "immutable," but many classes that do *not* meet it might well be considered "immutable" by other, equally reasonable people. For example, Map.Entry does not satisfy the JCIP notion of "immutable," although *I* (a person I consider reasonable) would categorize it as such. "Immutable" means "not mutable." It sounds solid, but I think it trails off into "Mutable by whom?" and "Mutable in what ways?" and "What would Werner Heisenberg's cat think?" A squishy, relativistic notion when you start to probe at it. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Eric Sosman on 16 Jul 2010 21:33 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, while I (still semi-reasonable) think most implementations should in fact be considered so. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Kevin McMurtrie on 17 Jul 2010 03:20
In article <i1q31n$jgl$1(a)news.boulder.noaa.gov>, www <www(a)nospam.com> wrote: > I wrote an immutable class. By following the samples of tutorials, I > also added "@Immutable" right above the class name. > > import net.jcip.annotations.Immutable; > > @Immutable //<--- what is this benefit? Without this line, the code is > also ok. Does this line make any difference? > public class MyClass > { > ... //all the code > } > > Thank you very much. Ha! C++ 'const' lives! Well, almost. Compiler enforcement would be helpful for avoiding the mistake of sharing something that's unexpectedly mutable. It might even help HotSpot eliminate some memory syncing, which is expensive when there are a lot of CPUs. -- I won't see Google Groups replies because I must filter them as spam |