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

[Vicente Romero]

looks good,
Vicente

On 01/11/2018 01:20 PM, 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
>