> On 27 Jun 2019, at 22:38, Stuart Marks wrote:
>
>
>
> On 6/19/19 12:51 AM, Abraham Marín Pérez wrote:
>> private void decorate(Map data) {
>> //...
>> data.computeIfPresent("field", (k, v) -> highlightDifferences(v,
>> otherValue));
>> //...
>> }
>> At one point an emptyMap()
On 6/19/19 12:51 AM, Abraham Marín Pérez wrote:
private void decorate(Map data) {
//...
data.computeIfPresent("field", (k, v) -> highlightDifferences(v,
otherValue));
//...
}
At one point an emptyMap() was passed to this method, causing an UOE. [...]
On the face of it, the
>
> Kind regards,
>
> Anthony
>
>
> --
> *From:* core-libs-dev on behalf
> of Abraham Marín Pérez
> *Sent:* Wednesday, June 19, 2019 9:51:46 AM
> *To:* Roger Riggs
> *Cc:* core-libs-dev@openjdk.java.net
> *Subject:* Re: Suggestio
From: core-libs-dev on behalf of
Abraham Marín Pérez
Sent: Wednesday, June 19, 2019 9:51:46 AM
To: Roger Riggs
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Suggestion for a more sensible implementation of EMPTY_MAP
Hi Stuart, Roger,
First of all, thank you for such a detailed response
Hi Stuart, Roger,
First of all, thank you for such a detailed response, this really shows the big
picture. I guess no implementation will be perfect, there will always be some
wrinkles that we need to accept, and the most suitable implementation will be
the one with the fewest or least
Hi Stuart,
Not withstanding all the details. It would be useful (and possibly
expected) that an EMPTY_MAP
could be substituted for a Map with no entries. As it stands, the
caller needs know whether any optional
possibly modifying operations will be used and decide whether to create
an empty
On 6/10/19 7:34 AM, Abraham Marín Pérez wrote:
I agree that it makes sense for EMPTY_MAP to have the same logic as Map.of() or
unmodifiable(new HashMap()), which means that my suggestion cannot be applied
to just EMPTY_MAP... but maybe that’s ok: maybe we can change all of them? If
we keep
Hi Michael,
Many thanks for your reply, I can definitely see your point.
I agree that it makes sense for EMPTY_MAP to have the same logic as Map.of() or
unmodifiable(new HashMap()), which means that my suggestion cannot be applied
to just EMPTY_MAP... but maybe that’s ok: maybe we can change
> If I understand correctly, this class represents an immutable empty map. As
> a result, operations like put or remove have been implemented to throw
> UnsupportedOperationException; this makes sense to me. However, this is
> also the implementation for computeIfPresent, which I believe may be
Hi everyone,
I'm a first timer here, I just joined the group as suggested by Martijn
Verburg to make a suggestion for a slight change in the implementation of
Collections.EMPTY_MAP.
If I understand correctly, this class represents an immutable empty map. As
a result, operations like put or
10 matches
Mail list logo
