@Override and default methods

[Brian Goetz]

Great to hear there's a not-so-unhappy resolution to this story!

BTW, its easy to accidentally make a MultiMap that tries to implement 
Map<K,Something> but violates the Map contract -- so be careful.

You should also consider writing a Collector<T, MultiMap<K,List<T>> for 
grouping into your MultiMap, like Collectors.groupingBy.  Its easy and fun!

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