>
>I've said this before but I'll repeat it. I don't think the JSR will have
>any chance of changing JNI to prevent modifications to final fields, for a
>variety of reasons. But it is also not necessary to prevent it. Use of
>native code turns off all safety guarantees and so we need not be concerned
>about what native code does with regard to synchronization, in general.
I feel pretty strongly about this. When somebody writes an article
for JavaWorld advocating the use of JNI to change final fields in
custom deserialization, I think we need one of three things to be
true:
* JNI throws an exception if an attempt is made to change a final field.
* I can go to the specification and point to a place where is says: "If you do
this, the semantics of your program are completely undefined, and your
VM can core dump or produce corrupt and non-typesafe results."
* The spec defines the semantics of using JNI to change final fields.
(This excludes the write protected fields such as System.in, for
which some special case will be provided).
I don't think any other answer is acceptable. If there is any idiom
that JVMs are going to be required to support, the semantics of the
VM must define that support. You can't have VM requirements that are
not supported by the semantics.
And if we don't declare using JNI to change final fields to be
broken, then you can count on somebody with poor taste using it and
then demanding that JVM's support it. And if they are an important
application/company, Sun will.
I don't feel strongly about whether JNI needs to throw an exception.
The spec just needs to say whether the semantics are defined. (If the
semantics are not
defined, at least the debug version of JNI should report an error).
This is similar to what happens when a constructor makes an object
visible to other threads before the object is completely constructed.
I don't recommend it, but the spec has to specify the semantics of
doing so.
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:31 EDT