>It has been suggested that JNI should be modified to prevent assignment to
>final fields and that System.in, System.out and System.err should all be
>treated as special cases.
>
>While it makes sense not to be able to modify final fields via JNI I don't
>think that there is any chance of making this change, nor in fact is there
>any need.
>...
>
>So the JMM can define the rules for final fields as per Bill Pugh's and
>Jeremy Manson's "Semantics of Multithreaded Java" paper without any concern
>for JNI or the System fields.
>
>David Holmes
No reasonable program would involve native code casting an random
number into a pointer and then storing into that pointer, so I don't
worry about giving semantics for that case.
If there were idioms that were being used all the time in production
codes, I think they should have well defined semantics. So if lots of
code is using native methods to change final fields, we need to
define the semantics of doing so.
We also need to provide work-arounds for things like serialization.
I would have no objection to providing a native method that would
allocate a instance of a class and then set all the fields of the
object (including final fields), without calling the constructor. Of
course, there are severe security implications of such a method,
which is why the method is only accessible from native code. I
believe that this method for constructing objects could be used to
implement (de-)serialization.
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:30 EDT