Re: what the benefit is by using annotation, like "@Immutable" ?

From:

Jim Janney <jjanney@shell.xmission.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sat, 17 Jul 2010 20:57:22 -0600

Message-ID:

<2p7hktxzsd.fsf@shell.xmission.com>

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> writes:

Jim Janney wrote:

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.

Well, right or wrong I'm in agreement. IMHO it is not sufficient for
a supposedly immutable type to only ensure that the data it is storing
directly is immutable. It can only store data that itself is also
immutable. Otherwise, the various benefits that go along with
immutability no longer apply.

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.

Huh? In what way is hashCode() for java.lang.String "carefully written"?

I mean sure, there are ways that it could have been written
incorrectly. The main (only?) non-thread-safe mistake being to use the
"hash" field itself as the accumulator for the calculation. But
otherwise it seems like a pretty straightforward, obvious
implementation to me (not counting the fact that if a string has the
great misfortune to actually have a hash code of 0, the hash code will
be recomputed every time hashCode() is called).

Mainly, it's thread-safe not because any particularly increased care
was taken in writing the method, but rather because the things that
hashCode() relies on are not going to change after the class has been
initialized, and so even if the "hash" value has been calculated in
one thread but not yet visible in another, the worst that can happen
is that it gets calculated again.

I'd say that being immutable _does_ imply thread safety, even for
lazily computed values. The only way that assumption would break is
if the lazily computed values depends on something other than what's
in the class itself, in which case I'd say the class is broken.

I'm open to being proven wrong if someone has a counter-example.

public class SannyCode {
   private final String s;
   private boolean calculated = false;
   private long code = 0;

   public SannyCode(String s) {
      this.s = s;
   }

    public long getCode() {
        if (!calculated) {
            calculated = true;
            for (int i = s.length() - 1; i >= 0; i--) {
                if (s.charAt(i) != '-') {
                    code += i;
                }
            }
        }
        return code;
    }
}

Instances of SannyCode are immutable, in the context of a single
threaded application, but they are not thread-safe.

--
Jim Janney