On Fri, 28 Aug 2026 17:01:17 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 four additional > commits since the last revision: > > - Fixed coding format issues. > - Fixed coding format issues > - Consolidate java.util.Collections test logic of relugar classes and value > classes > - Consolidated test logic of regular classes and value classes The value here isn't the test logic, it's regression/compatibility testing of the JVM feature itself. Most java.util classes were not written with value classes in mind, so this coverage is really just checking they still work correctly for value classes -- making sure nothing crashes or misbehaves as it flows through the existing internals. So yeah, the value class coverage is still worth having even though nothing different was actually done with the VClass instances relative to the original operations. As for Element/IElement/VElement — I think it'd only make sense if we had a VClass-only test and had to invent an identity-side type from scratch to pair with it. That's not the case here though — every file already has an identity type sitting right there (String, Integer, or some custom class), and VClass already covers the value side on its own since it's got the dual-mode toggle built in — it doesn't need an IElement/VElement pairing to "be" the value case, it already is one. Quick explanation of the mechanism: @AsValueClass + the ValueClassPlugin let one class (VClass) act as both an identity class and a value class, depending on how the suite gets run. Normal run = plain identity class. Run with VALUE_CLASS_PLUGIN=true, the plugin enables preview and flips the class to an actual value class at compile time. So the dual-mode toggle is baked into VClass itself, the test file never sees it. That's why a test doesn't need to explicitly run twice per file to get both identity and value coverage — it just uses VClass, and the same test gets compiled/run under both jtreg configs automatically. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32201#issuecomment-5455383470 PR Comment: https://git.openjdk.org/jdk/pull/32201#issuecomment-5455401268
