On Mon, 25 May 2026 09:01:40 GMT, David Simms <[email protected]> wrote:
>> This pull request implements the first >> [preview](https://openjdk.org/jeps/12) of [JEP 401: Value Classes and >> Objects](https://openjdk.org/jeps/401): >> >> - [JDK-8317277](https://bugs.openjdk.org/browse/JDK-8317277): Java language >> implementation of value classes and objects >> - https://github.com/openjdk/jdk/pull/31121 >> - [JDK-8317278](https://bugs.openjdk.org/browse/JDK-8317278): JVM >> implementation of value classes and objects >> - https://github.com/openjdk/jdk/pull/31122 >> - [JDK-8317279](https://bugs.openjdk.org/browse/JDK-8317279): Standard >> library implementation of value classes and objects >> - https://github.com/openjdk/jdk/pull/31123 >> >> This pull request also includes the implementation of [Strict Field >> Initialization in the JVM (Preview)](https://openjdk.org/jeps/8350458) (yet >> to have been assigned a JEP number). That work was implemented in the same >> code base because JEP 401 depends on strict field initialization. >> >> This is the "*master pull request*" for the initial preview of [JEP >> 401](https://openjdk.org/jeps/401). Comments and review for a change this >> large will not scale well in a single pull request. This pull request serves >> as the vehicle for sign-off and integration into >> [`jdk/master`](https://github.com/openjdk/jdk). **Review comments should be >> directed to the appropriate "*sub-review pull request*" listed above.** >> >>> [!NOTE] >>> The "*sub-review pull requests*" contain the same full set of code changes >>> as this "*master pull request*" to preserve the full implementation >>> context; the language compiler, JVM, and standard library changes are >>> intertwined. The separate pull requests exist only to subdivide the review >>> and related discussion by area. >> >> Any resulting code changes should be made in >> [`valhalla/lworld`](https://github.com/openjdk/valhalla/). >> >> `valhalla/lworld` is currently updated from `jdk/master` whenever a weekly >> [`jdk` tag](https://github.com/openjdk/jdk/tags) is created. At that time, >> code changes from `valhalla/lworld` will be propagated to this pull request >> and to all sub-review pull requests. >> >> Ultimately, review sign-off will be recorded on this "*master pull >> request*", and the "*sub-review pull requests*" will be closed without >> integration. >> >> This pull request has a large surface area and frequently conflicts with >> `jdk/master`. Refer to >> [`valhalla/lworld`](https://github.com/openjdk/valhalla/) for the latest >> state of the project code, keeping in mind that it may lag several days >> behind `jdk/mast... > > David Simms has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 2732 commits: > > - Merge remote-tracking branch 'valhalla/lworld' into 8317277 > - 8385344: [lworld] ProblemList > tools/javac/platform/CanHandleClassFilesTest.java with --enable-preview > > Reviewed-by: fparain > - 8385301: [lworld] Remove > serviceability/sa/TestJhsdbJstackMixedWithXComp.java from problem list > > Reviewed-by: dsimms > - 8385331: [lworld] adjust ValueComparisonTest.java again to work around > JDK-8370769 > > Reviewed-by: dsimms > - 8385311: [lworld] TypePtr::eq() should use accessor method for _offset > > Reviewed-by: mchevalier > - 8385259: [lworld] Clean up LP64 in x86 code > > Reviewed-by: dlong, thartmann > - Merge > > Merge jdk-27+23 > - 8384924: [lworld] misc cleanups > > Reviewed-by: thartmann > - 8385167: [lworld] C1: minor cleanups > > Reviewed-by: dlong, thartmann > - 8384066: [lworld] TestDeadAllocationRemoval.java is ignored by jtreg > > Reviewed-by: thartmann > - ... and 2722 more: https://git.openjdk.org/jdk/compare/86637704...b3b4a2cb src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5137: > 5135: name = method.getSimpleName().toString(); > 5136: if (serialMethodNames.contains(name)) { > 5137: if (switch (name) { My feeling here is that most changes are not needed. We can keep the structure of the code more similar to what's in master, then: * when we check writeObject/readObject/readObjectNoData -- if these method are well-defined and we are in a value class, issue a warning that these methods are not really used * for writeReplace, it's probably better to turn the check into a boolean returning method (like you did), and then track outside whether we've seen a writeReplace. If we haven't, then we can check if the class is inheriting one. * to do the inheritance check, we don't need resolve, we can simply do a symbol lookup that filters all inherited members, and then calls "hasAppropriateWriteReplace" accordingly. If we see one, done. An example of the lookup could be: Predicate<Symbol> inheritedWriteReplace = s -> s.kind == MTH && s.name == names.writeReplace && s.isInheritedIn(c, types); for (Symbol s : types.membersClosure(superclass, true) .getSymbolsByName(names.writeReplace, inheritedWriteReplace, RECURSIVE)) { if (hasAppropriateWriteReplace(tree, (MethodSymbol) s, false)) { return true; } } Note that this skips members in interface, which is what you want -- because the serialization runtime code will ignore non-class writeReplace. This should also allow us to get rid of the extra `env` field in the visitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31120#discussion_r3310857717
