I think it is an implementation bug. The javadoc for putIfAbsent says "When
{@code read()} is called on the result or state is committed, it forces a
read of the map and reconciliation with any pending modifications."My reading of this is that the value changes for anything that happens after the call to putIfAbsent. It would be good to make this clear, that any subsequent observation of this cell should observe the new value. Kenn On Fri, Aug 13, 2021 at 9:32 AM Reuven Lax <[email protected]> wrote: > Yeah - I remember thinking that the computeIfAbsent/putIfAbsent semantics > were very weird. I almost would have preferred not having those methods in > MapState, even though they can be useful. > > On Fri, Aug 13, 2021 at 9:21 AM Luke Cwik <[email protected]> wrote: > >> I was surprised to see the MapState API for computeIfAbsent/putIfAbsent >> only performs the write if the ReadableState that is returned is resolved. >> >> For example: >> ReadableState<String> value = mapState.putIfAbsent("key", "new value >> maybe"); >> does nothing until >> value.read(); >> >> It would seem like an obvious mistake for developers to make to forget to >> do the value.read() when coming from the Java Map API which always performs >> the write. >> >
