signatures that are recorded for default methods

[Ricky Clarkson]

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).
On Dec 14, 2012 6:42 AM, "Peter Levart" <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>  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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>
> >
>
>
>