signatures that are recorded for default methods (original) (raw)

Peter Levart peter.levart at gmail.com
Fri Dec 14 14:13:07 UTC 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 core-libs-dev mailing list