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