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 773:

> 771:             t = types.skipTypeVars(t, false);
> 772:         }
> 773:         if (t.isIntersection()) {

The check for intersection is good. I was wondering if we also need a check for 
union types, but I think we are in the clear (at least for now) because value 
classes cannot extend (Runtime)Exception/Throwable. So, all good (but I'd add a 
comment, just in case)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/31120#discussion_r3310661874

Reply via email to