The internal ASM (and the external version) does not generate the correct constant pool entry for invokespecial and invokestatic instructions for non-abstract methods on interfaces.

Currently ASM will generate a CONSTANT_Methodref entry, rather than a CONSTANT_InterfaceMethodref. This in turn results in incorrect byte code of generated anon classes for lambda expressions and method references, that may result in possible VM-related errors.

A simple class exercises this aspect:

import java.util.function.*;

class A {
  interface I {
      default Supplier<Integer> a() { return () -> 1; }
      default Supplier<Integer> b(int i) { return () -> i; }
      default Supplier<Integer> c(int i) { return () -> m(i); }

      int m(int i);
      
      static Integer d() {
          return 0;
      }
  }

  static class C implements I {
      public int m(int i) { return i;}
  }

  public static void main(String[] args) {
      I i = new C();

      i.a();
      i.b(1);
      i.c(1);
      I.d();
  }
}

Compile and execute with:

java -Djdk.internal.lambda.dumpProxyClasses=. -cp . A

then analyze the byte code of the generated proxy classes, for example:

  javap -v -p A\$I\$\$Lambda\$1.class

Note this currently executes fine, even though the constant pool entry is incorrect (possibly indicating a byte code validation issue with the VM).