Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4112313

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



    • linux-beta
    • generic
    • solaris_2.5.1


      Consider the following class structure:

      package pack;
      class OffLimits { // Note this has default access
          public int x = 11;
      package pack;
      public class Allowed extends OffLimits {
      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


        Issue Links



              gbrachasunw Gilad Bracha (Inactive)
              tturnidgsunw Todd Turnidge (Inactive)
              0 Vote for this issue
              1 Start watching this issue