Hi Thomas,
Thomas Neidhart wrote:
> Hi,
>
> during the vote for collections 4.0 we have discovered a problem wrt the
> MultiMap interface in general and specifically the MultiKeyMap.
>
> 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)
>
>
> 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.
We could introduce a compatibility interface and implement it like
interface Java8Map {
public boolean remove(Object key, Object value);
}
I wonder if it makes any problems for Java 8 though.
> For the MultiKeyMap it would be semantically wrong too, thus I propose a
> name change.
The question is nevertheless, what does that method of Java 8 to
MultiKeyMap? With Java 8 it simply exists.
> For MultiMap:
>
> boolean removeMapping(K key, V value)
If the method will do the same as Java 8 remove, we can stay with "remove"
assuming the approach from above works.
> For MultiKeyMap (for all remove(K ...) methods):
>
> V removeMultiKey(K key1, K key2)
> V removeMultiKey(K key1, K key2, K key3)
> ...
>
>
> In the case of the MultiMap, I think returning a boolean makes more
> sense, similar as Java 8 does it.
>
> For the MultiKeyMap, returning the previously mapped value is preferable
> imho.
The question is anyway, if we should keep the overloaded method names. Since
the inherited methods use "MultiKey<? extends K>" as key type in their
signatures, we might as well introduce new names and provide vararg support,
something like this:
V putInto(V newVal, K... keys);
V removeFrom(K... keys);
V containsKeys(K... keys);
...
What do you think?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
