On Thu, 30 Mar 2023 09:39:14 GMT, Tagir F. Valeev <tval...@openjdk.org> wrote:
>> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Simplify handling of cached keySet, values, and entrySet views. > > src/java.base/share/classes/java/util/LinkedHashMap.java line 78: > >> 76: * on collection-views do <i>not</i> affect the order of iteration of the >> 77: * backing map. >> 78: * > > I see above the list of methods that affect the encounter order in > access-order mode: >> Invoking the put, putIfAbsent, get, getOrDefault, compute, computeIfAbsent, >> computeIfPresent, or merge methods results in an access... > > Should we extend it to add new methods like putFirst and putLast? Also, it > says that 'In particular, operations on collection-views do not affect the > order of iteration of the backing map'. Now, we have a map-view > (`reversed()`). We should specify whether operations on the reversed map > change the encounter order of the original map, and if yes then how exactly > they do this (moving entries to the end, like in the original map, or moving > them to the beginning?) The list of methods that generate accesses shouldn't include any explicit-positioning methods. They should do exactly as one expects and shouldn't change encounter order based on access to an element. For example, firstEntry shouldn't move the entry to the end, and putFirst should put the entry at the front and not at the end. But it's worth clarifying that the same methods on the reversed view generate accesses to the backing map and update the order. And also, an access to an entry in the reversed view should move it to the front. (putAll doesn't work though because of bugs you pointed out elsewhere.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1167370506
