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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Maurizio Cimadamore
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

Reply | Threaded
Open this post in threaded view
|

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

Maurizio Cimadamore


On 11/01/18 18:20, Maurizio Cimadamore wrote:
> and javac prefers the overridden version of a method;
Whoops - obviously I meant 'prefers the overridding version...'

Maurizio
Reply | Threaded
Open this post in threaded view
|

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

Jan Lahoda
In reply to this post by Maurizio Cimadamore
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
>
Reply | Threaded
Open this post in threaded view
|

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

Vicente Romero-2
In reply to this post by Maurizio Cimadamore
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
>

Reply | Threaded
Open this post in threaded view
|

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

Vicente Romero-2
I just saw that there is a typo in the bug title ambuguity -> ambiguity,
just in case you haven't pushed yet.

Vicente

On 01/12/2018 09:20 AM, Vicente Romero wrote:

> 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
>>
>