@Override and default methods

[Paul Benedict]

My concern is how intrusive default methods can be. If someone adds a
default method to a super interface and it conflicts with existing methods
in a sub-interface, you can't compile. This pattern is ought to repeat over
and over. JDK 9 or 10 or the future may continue to add new default methods
and break sub-interfaces.

Can anything be done so that true abstract methods always wins and default
methods in super-interfaces always lose?




On Sat, Nov 16, 2013 at 4:28 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> things are more complex than i
> had thunk, remove was introduced in ConcurentMap first so its name can not
> be changed :(
>
> Rémi
>
> From my smartphone
>
> -------- Message d'origine --------
> De : Remi Forax <forax at univ-mlv.fr>
> Date : 16/11/2013  12:26  (GMT+01:00)
> A : lambda-dev at openjdk.java.net
> Objet : Re: @Override and default methods
>
> On 11/14/2013 09:34 PM, Mike Duigou wrote:
> > Hi Paul;
> >
> > This is unfortunate. Hopefully we come up with some compromise or
> accommodation.
> >
> > Mike
>
> I think the JDK and Apache Collections are both wrong in naming their
> methods.
> For the JDK, the method should be named removeEntry and for the Apache
> Collections
> it should be removeMultiKey().
> Given that Apache Collections remove() method predates JDK one,
> I propose to just rename remov to removeEntry
> (I know it's an API change but a lot of implementations of Map may
> introduce a remove(),
> the name is too common).
>
> other comments inlined.
>
> >
> >
> > 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?
>
> They were introduce in 3.1 (in 2008 it seams).
>
> https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/org/apache/commons/collections/map/MultiKeyMap.html
>
> >
> >> 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.
>
> also the semantics is different.
>
> >
> >
> >
> >> 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.
> >
> > Thanks,
> >
> > Mike
> >
>
> Rémi
>
>
>
>


-- 
Cheers,
Paul