signatures that are recorded for default methods

[Peter Levart]

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
>>>>
>>>>
>>>>
>>>
>