Re: Support refs to private members over inner class borders

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Michael" == Michael Matz <matz@suse.de> writes:

>> Yeah, it allows it now, but it won't if you try `java -Xfuture'.
>> I.e., the bytecode in question is invalid.

Michael> I see.  But the direction inner->lookup->outer has to work,
Michael> hasn't it?  This also doesn't (without the patch at least).

The Java source code is correct, the problem is that the output of
`gcj -C' is wrong.  If you look at the bytecode generated by javac you
will see something different.  For instance instead of a `getfield'
you'll see something like:

 32: invokestatic #11=<Method Outer.access$200 ()java.lang.String>

Michael> Okay.  Though I obviously don't know what accessor method in
Michael> java sense are ;-).

The compiler should introduce package-private synthetic methods that
serve only to return or set fields that aren't accessible from inner
classes.  E.g., in the above, `access$200' is a method introduced by
the compiler.

Michael> Because in that case I will use it on the hammer branch, if
Michael> it's not totally bogus.

It is bogus in the sense that it is code we simply want to pull out
again later.  In the short term, well, we've never shipped a release
that made any promises about safety.  So from that perspective this
code is ok.

I think the bytecode works in `java' as a backward compatibility hack.
As far as I know all current compilers generate the accessor methods.
Note that this also fails if you use `java -verify' -- meaning that
this code is only accepted in a trusted context (as you would expect
since otherwise you could use this to violate the VM security).

gij is a little unusual in that it always verifies bytecode.

Tom