Suggestion for a more sensible implementation of EMPTY_MAP

Abraham Marín Pérez abraham.marin.perez at gmail.com
Mon Jul 1 07:43:37 UTC 2019



> On 27 Jun 2019, at 22:38, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> 
> 
> On 6/19/19 12:51 AM, Abraham Marín Pérez wrote:
>> private void decorate(Map<String, String> 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 decorate() method has the possibility to modify the map that it's passed. Thus, it shouldn't be at all surprising that passing an unmodifiable map to it results in UOE.

decorate() does other things other than calling computeIfPresent. Given our business logic, we don’t believe throwing UOE is a helpful behaviour in this particular case.

> 
> As a special case, it doesn't *actually* modify the map if "field" is absent, but you have to do some analysis to figure this out.
> 
> Now you want the JDK to add another special case to Collections.emptyMap(), and possibly others, in order to make this special case work. I don't think we want to do that.

Fair enough. I made the suggestion thinking that this is something that would benefit the overall community. But maybe that’s not the case. If the overall community benefits better from the current implementation, then I agree it should stay as it is.

Thanks for taking the time to debate and consider this change.

Cheers,
Abraham


> 
> s'marks



More information about the core-libs-dev mailing list