Defaults for Objects' methods

[Deepak S Patwardhan]

Thanks Dan for pointing out the relevant section of EDR 2 spec.

I was about to suggest, before I saw your response, that we may formally
change the two-state treatment of interface methods - abstract, default - to
three, by adding - redundant. Interface methods which have the same
signature as Objects' (public) methods are redundant. Redundant methods are
neither abstract nor default.

Regards,
Deepak S Patwardhan.

> -----Original Message-----
> From: Dan Smith [mailto:daniel.smith at oracle.com]
> Sent: 19 July 2012 21:34
> To: Deepak S Patwardhan
> Cc: lambda-dev at openjdk.java.net
> Subject: Re: Defaults for Objects' methods
> 
> On Jul 19, 2012, at 3:20 AM, Deepak S Patwardhan wrote:
> 
> > Hi all,
> >
> > This has been previously discussed in the thread "defender methods and
> > method of Object",
> > http://mail.openjdk.java.net/pipermail/lambda-dev/2012-
> March/004582.html .
> >
> > Consider the following (which compiles with lambda build 45)
> >
> > public interface PrettyPrintable {
> >
> >    public String prettyString();
> >
> >    public String toString() default {
> >        return prettyString();
> >    }
> > }
> >
> > Since the (current) method resolution algorithm will never result in
> > the invocation of the default body of toString() from this interface,
> > shouldn't the above give a compilation error with the reason being
> unreachable code ?
> > Basically, should we disallow interfaces to provide defaults for
> > Object's methods ?
> 
> Yes, an error is the specified behavior.  So the EDR 2 specification, Part
G,
> 9.4.3:
> 
> http://jcp.org/aboutJava/communityprocess/edr/jsr335/index2.html
> 
> This was a fairly recent decision, so it appears the compiler may not have
> caught up with it yet.
> 
> The question of how to handle Object methods has been discussed quite a
> bit by the Expert Group and will be discussed more.  The alternative of
> subclasses inheriting PrettyPrintable.toString rather than Object.toString
is
> on the radar.  It's not a no-brainer, because it involves a fairly
significant shift
> in the classes vs. interfaces model, but we know some people would really
> like it to work that way.
> 
> -Dan