>> * 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