>To prevent this security violation, the string fields should be declared
>as blank finals. The blank final declaration should ensure writes are
>immediately flushed under the proposed memory model.
>
>If we did not worry about the security violation, then the blank final
>declaration need not be used; if we say it is OK for the racy thread
>to read default field values.
This is essentially the proposal. Many of these behaviors are not
guaranteed under the current semantics or current JVM
implementations. On the other hand, the problem with seeing mutating
strings is a very remote possibility. It can only happen on certain
SMP systems, or with a strange set of compiler optimizations. It is
unlikely that the current security risk posed by this is higher than
any number of other problems (e.g., having Microsoft Outlook
installed anywhere on the planet). On the other hand, even if the
risk is remote, we should get it right.
One proposal that was discussed at JavaOne was to roll out new Java
compliance tests that try to verify that this trick cannot be used to
observe mutating strings. That way, if there are any platforms where
it can occur with any repeatability, they will need to fix it.
Rolling out these new tests would be easy and not require any spec
change, since the existing spec states that strings are immutable.
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:26 EDT