Uncertainty about fix for JDK-5059679

Alex Buckley alex.buckley at oracle.com
Wed Feb 15 17:04:35 UTC 2023


On 2/15/2023 8:28 AM, Maurizio Cimadamore wrote:
> 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>)|).

At which point this class-based scenario is more clearly seen as 
analogous to the interface-based scenario that Archie also gave, where 
you can only implement the subinterface Lower<R> by declaring a concrete 
method with a raw signature. The Java language is consistent in "kicking 
the can down the road", but the JLS doesn't offer the words to 
characterize how, when, or why the Java language works like this.

Alex


More information about the compiler-dev mailing list