Default interface methods aren't considered abstract method implementations

[Chen Liang]

Hello guys, amber is for new language features. Questions with java
compilation or JLS/JVMS belong to the compiler group.

That said, I believe this behavior is most likely a preservation of method
resolution, that for instance methods, methods from superclass have higher
priority than methods from interfaces. For example, before Java 8, static
methods could not be defined in interfaces; and when they were added in 8,
resolution rule states that they aren't shadowed to child types, so classes
cannot "inherit" interface static methods, unlike interface static fields.

Another fun fact is that superinterface fields take precedence in
resolution over superclass fields. Also a legacy from old Java, but I don't
think that is going to be changed to make things "consistent".

Regards,
Chen Liang

On Sun, Feb 9, 2025 at 4:26 PM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> Attila,
>
> Come to think of it, we should use some other, more narrowly focused,
> mailing list. Apologies to subscribers of this list. Since lambda-dev
> is defunct now, perhaps we could use compiler-dev, amber-dev, or
> core-libs-dev instead. I'm voting for amber-dev, where Brian mostly
> resides these days.
>
> -Pavel
>
> On Sun, Feb 9, 2025 at 10:12 PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
> >
> > You are not specifically asking Brian, are you? If so, sorry for
> replying.
> >
> > My humble take is that the default method is something to use when
> > there's nothing else there. When there's something, even if it's
> > abstract, we use that. So, a default method is a minimally interfering
> > fallback/extension scenario, if you will.
> >
> > That abstract A.m() effectively replaces default F.m() in C as if
> > F.m() were never there. If F.m() were allowed to provide
> > implementation for A.m() in C, then some uncompliable code could
> > suddenly become compilable and operational at runtime.
> >
> > -Pavel.
> >
> > On Sun, Feb 9, 2025 at 9:04 PM Attila Szegedi <szegedia at gmail.com>
> wrote:
> > >
> > > Hey folks,
> > >
> > > I found a somewhat puzzling behavior: default interface methods aren't
> considered abstract method implementations. Trying to compile this minimal
> reproducer:
> > >
> > > ------ C.java ------
> > > abstract class A {
> > >   abstract void m();
> > > }
> > >
> > > interface F {
> > >   default void m() {}
> > > }
> > >
> > > class C extends A implements F {}
> > > ------ C.java ------
> > >
> > > $ javac C.java
> > > C.java:9: error: C is not abstract and does not override abstract
> method m() in A
> > > class C extends A implements F {
> > > ^
> > > 1 error
> > >
> > > I can accept this being valid according to JLS today (I tried with 11,
> 21, and 23.) I admit this is one of rare occasions when I didn't go
> scouring the JLS to figure out what exactly prevents the compiler from
> accepting F.m() as implementation of A.m() in C. I'm wondering though if
> this isn't something that could be improved upon in the future. (I'm sure
> there's a gotcha somewhere. Right, Brian? ;-) )
> > >
> > > Have a great day,
> > >   Attila.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250209/09e4cc7c/attachment.htm>