@Override and default methods

[Thomas Neidhart]

On 11/17/2013 06:19 PM, Brian Goetz wrote:
> 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.

Indeed, I was a bit too quick stating that a MultiMap is fully compliant
with the Map contract. In fact there are subtle differences which have
to be considered when using it. Guava has chosen to not implement the
Map interface for their Multimap, and their decision was probably wiser
in this regard.

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

Unfortunately, we still aim for Java 5, thus all the new additions are
not yet available for us, but this looks like really interesting stuff.
Also most of the functional aspects of Apache Collections will be
obsolete with Java 8, so we will have to see ourselves which direction
to go in the future.

Thomas

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