JLS and JVMS SE8 Disagreement: Method Resolution Behavior with Multiple Maximally-Specific Default Methods

[Alex Buckley]

Hi John,

The ICCE is specified in JVMS 6.5, in the "Run-time Exceptions" section 
of invoke{interface,special,virtual}. It is this ICCE that JLS 13.5.6 
relies on when describing whether adding a default method is binary 
compatible.

The thing to remember is that resolution (JVMS 5.4.3.3) is just a 
preliminary step in the execution of invoke* bytecodes. It "starts" from 
the static type named in a symbolic reference. Selection (JVMS 6.5) is a 
distinct and fussier step. It "starts" from the dynamic type of the 
receiver object.

Alex

On 12/31/2014 12:51 PM, John Vilk wrote:
> Hello,
>
> I recently noticed a disagreement between the JLS and the JVMS for SE8
> concerning the scenario where multiple direct superinterfaces of a class
> provide a default method for a method reference with the same name and
> signature. I believe this is a bug in the JVM specification, which
> specifies behavior that is not present in the reference implementation of
> the specification, and which differs from the behavior specified in the JLS.
>
> The JVM specification states the following should occur in the section on
> method resolution, §5.4.3.3
> <http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.3>,
> should there be no single maximally-specific default method (meaning, there
> are multiple) (emphasis mine):
>
> Otherwise, if any superinterface of C declares a method with the name and
> descriptor specified by the method reference that has neither its
> ACC_PRIVATE flag nor its ACC_STATIC flag set, *one of these is arbitrarily
> chosen and method lookup succeeds.*
>
> However, the JLS specification states the following in the section on
> Interface Method Declarations in the binary compatibility chapter, §13.5.6
> <http://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.5.6>:
>
> Adding a default method, or changing a method from abstract to default,
> does not break compatibility with pre-existing binaries, but may *cause an
> IncompatibleClassChangeError if a pre-existing binary attempts to invoke
> the method.*
>
> This section of the JLS contains a full example that exemplifies the
> specification bug I am describing in this email. In particular, the JLS
> states:
>
> If Cowboy is recompiled but not CowboyArtist, then running the new binary
> with the existing binary for CowboyArtist will link without error *but
> cause an IncompatibleClassChangeError when main attempts to invoke draw().*
>
>
> However, this behavior description is in contrast to the JVM specification,
> which claims that one of the draw methods should be arbitrarily chosen and
> invoked.
>
> Using separate compilation on the example, I verified that the JVM does, in
> fact, throw an IncompatibleClassChangeError, which disagrees with the
> behavior specified in the JVMS:
>
> $ java example/CowboyArtist
> Exception in thread "main" java.lang.IncompatibleClassChangeError:
> Conflicting default methods: example/Cowboy.draw example/Painter.draw
> at example.CowboyArtist.draw(CowboyArtist.java)
> at example.CowboyArtist.main(CowboyArtist.java:6)
>
>
> Since this behavior originates in the JVM, rather than in the bytecode
> produced from the Java Compiler, it should be included in the JVM
> specification.
>
> Thus, to fix this specification bug, I propose that the quoted section of
> the JVMS from the method resolution section be replaced with the following
> text:
>
> Otherwise, if there are multiple maximally-specific superinterface methods
> of C for the name and descriptor specified by the method reference, method
> resolution throws an IncompatibleClassChangeError.
>
>
> I believe the above text captures the behavior of the current reference
> implementation, and is in line with the JLS.
>
> Let me know if you have any questions, comments, or if you find a mistake
> in my reasoning above. It is very possible that I am missing a subtlety.
>
> Thanks for reading!
>
> John
>