Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behaviour in updateValue() with empty key #1517

Open
romanvmarkov opened this issue Sep 27, 2023 · 2 comments
Open

Unexpected behaviour in updateValue() with empty key #1517

romanvmarkov opened this issue Sep 27, 2023 · 2 comments

Comments

@romanvmarkov
Copy link

romanvmarkov commented Sep 27, 2023

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

  1. Create new IntObjectHashMap map = new IntObjectHashMap();.
  2. Update value for empty key: map.updateValue(0, () -> null, (existingValue) -> { if (map.containsKey(0)) throw new RuntimeException("key 0 does not exits at the moment"); return new Object();});
  3. Exception is thrown

Currently, map has flag containsZeroKey before the value for zero key was evaluated. It leads to true result of map.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 replacing this.sentinelValues.containsZeroKey = true; after this.sentinelValues.zeroValue = function.valueOf(factory.value()); is enough for fixing this

@mohrezaei
Copy link
Member

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.

@mohrezaei
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants