commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: [collections] MultiMap clash with Java 8
Date Thu, 14 Nov 2013 22:39:20 GMT
For anyone's observation, I sent this question to the Open JDK list because
I am so surprised how adding default methods can break custom interface
extensions. I was really hoping default methods would be much more subtle
but it turns out this could be a common occurrence going forward. What if
JDK 9 introduces new default methods with other clashes to us? I ask
rhetorically but I think you can see my point.


On Thu, Nov 14, 2013 at 4:36 PM, Phil Steitz <phil.steitz@gmail.com> wrote:

> On 11/14/13 1:06 PM, Thomas Neidhart wrote:
> > On 11/14/2013 06:12 AM, Gary Gregory wrote:
> >> How about the name removeEntry|Entries since there is a Map.Entry.
> > Also possible, but there is a subtle difference imho:
> >
> >  * removeMapping does not assume that such a mapping exists, whereas
> >  * removeEntry sounds like you remove an entry that you are sure exists
>
> For MultiMap, shouldn't it also be "removeValue" if we go that way,
> since what is being removed (IIUC) is one of the values in the
> collection that is the entry?
> >
> > The method may not succeed, as there is no such mapping currently in the
> > map.
> >
> > But I would be fine with removeEntry too.
> > What about the methods for MultiKeyMap? Any comments?
>
> Your proposal on that looks good to me.  I am ambivalent on
> removeValue, removeEntry, removeMapping, slightly favoring the last
> (your original proposal).
>
> I agree with your recommendation on return values.
>
> Phil
> >
> > Thomas
> >
> >> Gary
> >>
> >>
> >> On Wed, Nov 13, 2013 at 4:49 PM, Thomas Neidhart
> >> <thomas.neidhart@gmail.com>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.
> >>>
> >>> For the MultiKeyMap it would be semantically wrong too, thus I propose
> a
> >>> name change.
> >>>
> >>> For MultiMap:
> >>>
> >>>  boolean removeMapping(K key, V value)
> >>>
> >>> 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.
> >>>
> >>> Any objections?
> >>>
> >>> Thomas
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Cheers,
Paul

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message