On Fri, 9 Oct 2026 16:21:58 GMT, Bill Huang <[email protected]> wrote:
>> Changed Tests: >> >> HashMap/KeySetRemove.java: equal ValueClass keys mapped to null can be >> removed from HashMap and TreeMap. >> >> HashMap/NullKeyAtResize.java: null-key resize behavior remains correct when >> surrounding keys are ValueClass instances. >> >> HashMap/PutNullKey.java: colliding comparable tree-bin keys are >> value-capable via @AsValueClass. >> >> HashMap/ReplaceExisting.java: replacing an existing ValueClass key during >> active iteration does not corrupt the iterator. >> >> HashMap/SetValue.java: Map.Entry.setValue() returns the old ValueClass value. >> >> HashMap/ToArray.java: toArray() coverage is added for ValueClass keys, >> values, and set elements across hash and linked variants. >> >> HashMap/TreeBinAssert.java: tree-bin iterator-removal coverage now uses a >> value-capable key. >> >> Hashtable/EqualsCast.java: Provider/Hashtable equality now includes matching >> ValueClass key/value entries. >> >> Hashtable/SimpleSerialization.java: serialization round-trip now also covers >> Hashtable<Integer,Integer>. >> >> LinkedHashMap/ComputeIfAbsentAccessOrder.java: access-order behavior is >> repeated with Integer keys. >> >> LinkedHashMap/EmptyMapIterator.java: fail-fast iterator behavior is repeated >> with Integer key/value entries. >> >> LinkedList/AddAll.java: append-order behavior is repeated with ValueClass >> elements. >> >> LinkedList/Clone.java: clone/equality checks for LinkedList, TreeSet, and >> TreeMap subclasses now include ValueClass contents. >> >> Unchanged Tests: >> >> HashMap/HashMapCloneLeak.java: unchanged because the test depends on >> WeakReference reachability. Value objects are not valid weak-reference >> targets, so adding VClass would not match the regression being tested. >> >> HashMap/OverrideIsEmpty.java: unchanged because the test is about HashMap >> subclass method dispatch. Value classes cannot extend HashMap, and changing >> only the key/value payload would not add meaningful value-class coverage. >> >> HashMap/WhiteBoxResizeTest.java: unchanged because it is a >> white-box/internal capacity and table-sizing test using >> reflection/VarHandles over HashMap, LinkedHashMap, HashSet, and WeakHashMap >> internals. Its purpose is sizing/lazy allocation/resize arithmetic, not >> key/value equality or value-object behavior. >> >> HashMap/ToString.java: unchanged because it specifically verifies that >> HashMap.Entry.toString() does not throw when the map contains null keys or >> values. Adding value-class keys or values would not extend the original >> null-handling regression in a meaningful ... > > Bill Huang has updated the pull request incrementally with one additional > commit since the last revision: > > Fixed code indentation. OK, great to see the duplication is all being pulled out. I note that most (but not all) of the files have the copyrights reverted. I guess this is the right thing if the file really is being reverted to its previous state. A lot of these changes came in with the JEP 401 integration (cc278dbb8a1ca0754d5842708b9029441055d361) and so I think the proper thing to do is to have a PR that consists entirely of file reversions, which will also include reversions of the copyright date. (It looks like CheckedListBash.java is being reverted, but its copyright date is not? Maybe that was just an oversight.) In any case the history in this PR is now completely confusing as the initial description is out of date. So I think the thing to do is to create a pure-reversion PR that reverts all the files (except the two specific ones) and that is focused on removing the duplicate code that uses VClass. I guess it'll need a separate bug ID as well. But this will make it clearer in the history what's going on. Then we can proceed with another PR to make the changes to Collections/Ser and HashMap/PutNullKey. Probably this bug ID can be reused, but I think a new, clean PR for this would also be preferable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32201#issuecomment-6175987703
