@Override and default methods

[David Holmes]

On 17/11/2013 12:40 PM, Paul Benedict wrote:
> My concern is how intrusive default methods can be. If someone adds a
> default method to a super interface and it conflicts with existing methods
> in a sub-interface, you can't compile. This pattern is ought to repeat over
> and over. JDK 9 or 10 or the future may continue to add new default methods
> and break sub-interfaces.

This was deemed an acceptable price to pay to allow the platform classes 
to move forward. Some code will need modification to run on Java 8.

> Can anything be done so that true abstract methods always wins and default
> methods in super-interfaces always lose?

The issue here is not abstractness but incompatible/conflicting 
signatures. If a class already has a method Foo that is later added to 
an inherited interface as a default method then the class's Foo will 
continue to be invoked.

David
-----
>
>
>
> On Sat, Nov 16, 2013 at 4:28 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> things are more complex than i
>> had thunk, remove was introduced in ConcurentMap first so its name can not
>> be changed :(
>>
>> Rémi
>>
>>  From my smartphone
>>
>> -------- Message d'origine --------
>> De : Remi Forax <forax at univ-mlv.fr>
>> Date : 16/11/2013  12:26  (GMT+01:00)
>> A : lambda-dev at openjdk.java.net
>> Objet : Re: @Override and default methods
>>
>> On 11/14/2013 09:34 PM, Mike Duigou wrote:
>>> Hi Paul;
>>>
>>> This is unfortunate. Hopefully we come up with some compromise or
>> accommodation.
>>>
>>> Mike
>>
>> I think the JDK and Apache Collections are both wrong in naming their
>> methods.
>> For the JDK, the method should be named removeEntry and for the Apache
>> Collections
>> it should be removeMultiKey().
>> Given that Apache Collections remove() method predates JDK one,
>> I propose to just rename remov to removeEntry
>> (I know it's an API change but a lot of implementations of Map may
>> introduce a remove(),
>> the name is too common).
>>
>> other comments inlined.
>>
>>>
>>>
>>> On Nov 13 2013, at 18:43 , Paul Benedict <pbenedict at apache.org> wrote:
>>>
>>>> I saw this email come through Apache and would like your opinions:
>>>>
>>>> ===
>>>> Hi,
>>>>
>>>> during the vote for collections 4.0 we have discovered a problem wrt the
>>>> MultiMap interface in general and specifically the MultiKeyMap.
>>> Are the problematic methods new in Collections 4.0 or were they part of
>> previous releases as well?
>>
>> They were introduce in 3.1 (in 2008 it seams).
>>
>> https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/org/apache/commons/collections/map/MultiKeyMap.html
>>
>>>
>>>> Java 8 introduces a new default method in the Map interface:
>>>>
>>>> boolean remove(Object key, Object value)
>>>>
>>>> This clashes with the method in MultiMap:
>>>>
>>>> V remove(K key, V value)
>>>>
>>>> and the remove methods for multiple keys in MultiKeyMap:
>>>>
>>>> V remove(K key1, K key2)
>>> The issue is that the return types are unrelated. If the Java 8 Map
>> method returned Object then it would be possible to specialize the return
>> type to V but because boolean and V/Object are unrelated then the override
>> is not allowed.
>>
>> also the semantics is different.
>>
>>>
>>>
>>>
>>>> Just changing the return type does not solve the problem, as one can not
>>>> re-define a method in an interface without using the @Override
>>>> annotation, but this would only work when compiling with JDK 8 and fail
>>>> for other JDKs.
>>>> ===
>>>>
>>>> What is the correct course in such a situation?
>>> Is it possible to rename these methods in Apache Collections to
>> removeKey and removeValue? Understandably if these methods are not new in
>> 4.0 then it will be difficult to remove them. The other question would be
>> whether it's appropriate for these classes to implement or extend Map. If
>> their semantics are such that they do not fully implement the standard Map
>> semantics then it's probably best that they not claim to be Map
>> implementations.
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>
>> Rémi
>>
>>
>>
>>
>
>