@Override and default methods

[Remi Forax]

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