Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of paulus.benedictus@gmail.com
 designates 209.85.128.50 as permitted sender)
MIME-Version: 1.0
Sender: paulus.benedictus@gmail.com
In-Reply-To: <5285505A.7060409@gmail.com>
References: <5283F3DF.403@gmail.com>
	<CACZkXPwOyJbz-j8z18ovFhC+4ELi6L6ao5hhPokbF_cyVke81A@mail.gmail.com>
	<52853B70.4040409@gmail.com>
	<5285505A.7060409@gmail.com>
Date: Thu, 14 Nov 2013 16:39:20 -0600
Message-ID: 
 <CABLGb9xnkeV4e69iX9L2zcCtL=c2Df1myG5sdCUjnw1mZ6LdNQ@mail.gmail.com>
Subject: Re: [collections] MultiMap clash with Java 8
From: Paul Benedict <pbenedict@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a11c250b6b27cdf04eb2ac083

--001a11c250b6b27cdf04eb2ac083
Content-Type: text/plain; charset=ISO-8859-1

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

--001a11c250b6b27cdf04eb2ac083--