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

VerifyError when accessing protected method in interface

    XMLWordPrintable

Details

    • Bug
    • Resolution: Duplicate
    • P3
    • None
    • 1.4.0
    • tools
    • generic
    • generic

    Description



      Name: rmT116609 Date: 11/12/2001


      java version "1.4.0-beta3"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
      Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)


      Javac compiles this example in violation of JLS 9.2. As a result, the VM throws
      a VerifyError:

      $ cat Blah.java
      class Blah {
        public static void main(String[] args) {
          I.Inner.bar(new I(){});
        }
      }
      interface I {
        class Inner {
          static void bar(I i) {
            try {
              i.finalize();
            } catch (Throwable t) {
            }
          }
        }
      }

      $ javac Blah.java
      $ java Blah
      Exception in thread "main" java.lang.VerifyError: (class: I$Inner, method: bar
      signature: (LI;)V) Bad access to protected data
              at Blah.main(Blah.java:3)

      According to JLS 9.2, interfaces only implicitly declare method signatures
      corresponding to the PUBLIC methods of Object, but not the protected methods.
      In external email, Gilad Bracha has told me that he took great pains to
      emphatically state that interfaces semantically DO NOT extend Object, even
      though that how it is implemented by the JVMS. Therefore, i.finalize() should
      not compile, because I does not have a member named finalize(). My little trick
      of using a nested class (with full access to any protected members of the
      enclosing type) should not have succeeded; but because it did, the result is a
      VerifyError.

      You may also want to link this bug to bug 4479715, where it is argued that the
      JLS permits things like "int clone();" in an interface. I'm not sure I like the
      implications of that, as it would make an interface non-instantiable, but it
      results from a literal reading of the JLS.

      These gaps in the JLS, coupled with behavior of javac which contradicts the JLS,
      makes it difficult to implement a 3rd-party compiler with the correct behavior.
      (Review ID: 135444)
      ======================================================================

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              rmandalasunw Ranjith Mandala (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: