You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2013/11/13 22:49:19 UTC
[collections] MultiMap clash with Java 8
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
Re: [collections] MultiMap clash with Java 8
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/14/2013 11:36 PM, Phil Steitz 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).
There was a response an the lambda-dev mailinglist, suggesting
removeValue and removeKey respectively.
Well, I like removeKey for the MultiKeyMap, but the MultiMap I am split,
I find both, removeValue and removeMapping equally good.
Thomas
> I agree with your recommendation on return values.
>
> Phil
>>
>> Thomas
>>
>>> Gary
>>>
>>>
>>> On Wed, Nov 13, 2013 at 4:49 PM, Thomas Neidhart
>>> <th...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] MultiMap clash with Java 8
Posted by Phil Steitz <ph...@gmail.com>.
On 11/14/13 2:39 PM, Paul Benedict wrote:
> 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.
Yes, this is a good point. On the other hand, whenever you add to
an interface you risk this. The likelihood of this happening is
greater with less precise method names in the extensions. We are
looking at a great example here: "remove" in our classes should
arguably have been made more precise in the first place.
Independent of the name clash problem, I think Thomas'
recommendations represent an improvement.
Phil
>
>
> On Thu, Nov 14, 2013 at 4:36 PM, Phil Steitz <ph...@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
>>>> <th...@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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] MultiMap clash with Java 8
Posted by Paul Benedict <pb...@apache.org>.
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 <ph...@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
> >> <th...@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
Re: [collections] MultiMap clash with Java 8
Posted by Phil Steitz <ph...@gmail.com>.
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
>> <th...@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
Re: [collections] MultiMap clash with Java 8
Posted by Thomas Neidhart <th...@gmail.com>.
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
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?
Thomas
>
> Gary
>
>
> On Wed, Nov 13, 2013 at 4:49 PM, Thomas Neidhart
> <th...@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
Re: [collections] MultiMap clash with Java 8
Posted by Gary Gregory <ga...@gmail.com>.
How about the name removeEntry|Entries since there is a Map.Entry.
Gary
On Wed, Nov 13, 2013 at 4:49 PM, Thomas Neidhart
<th...@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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [collections] MultiMap clash with Java 8
Posted by Paul Benedict <pb...@apache.org>.
The thread is here:
http://mail.openjdk.java.net/pipermail/lambda-dev/2013-November/011397.html
On Wed, Nov 13, 2013 at 7:40 PM, Paul Benedict <pb...@apache.org> wrote:
> I will forward a portion of this email to the OpenJDK folks and see what
> they think about compatibility options.
>
>
> On Wed, Nov 13, 2013 at 3: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
>>
>>
>
>
> --
> Cheers,
> Paul
>
--
Cheers,
Paul
Re: [collections] MultiMap clash with Java 8
Posted by Paul Benedict <pb...@apache.org>.
I will forward a portion of this email to the OpenJDK folks and see what
they think about compatibility options.
On Wed, Nov 13, 2013 at 3:49 PM, Thomas Neidhart
<th...@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
>
>
--
Cheers,
Paul
Re: [collections] MultiMap clash with Java 8
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/15/2013 09:06 AM, Jörg Schaible wrote:
> 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.
Does not really work and I would prefer the method renaming anyway as it
is more specific.
>> 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);
> ...
hmm, using varargs is not advised, as this will lead to warnings in
client side code, at least for Java 5.
There was an answer on the lambda-dev mailinglist, and the suggestion
was to change the methodname to removeKey(...), which would also be ok
for me (I suggested removeMultiKey, but this is more concise I guess).
If there would not be the problem with generics and varargs, I would be
in favor of changing all the methods in a similar way as you suggest,
but I fear this will make the situation just worse atm.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] MultiMap clash with Java 8
Posted by Jörg Schaible <Jo...@scalaris.com>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org