>
>Compilers would be required to have special knowledge of these
>classes.
Actually, it would be possible to write these classes using existing
Java semantics by using synchronization. It wouldn't be as fast as
incorporating them into the JVM. But it would provide a nice bridge
until people get their JVM's changed.
However, I'm not sure this is a direction I'd push.
As far as arrays of final elements, we only need the guarantee
against seeing stale values on SMP's with weak memory models. Nobody
is going to switch to a slower, more awkward data structure just for
that.
In favor of the idea that if we do it at all, we should do it at the
language level: this would allow functions such as Class.getSigners()
to return a reference to a final array of signers, rather than making
a copy each time getSigners is invoked (expensive) or returning a
reference to an unfinal array (implemented this way originally, an
serious security hole that has now been closed).
But neither form of final array can be used to make String immutable
unless we copy the array of characters when we create the String.
As far as volatile, I like the idea that a volatile boolean flag can
be used to guard any arbitrary data. It allows us to fix things like
the double check idiom just by making a field volatile, and allows
lots of other nice idioms.
THere is still some use for volatile arrays, but I think the set of
people who would use it (correctly) is very tiny -- Doug and a
handful of other people.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT