Uncertainty about fix for JDK-5059679

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Feb 15 16:28:06 UTC 2023


On 14/02/2023 01:06, Dan Smith wrote:

> LS isn't always clear about which of these two signatures it's talking 
> about, but in this case, given the use of different phrases in the 
> third and fourth rules, and the fact of javac's longstanding behavior, 
> I think that's the intent.
>
> (It makes sense, too, because the underlying problem is that you don't 
> want the descriptors to clash in the class file. And they don't, 
> because one has descriptor '(Object)V' and the other is '(Class)V'. 
> Eventually, somebody might try to override something and need a bridge 
> method that *would* clash, but in that case there would be another 
> method for which this error check should apply.)

Exactly.

The checks in 8.4.8 are there to ensure you can’t accidentally override 
a bridge method. As Dan points out, the underlying descriptors are 
different here, so no real problem occurs. When writing the checks for 
8.4.8 I had to scan these rules multiple times - and I agree that some 
clarification could be in order here. I think reading them with the 
glasses of “no accidental bridge method override” is generally a useful 
metaphore - and, since the JLS cannot speak about bridge methods, that 
results in a somewhat convoluted formulation of the rules.

The example Archie shown is one of those cases where there’s obviously 
something “fishy” going on, but the compiler decides to go ahead with 
it, kicking the can down the road, to when the abstract class will 
become a concrete one. So, if a new class comes along, like this:

|class EvenLower<R> extends Lower<R> { void method(Class<?> c) { } } |

A problem will be reported - because the class will still need to 
implement |method(Class<R>)| - but of course if you try to do that, you 
will get a clash.

That said, your subclass can have a raw declaration:

|class EvenLower<R> extends Lower<R> { void method(Class c) { } } |

In which case everything is ok (beause |method(Class)| is a subsignature 
of the sharper |method(Class<R>)|).

Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230215/826659c7/attachment-0001.htm>


More information about the compiler-dev mailing list