@Override and default methods
mike.duigou at oracle.com
Thu Nov 14 12:34:36 PST 2013
This is unfortunate. Hopefully we come up with some compromise or accommodation.
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:
> 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?
> 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.
More information about the lambda-dev