@Override and default methods

Thomas Neidhart thomas.neidhart at gmail.com
Sat Nov 16 03:53:06 PST 2013


> Hi Paul;
> 
> This is unfortunate. Hopefully we come up with some compromise or accommodation. 
> 
> Mike

Hi Mike,

thanks for answering on this topic.

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

These method existed already in previous releases, but we are somewhat
fortunate to change it for this release if necessary.

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

Yes, we already discussed various options on how to rename them, but
wanted to explore also other possibilities.

The MultiMap interface, and its implementations are otherwise perfectly
compliant to the Map interface, just offering a convenient interface for
mapping multiple values to a given key by using a collection as value type.

I guess the names you suggest are pretty good, although I slightly favor
removeMapping in case of the MultiMap.

Thomas


More information about the lambda-dev mailing list