Open romanvmarkov opened 11 months ago
None of the functions in any of the interfaces have been designed or tested for reentrancy. It's reasonable to expect reentrancy if the method is non-mutating, but for a mutating function, usually the point of passing in the function is late invocation, which may very well be when the collection is in a intermediate state.
In a language like Rust, where the compiler enforces mutation semantics, the above code, where there is a mutable reference to the collection as well as a non-mutable reference, would immediately cause a compile error.
In Java (or any other language), if the collection is guarded by a non-reentrant lock, the above code would result in a deadlock.
This issue exits in Eclipse Collections framework. Unexpected behaviour in, for instance, IntObjectHashMap.updateValue() with empty key. Apparently, the issue will be reproduced also in any PrimitiveObjectHashMap and in updateValueWith() method.
Steps to reproduce
IntObjectHashMap map = new IntObjectHashMap()
;.map.updateValue(0, () -> null, (existingValue) -> { if (map.containsKey(0)) throw new RuntimeException("key 0 does not exits at the moment"); return new Object();});
Currently, map has flag
containsZeroKey
before the value for zero key was evaluated. It leads to true result ofmap.containsKey(0)
call. That's quite unexpected and it's different from behaviour for non empty key.map.containsKey(0)
returning false inside function expected before value for zero key was inserted to the map.I assume, the issue will be reproduced also in any PrimitiveObjectHashMap and in
updateValueWith()
method. Just replacingthis.sentinelValues.containsZeroKey = true;
afterthis.sentinelValues.zeroValue = function.valueOf(factory.value());
is enough for fixing this