On Mon, 27 Apr 2026 07:24:11 GMT, Dusan Balek <[email protected]> wrote:

>> With the `SwitchBootstraps.typeSwitch(...)` method, there is a specification 
>> issue (difference between what is written in the method's Javadoc and its 
>> actual behaviour) causing some JCK tests to fail.
>> 
>> The proposal here is:
>> Adjust the Javadoc of the `SwitchBootstraps.typeSwitch(...)` method to 
>> reflect the following changes in the behaviour of the method:
>> - the method no longer requires a `target` to be of a reference type 
>> (primitive type targets are allowed now)
>> - primitive type `labels` are allowed now if the preview features are enabled
>> 
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Dusan Balek has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Updating Javadoc as suggested in CSR

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 137:

> 135:      * {@code labels} are an array of case labels which must be non-null 
> and of
> 136:      * type {@code String}, {@code Integer}, {@code Class}, or {@code 
> EnumDesc}.
> 137:      * In addition, when preview features are enabled, {@code Long}, 
> {@code Float},

I am imagining a preview-block like this ideally, but we can hold on and wait 
for the note tag JEP instead. 
https://github.com/openjdk/valhalla/blob/2df83c2090e199be376f5b775fcb98d982c8803d/src/java.base/share/classes/java/lang/Object.java#L36

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 142:

> 140:      * The type of the returned {@code CallSite}'s method handle will 
> have
> 141:      * a return type of {@code int}.   It has two parameters: the first 
> argument
> 142:      * will be an instance or value of the ({@code target}) type and the 
> second

Suggestion:

     * will be a value of the ({@code target}) type and the second


An objecct instance or `null` is a "reference value" per JLS 4, and this can be 
considered as "value" when combined with primitive values.

Ideally "will be" should be replaced with "is" here and below.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 161:

> 159:      *       and equals to the target (matched by value comparison using 
> {@code ==}
> 160:      *       after unboxing if necessary)</li>
> 161:      *   <li>the element is of type {@code Float} or {@code Double} 
> (preview)

Suggestion:

     *   <li>(Preview) the element is of type {@code Long} or {@code Boolean}
     *       and equals to the target (matched by value comparison using {@code 
==}
     *       after unboxing if necessary)</li>
     *   <li>(Preview) the element is of type {@code Float} or {@code Double}

Make this status more explicit.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 165:

> 163:      *       {@code equals} on boxed values)</li>
> 164:      *   <li>the element is of type {@code EnumDesc}, that describes a 
> constant
> 165:      *       that is equal to the target (matched using {@code ==} on 
> enum constants)</li>

I think instead of using "(matched using ..." we should use phrases like:
`that {@code equals} the target`
`that {@code ==} the target`

More concise and straightforward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/30703#discussion_r3148004426
PR Review Comment: https://git.openjdk.org/jdk/pull/30703#discussion_r3147988255
PR Review Comment: https://git.openjdk.org/jdk/pull/30703#discussion_r3147962579
PR Review Comment: https://git.openjdk.org/jdk/pull/30703#discussion_r3147978809

Reply via email to