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

invokestatic: IncompatibleClassChangeError is thrown instead of AbstractMethodError

    XMLWordPrintable

Details

    Description

      Consider the following case:
         public interface I1 { default public void m() {}}
         public interface I2 extends I1 { public void m(); }
         public class T3 implements I2 {}

      Call site: T3 { invokestatic T3.m()V T3 }

      NB: T3 isn't marked as abstract.

      VM: IncompatibleClassChangeError: Expected static method p1.T3.m()I
      JVMS: AbstractMethodError should be thrown

      Please, note that if I1.m is absent, AME is thrown as expected.

      JVMS-5.4.3.3. Method Resolution
      "[I]f method lookup succeeds and the method is abstract, but C is not abstract, method resolution throws an AbstractMethodError."

      JVMS-6.5 invokestatic.
      "Linking Exceptions
      During resolution of the symbolic reference to the method, any of the exceptions pertaining to method resolution (§5.4.3.3) can be thrown.
      Otherwise, if the resolved method is an instance method, the invokestatic instruction throws an IncompatibleClassChangeError."

      ILW = HLM = P3

      I = H = JVMS violation; though error mismatch isn't that serious, it adds noise into the results and hinders results analysis of default method security testing
      L = L = forbidden by JLS, but separate compilation may be a source of that
      W = M = Incorrect exception can be "translated" if necessary

      Attachments

        Issue Links

          Activity

            People

              hseigel Harold Seigel (Inactive)
              vlivanov Vladimir Ivanov
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: