Should HashMap::computeIfAbsent be considered a "structural modification" for an existing key?

[Peter Levart]

Ah, I see your point. Haven't read this part of your message below 
before. You don't know in the MultiMap code whether the key is already 
in the HashMap or not (so you can't choose .get() vs. 
.computeIfAbsent()), but  the user of the MultiMap might expect that 
when the MultiMap has been pre-initialized, that MultiMap.get() will 
only be a read operation and therefore thread-safe.

 From consistency point of view HashMap might be expected to not modify 
its internal state when it's obvious that the external view of its state 
doesn't change. .computeIfAbsent() is violating that expectation. 
WeakHashMap is violating that expectation too, but it has its own 
reasons while HashMap doesn't have them...

I  think this could be fixed.

Regards, Peter

On 11/20/18 12:52 AM, Michael Rasmussen wrote:
> From: Andrew Dinn <adinn at redhat.com>
>> I have to ask the obvious: Why does the question matter?
> I'm trying to figure out if something is a bug in HashMap in the JDK, or in Weld :D
>
> The case in question is basically, a HashMap is created, and then the keys are iterated over concurrently.
> The issue here though is that the HashMap is used as the backing of a MultiMap, and the multimap.get is basically hashmap.computeIfAbsent(key, k -> new HashSet()).
> Meaning you have a HashMap, which you've fully initialized, and you're iterating over all the known keys in the map... but surprisingly the call to .get actually changes the structure of the map, leading to bad consequences.
>
> /Michael