Legal program, compiled as prescribed by the JLS, gets IllegalAccessError

Consider the following class structure:

::::::::::::::
./pack/OffLimits.java
::::::::::::::
package pack;
 
class OffLimits { // Note this has default access
    public int x = 11;
}
::::::::::::::
./pack/Allowed.java
::::::::::::::
package pack;
 
public class Allowed extends OffLimits {
}
::::::::::::::
./Outsider.java
::::::::::::::
import pack.*;
 
public class Outsider extends Allowed {
    public static void main(String[] args) {
        System.out.println(new Outsider().x);
    }
}

The JLS section 13.1 states that "A reference to a field of another
class or interface must be resolved at compile time to a symbolic
reference to the class or interface in which the field is declared,
plus the simple name of the field." This means that the reference
to 'x' in Outsider must be compiled to the following:

        getfield Field pack/OffLimits.x:"I";

When this program is run, the VM gives the following error:

java.lang.IllegalAccessError: try to access class pack/OffLimits from class Outsider
        at Outsider.main(Outsider.java:5)

This is a bad situation. We have the compiler translating a legal
program into the JLS prescribed code and the VM is, essentially,
failing to verify the class.

[A similar example can be built using methods instead of fields.]

The VM was changed (when, 1.1?) so that it did not need the declaring
class. At some point, it became able to search up through the
superclasses looking for the method. Thus it can currently handle...

        getfield Field pack/Outsider.x:"I";

...even though there is no field 'x' explicitly declared in Outsider.

Possible solutions:

1. Change the access checks in the VM so that they check that the
   run-time type of the top stack position is allowed to see the
   field of the inaccessible class.

   Note: newly compiled programs with the offending pattern (above)
         would not cause 1.0 VMs to crash,
but the class file would still not verify.

2. Change the compiler to generate field references which always refer
   to the type of the expression, rather than the type of the declarer.

   Note: any newly compiled program would cause 1.0 VMs to crash.

3. Change the compiler the "new style" field references only where
   needed -- use the old style where it will work.

   Note: any newly compiled program would cause 1.0 VMs to crash
only when the offending pattern is in the program.

I am putting this bug in at a high priority, because it is a
problem for several people: this was a problem for the designers
of the JavaMail APIs. It also is a problem in the JCK: the positive
case of jck test clss07002 is failing because, now that the VM is
verifying the jck tests, the legal program which comprises that
test is failing to verify in the VM. This may also be the source
of the IllegalAccessError currently cropping up in HotJava, but I
haven't checked.

todd.turnidge@Eng 1998-02-13