> Thinking about the problems with native code changing final fields
> got me thinking about a different problem.
>
> I suspect there are lots of tools that analyze a program and make
> decisions such as:
> Well, although this field is of type Object, the field is private
> and all the putfields in the class put a String into the field,
> so I can deduce that the field will always hold a String and inline
> virtual methods invoked on what this field references.
>
> The problem with this is that there is no way for compilers to look
> at native code, and the SetField JNI calls don't respect private
> annotations.
>
> All kinds of things, such as escape analysis, get trashed if you have
> to account for unknown native code.
>
> Reflection can have much of the same effects. With the right run-time
> permissions, you can read and set private fields.
In our Java compiler, we assume that native code correctly obeys
the access restrictions. If native code does access fields it isn't
supposed to be able to access, things can go very wrong. If the
programmer wants to access the field correctly, he should declare the
field in such a way that the native code is allowed to access the
field. Otherwise, you're trying to subvert the language: be prepared
for surprises.
Reflection is a bit more difficult a problem, because the
overriding of access control is explicitly sanctioned with the
java.lang.Reflect.setAccessible method (a similar problem occurs with
the java.lang.System.setIn/Out/Err methods). Our current plan is to
assume that code doesn't do anything nasty with reflection, and issue
a warning (and possibly disable the optimizations) if the
setAccessible method is ever used.
-Keith
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT