RFR 8194932: no ambuguity error is emitted if classfile contains two identical methods with different return types

[Jan Lahoda]

To me, looks OK.

Jan

On 11.1.2018 19:20, Maurizio Cimadamore wrote:
> Hi,
> this is a fix for an issue that has to do with compilation from
> classfile. While typically it is not possible for a Java source to
> contain two override equivalent method (as that would be flagged as
> method clash by javac), when a classfile contains two methods that have
> the same signature but different return types (which is possible at the
> classfile level), javac doesn't generate an ambiguity error when such
> method is called. Instead, javac non-deterministically resolves the call
> to the first method being declared in the classfile.
>
> The solution is to omit a part of the override check that is run in
> Resolve::mostSpecific (**). That is, this part should be disabled if the
> owner of both potentially ambiguous methods is the same. Extra code was
> added to handle the case of statically imported methods, in which case
> javac clones the imported method symbols and replaces their owner to
> make sure that the bytecode comes out in a certain way. So, if javac
> detects that the 'base' symbol of both methods is indeed the same - it
> means that the same symol was imported (and cloned) twice, so we can
> just return either. At this point, we should never have a case where we
> have two maximally specific concrete methods with same owner (unless we
> are in the classfile case).
>
> http://cr.openjdk.java.net/~mcimadamore/8194932/
>
> (**) the override check performed by javac is outside the spec, but
> necessary because javac doesn't filter overload candidates by
> accessibility - that is, overridden methods are played through the javac
> overload resoluytion machinery, and javac prefers the overridden version
> of a method; this is an unfortunate, but historical, javac design choice.
>
> Cheers
> Maurizio
>