Cannot implement abstract method with extension method
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Aug 27 06:22:14 PDT 2010
On 27/08/10 14:09, Jordan Stewart wrote:
> On Thu, Aug 26, 2010 at 1:10 AM, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
> On 25/08/10 13:01, Thomas Jung wrote:
> > Hi,
> >
> > given the extension method m in interface A and abstract method m in
> > the abstract class B. The definition of the extension method A.m is
> > not used to "implement" B.m in C.
> >
> > interface A{
> > extension boolean m(Object object) default As.m;
> > }
> >
> > abstract class B {
> > public abstract boolean m(Object object);
> > }
> >
> > class C extends B implements A{}
> >
> Uhmm, it's not crystal clear as to whether this should work as you
> expect - Brian any ideas?
>
>
> Hi Maurizio,
>
> Is the implementation meant to conform to the Defender Methods draft?
> The Method dispatch section of the draft lists a four step process-
> 1. standard search for an implementation
> 2. determine the set of interfaces that provide a default
> 3. discard superinterfaces from the set that have subinterfaces in the set
> 4. if there's one member in the set use its default implementation,
> otherwise throw an exception
>
> Perhaps I'm missing/misunderstanding something (very possible given
> that it's after 1am here in New Zealand!), have misread, or the
> current implementation isn't meant to conform to the draft, but if not
> then in this case As.m should be used as the implementation of m for
> instances of C.
Hi,
the rules you are referring to describe a runtime lookup and not the
static checks carried out by javac. However in the latest push I've
changed javac to be more liberal so that it now accepts cases that will
in fact succeed given the above runtime resolution rules.
Thanks
Maurizio
>
> Cheers,
> Jordan
>
More information about the lambda-dev
mailing list