Re: RFC: fix PR 28892

[David Daney <ddaney at avtrex dot com>]

Andrew Haley wrote:
> David Daney writes:
>  > Tom Tromey wrote:
>  > >>>>>>"Andrew" == Andrew Haley <aph@redhat.com> writes:
>  > > 
>  > > 
>  > > Andrew> I'd have made it WONTFIX.  Sadly, however, there seems to be no rule
>  > > Andrew> in the specification that forbids final fields being rewritten in
>  > > Andrew> methods other than clinit.
>  > > 
>  > > In this case I don't think the fields are being rewritten -- they are
>  > > simply being initialized by a different function.
>  > > 
>  > > Andrew> This makes some optimizations harder.  I think we need a flag to tell
>  > > Andrew> gcj that what we are compiling may not be Java code.  Then we can do
>  > > Andrew> better optimizations when we know that it is.
>  > > 
>  > > Unfortunately I think final fields may be changed via reflection.
>  > > 
>  > 
>  > Is this behavior specified anywhere?
>  > 
>  > I have not carefully read JLS 3, but IIRC in the good old days, it was 
>  > kind of unspecified behavior.
>
> Well, if you can find that in JLS 2 you're better at reading specs
> than me!  There are some restrictions on putfield, but I can't see
> that one.

Well I think I found the relevant documentation.  The JLS defers to the 
API documentation for things in the standard library.

Look in: http://java.sun.com/j2se/1.5.0/docs/api/

The documentation for java.lang.reflect.Field.set(Object,Object) says:

"If the underlying field is final, the method throws an 
IllegalAccessException unless setAccessible(true) has succeeded for this 
field and this field is non-static. Setting a final field in this way is 
meaningful only during deserialization or reconstruction of instances of 
classes with blank final fields, before they are made available for 
access by other parts of a program. Use in any other context may have 
unpredictable effects, including cases in which other parts of a program 
continue to use the original value of this field."

Earlier versions of the JDK specified that an IllegalAccessException was 
thrown unconditionally, but I think behaved in the manner documented for 
 JDK 1.5.

If you try to modify a final field directly (after it has been set) the 
verifier must reject the code.  So the only option would be to use 
reflection, for which it is only supposed to work in a very narrow set 
of circumstances.

David Daney.