signatures that are recorded for default methods
Peter Levart
peter.levart at gmail.com
Fri Dec 14 06:13:07 PST 2012
On 12/14/2012 01:41 PM, Ricky Clarkson wrote:
>
> Surely a default method that all subclasses are instructed to override
> just shouldn't exist, right?
>
> Then the compiler will 'instruct' subtypes to implement it
> automatically (i.e., by failing to compile).
>
I just wanted to illustrate how a sub-optimal specification of default
method behaviour for "optional" methods would sound like if one didn't
want to specify that it always throws UnsupportedOperationException ;-)
Peter
> On Dec 14, 2012 6:42 AM, "Peter Levart" <peter.levart at gmail.com
> <mailto:peter.levart at gmail.com>> wrote:
>
> On 12/14/2012 10:06 AM, Peter Levart wrote:
> > On 12/14/2012 07:21 AM, David Holmes wrote:
> >> Paul,
> >>
> >> On 14/12/2012 9:46 AM, Paul Benedict wrote:
> >>> Lance,
> >>>
> >>> Good questions. Someone with authority will surely answer, but
> here's
> >>> my armchair opinion...
> >>>
> >>> If the Javadoc is to specify how the default method executes, than
> >>> that would naturally infer all default implementations must have a
> >>> stated contract. You can't document the default execution
> behavior in
> >>> the public API and then let a provider switch the behavior.
> The two go
> >>> hand-in-hand, imo.
> >>
> >> I couldn't really make sense of that. :) The method has a contract.
> >> The "default implementation" has to honor that contract. The
> question
> >> is whether how the "default implementation" honors the method
> >> contract is required to be part of a second contract.
> >>
> >> I hope that made sense :)
> > I think that the answer is obvious. A default method provider
> has only
> > as much freedom in choosing the implementation of the default method
> > that particular implementation differences among various
> providers are
> > not observable by the "sane" usage of the API. The only soft aspect
> > might be performance. Any other behavioural difference should not be
> > allowed. Otherwise there will be in-compatibilities among platform
> > providers.
> >
> > For example, the default Iterator.remove() is implemented in
> Oracle's
> > JDK as always throwing UnsupportedOperationException. The TCK should
> > test for that and the Javadoc should specify that.
> Ok, I admit that in this particular case and other similar cases
> (where
> the default method does nothing useful), the specification could
> alternatively specify: "The default method behaviour is
> unspecified and
> useless. Don't call that method or make sure it is always
> overridden if
> you call it" - the TCK in that case doesn't test the behaviour of such
> method.
>
> Peter
> >
> > As Joe said, default interface methods are no different than any
> other
> > overridable methods. They have a contract and behaviour. The
> behaviour
> > can be changed (overriden) within constraints defined by
> contract, but
> > the behaviour itself should also be specified and followed by
> > different providers.
> >
> > Just my 2 cents.
> >
> > Regards, Peter
> >
> >>
> >> David
> >> -----
> >>
> >>
> >>> Paul
> >>>
> >>> On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle
> >>> <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
> wrote:
> >>>>
> >>>> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote:
> >>>>
> >>>>> Good point, Joe.
> >>>>> Those extra assertions for default methods can be checked
> >>>>> by regular API tests separately from signature tests.
> >>>>
> >>>> I am not clear on this. See the message attached from David
> which
> >>>> ask a similar question (from the attached email):
> >>>> -------------------
> >>>> 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.
> >>>> -------------------
> >>>>
> >>>>
> >>>> If everyone needs to implement the same default
> implementation then
> >>>> great the JCK/TCK can test it and IMHO we should have a
> javadoc tag
> >>>> for this.
> >>>>
> >>>> If everyone is free to choose what the default behavior is,
> then we
> >>>> cannot test it.
> >>>>
> >>>> So has there been a decision WRT the requirements for default
> methods?
> >>>>
> >>>>
> >>>> Best
> >>>> Lance
> >>>>> Thanks,
> >>>>> -leonid
> >>>>>
> >>>>> On 12/13/2012 1:05 PM, Joe Darcy wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> As with concrete methods on abstract classes, I would
> expect the
> >>>>>> specifications of the default methods to often contain text
> akin
> >>>>>> to "This default implementation does x, y, and z" since if the
> >>>>>> method is to be called by subtypes, the self-use patterns
> in the
> >>>>>> default method need to be known.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> -Joe
> >>>>>>
> >>>>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote:
> >>>>>>> Hello Lance,
> >>>>>>>
> >>>>>>> My understanding would be that the signature test
> >>>>>>> should check that interface method is marked as default method
> >>>>>>> but do not track the code in its default body
> >>>>>>> (assuming that the body is not a part of a spec - API
> javadoc).
> >>>>>>>
> >>>>>>> (I've confirmed that with the signature test developer)
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> -leonid
> >>>>>>>
> >>>>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote:
> >>>>>>>> Folks,
> >>>>>>>>
> >>>>>>>> Will the signatures for interfaces that are recorded by the
> >>>>>>>> TCKs for interfaces record the fact that a method includes a
> >>>>>>>> default method? or will it just record the method definition?
> >>>>>>>>
> >>>>>>>> I am assuming it will, but I know there has been discussion
> >>>>>>>> that a implementor could choose a different default
> >>>>>>>> implementation on one of the recent threads that was up for
> >>>>>>>> review.
> >>>>>>>>
> >>>>>>>> I am still trying to understand what our guidelines are,
> if any
> >>>>>>>> for documenting the behavior of the supplied default methods
> >>>>>>>> given the javadocs are part of the specification for many
> APIs
> >>>>>>>> (and in some case the only spec).
> >>>>>>>>
> >>>>>>>> Best
> >>>>>>>> Lance
> >>>>>>>>
> >>>>>>>> Lance Andersen| Principal Member of Technical Staff |
> >>>>>>>> +1.781.442.2037
> >>>>>>>> Oracle Java Engineering
> >>>>>>>> 1 Network Drive
> >>>>>>>> Burlington, MA 01803
> >>>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>> Lance Andersen| Principal Member of Technical Staff |
> +1.781.442.2037 <tel:%2B1.781.442.2037>
> >>>> Oracle Java Engineering
> >>>> 1 Network Drive
> >>>> Burlington, MA 01803
> >>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> >>>>
> >>>>
> >>>>
> >>>
> >
>
>
More information about the lambda-dev
mailing list