Re: what the benefit is by using annotation, like "@Immutable" ?
On 07/16/2010 06:36 PM, Andreas Leitgeb wrote:
Lew<lew@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