JavaMemoryModel: Native methods and Final fields

From: David Holmes (
Date: Thu Feb 22 2001 - 22:24:05 EST

It has been suggested that JNI should be modified to prevent assignment to
final fields and that, 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.

I don't think there is any chance because such a change would not be
backward compatible with existing code (no matter how badly we may think of
that code), nor would the performance implications be acceptable. Trying to
force a JNI change as part of the JMM JSR could stall the JMM JSR or even
cause it to fail.

I don't think there is any need for this change because code that uses JNI
already foregoes all of the safety guarantees that Java makes. If bad native
code causes the JVM to crash so be it - there is no attempt to prevent this.
Similarly if "bad" native code changes a final field and different threads
now see different values for this final field, then so be it. There should
be a warning/caveat about this in the JNI specification, but no more than
that. Further in debugging environments it may even be desirable to change
the values of final fields., System.out and System.err are an example of a very bad design
decision that Java will have to live with until they decide to release a
version that is allowed to break source compatibility. Until then VM's have
to special case these fields regardless of the JMM issues (they already hit
the problem of JITs inserting direct references and missing calls to setXX()

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
JavaMemoryModel mailing list -

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