JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces)
Paul Benedict
pbenedict at apache.org
Thu Nov 29 19:01:51 PST 2012
Can someone please clarify if I implement a default method in a
concrete class, I can still call the default method via super? Because
if that's true, documenting the default method's behavior is
absolutely imperative. They function like methods in abstract classes;
their implementation will always be available for delegation like any
other superclass method.
Paul
On Thu, Nov 29, 2012 at 7:50 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 30/11/2012 12:01 AM, Kevin Bourrillion wrote:
>> On Thu, Nov 29, 2012 at 2:49 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> If the type is subclassable and the method makes any calls to
>> overrideable methods on its own type, they certainly do need to
>> specify
>> how they're implemented (see e.g. Effective Java). And (a)
>> interfaces
>> are always subtypable, and (b) it's hard to imagine many default
>> implementations /not /invoking any methods on the same instance
>> (what
>>
>> else is there to do?), and those methods are of course always
>> overrideable. So this seems like an open and shut case to me.
>>
>>
>> Okay. In that sense all default methods are like concrete methods in
>> the AbstractXXX classes. Which are described as "This implementation
>> ..."
>>
>>
>> 2. It is not obvious to me that the JDK's choice for a default
>> implementation has to be _the_ only possible implementation
>> choice. In
>> many/most cases there will be a very obvious choice, but
>> that doesn't
>> mean that all suppliers of OpenJDK classes have to be
>> locked in to that
>> choice.
>>
>> This would leave a library author having no clue whether they
>> can depend
>> on "inheriting" the default or not. Default method
>> implementations are
>> not like other implementations; they're extremely leaky, and I think
>> they must be specified.
>>
>>
>> I don't see that they are any different to abstract class method
>> implementations in that regard. The JDK doesn't mandate how the
>> non-abstract methods in the AbstractXXX classes are implemented.
>>
>>
>> I'm not following. How is the "This implementation..." text you referred
>> to above /not/ a case of the JDK mandating how they're implemented?
>
> Because such statements are non-normative implementation notes. If
> somebody else wants to implement the Java APIs and provide their own
> class library then they are not required to match what is written in
> implementation notes.
>
>> Yes we definitely need a distinction between the normative and
>> non-normative text.
>>
>>
>> Any thoughts on how to make this feature cover both cases? Seems like
>> "@default" would not be the right tag anymore.
>
> To me @default would by definition be non-normative text.
>
> But maybe we are kidding ourselves to think this facilitates alternative
> implementations.
>
> David
> -----
>
>>
>> --
>> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
>> <mailto:kevinb at google.com>
>>
>
More information about the lambda-dev
mailing list