From: <###@###.###>

As part of JSR133, the expert group promised to discover and offer
suggested changes to make JDK code sensibly conform to the revised
memory model. Among the simplest but most important of these was to
identify core classes advertised as immutable but not using "final"
fields. These fields really must be declared as final to behave
correctly. Although breaches are extremely rare and hard to exploit,
it is important to revise them accordingly to make definite guarantees
that when for example, you create a Integer(3), no thread ever sees
its value as zero.

Looking only at the core libraries (lang, util), we've identified
the following classes, and have made versions with suggested changes.
lang:
  Boolean.java Character.java Float.java Package.java String.java
  Byte.java Double.java Integer.java Short.java
util:
  UUID.java

In most cases, this was just a matter of adding "final". Code inside
some constructors (mostly in class String) also needed a few other
minor rearrangements though.

There are of course no API changes. These are pure bug fixes.

To check that these changes do not affect performance, we've run
specJVM and specJJB using revised version, and didn't see any
consistent difference one way or the other. (While using finals in
general leads to a few more opportunities for optimizations, hotspot
doesn't much expolit these yet. Also, finals can disable a few code
reorderings but we can't see any observable performance effect.) I've
sent mail to ###@###.### asking if he knows of better tests; if he
does, we'll run them, but we don't expect to find any interesting
differences.

[ ... ]

- ###@###.###