I have a couple of questions about abstract with default implementation

bitter_fox bitterfoxc at gmail.com
Sat Dec 17 01:15:53 PST 2011


Thank you for the answer.
I've understood.

I can't wait for the draft including the body of Extension Methods :)

Thanks,
bitter_fox

2011/12/17 Robert Field <Robert.Field at oracle.com>

> On 12/16/11 9:14 PM, bitter_fox wrote:
> > I have a couple of questions about abstract with default implementation
> >
> > *Revision of javac is 1245.
> >
> > 1.Does "default implementation" work in extending abstract class?
> > interface A
> > {
> >      void a() default {}
> > }
> > interface B
> > {
> >      void a(); // B#a is an abstract method same as C#a
> > }
> > abstract class C
> > {
> >      public abstract void a();
> > }
> >
> > class D implements A, B // OK
> > {}
> > class E extends C implements A // Compile error
> > {}
> >
> > Is it correct that E makes the compile error:
> > Main.java:16: error: E is not abstract and does not override abstract
> > method a() in C
> > class E extends C implements A // Compile error
>
> Yes, the rule is "class always wins", that includes abstract class methods.
>
> >
> > 2.Can I use default implementation for "abstract method" in interface?
> > The methods are abstract in interface, whether there is "abstract" or
> not.
> > (I know that using "abstract" in interface is not recommended.)
> > So, these will be same:
> > interface A
> > {
> >      void a() default {}
> > }
> > interface B
> > {
> >      abstract void a() default {} // (1)
> > }
> > However, (1) makes the compile error:
> > Main.java:25: error: abstract methods cannot have a body
> >          abstract void a() default {} // (1)
>
> I don't believe the abstractness of default methods is completely nailed
> down.  But our model of it for the current implementation is that
> default methods are not abstract (even though they are in an
> interface).  Two possible models: (1) now three options:
> abstract/concrete/default; or (2) default methods are concrete.
>
> -Robert
>
> >
> > Thanks,
> > bitter_fox
> >
>
>
>


More information about the lambda-dev mailing list