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.lev...@gmail.com
<mailto:peter.lev...@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.ander...@oracle.com <mailto:lance.ander...@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.ander...@oracle.com <mailto:lance.ander...@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.ander...@oracle.com <mailto:lance.ander...@oracle.com>
>>>>
>>>>
>>>>
>>>
>
