On Mon, 15 Jun 2026 14:17:29 GMT, Jaikiran Pai <[email protected]> wrote:
>> David Simms has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 2798 commits: >> >> - Merge remote-tracking branch 'valhalla/lworld' into >> jep401_sub_review_8317279 >> - 8386239: [lworld] Update jdk/java/util/Arrays/ArraysEqCmpTest.java >> >> Reviewed-by: liach >> - 8386242: [lworld] Simplify and clarify StrictProcessor >> >> Reviewed-by: dsimms >> - 8386140: [lworld] FieldReflector using wrong Class argument >> >> Reviewed-by: alanb, dsimms >> - 8386216: [lworld] Rollback meaningless diff in EventClassBuilder >> >> Reviewed-by: dsimms >> - 8385170: [lworld] Serialization spec needs to allow abstract value >> classes like Number >> >> Reviewed-by: liach >> - 8385980: [lworld] Standardize pattern for preview value class generation >> >> Reviewed-by: liach >> - 8386086: [lworld] >> sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java should be >> removed from problem list >> >> Reviewed-by: liach, dcubed >> - Merge >> >> Merge jdk-28+1 >> - 8386090: [lworld] Redundant test changes in lworld versus mainline >> >> Reviewed-by: vromero >> - ... and 2788 more: https://git.openjdk.org/jdk/compare/92298786...4d6d2888 > > src/java.base/share/classes/java/lang/Boolean.java line 58: > >> 56: * Use of value class instances for synchronization, mutexes, >> or with >> 57: * {@linkplain java.lang.ref.Reference object references} >> result in >> 58: * {@link IdentityException}. > > Should we specify the behaviour of value classes, for example when it comes > to synchronization, at one single place and if necessary just link to that > place instead of repeating this detail in all of the value class' javadocs? > Perhaps the javadoc of `Class.isValue()` is a good place to specify this > detail? > > If it takes a lot of rework to remove the duplicated text, then perhaps it > could be done as a post integration cleanup? I think we have such repeated details following the guides set by ValueBased annotation. And I think this simply shares some problematic uses without specifying too many details. > src/java.base/share/classes/java/lang/Boolean.java line 187: > >> 185: * <p> >> 186: * - When preview features are enabled, {@code >> Boolean} is a {@linkplain Class#isValue value class}. >> 187: * The {@code valueOf} behavior is the same as >> invoking the constructor. > > Both the constructors of `Boolean` class are deprecated. Furthermore, the > current specification of those constructors use the term "allocate": > >> Allocates a {@code Boolean} object representing the >> {@code value} argument. > > Given this, should this new semantics related to value classes be specified > without reference to these existing deprecated constructors? These constructors have been changed from deprecated for removal to plain deprecation in 25. The plan is to remove deprecation once Value Objects leaves preview. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31123#discussion_r3415806974 PR Review Comment: https://git.openjdk.org/jdk/pull/31123#discussion_r3415799148
