Re: JavaMemoryModel: Serialization and final fields

From: Joshua Bloch (jbloch@eng.sun.com)
Date: Fri Aug 27 1999 - 01:48:21 EDT


>> * Say that in general, it is acceptable to have native code change
>> final fields.
>
>Or merely say that no memory-based guarantees of any kind can be made
>about final fields that are modified by native code. Which seems like
>an intrinsically true statement that ought to be there anyway.

   Yes, as a general rule, native methods can do anything, including
scribbling over memory.

>I don't know what to think about clone() though. Luckily it is so
>broken that people don't use it much,

    I wish this were true, but it's not. They use it all the time, even
though it's very broken.

>but still, it is a much worse
>problem than deserialization or System.in since the global-barrier
>solution seems way too heavy there. (On the other hand, horrible
>performance on multiprocessors would add just one more reason not to
>use it.)

    Yep.

                         Josh



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:18 EDT