...

...

Write a class with the following properties:

1. All fields are private.

2. Only the constructors modify fields.

3. A constructor only modifies fields in the object it is constructing,
not in any other instance of the class.

Instances can still be modified by reflection-abuse, but for all normal
purposes they are immutable.

Patricia

    "Immutable" is a fuzzily-defined concept.  For example, it
is common to say that String is immutable, even though some of
its internal state can change after the String has been created
(as by hashCode, for example).

    One might say that the object is still "immutable" if the
changes to its internal state are not "visible" outside the
object itself.  In the case of hashCode, one might argue that
there is no way for the caller to detect whether the returned
value was freshly-computed or was cached.  And yet, there might
in fact be a way to do so: If you made very careful timings of
hashCode on a very long string, you might be able to observe
that the first call took longer than subsequent calls; does
this amount to a difference in behavior?

    For that matter, it is in fact possible to "change" an
existing String object in such a way that, say, charAt(0)
returns different values at different times.  (You use what
Patricia Shanahan calls "reflection abuse" to find the char[]
array underlying the String, and then you change the values
of the array elements.)  So it turns out that that String is
only immutable in the face of "normal" operations -- which
really says only that String cannot be changed unless you
change it!   By that definition, *every* class is "immutable:"
just label any value-changing operations as "abnormal."

    But let's go ahead and restrict ourselves to "normal"
operations.  Can we get visible changes in behavior from
our immutable Strings?

    // synchronized ("string")
    {
       Thread t = new Thread(new Runnable() {
           public void run() {
           synchronized ("string") {
                   System.out.println("in thread");
               }
           }
       });
       t.start();
       System.out.println("thread started");
       t.join();
       System.out.println("thread finished");
    }

Clearly, the code's visible behavior -- its output -- depends
on whether the first line is or isn't commented out.  What is
the difference?  In one case the second thread can run to
completion, and in the other it cannot.  What is the reason for
this difference?  It has to do with whether the String "string"
is or isn't locked -- that is, it has to do with the state of
the supposedly immutable object "string".  A change in the state
of "string" produces a change in the behavior of the program; how
can we keep straight faces while we talk about this state change
and still say "immutable?"

    Immutability is a useful concept, but hard to pin down with
exactitude.  "I know it when I see it," as Justice Potter Stewart
said of another notion; the fact that he could do no better is
evidence for the existence of things that seem easy to understand
but prove hard to define.  I believe "immutability" is one such.

C++ allows both "passing pointers by value" like Java and "passing by
reference".  The semantics of both are precisely defined.  One thing I would
not accuse C++ of is "lack of rigor".