On Wed, 8 Jul 2026 18:25:54 GMT, Justin Lu <[email protected]> wrote:
>> This PR corrects the special case handling in `Locale.Builder.setLocale`.
>> The current handling always assumes a `Locale` matching the `ja/JP/JP` and
>> `th/TH/TH` special cases will contain the correct compatibility extensions.
>> A user can remove the extension or create a Locale in the form of the
>> special case without the correct compatibility extension.
>>
>> For example, the current implementation does the following,
>>
>>> jshell> loc = new Builder().setLocale(Locale.of("ja", "JP",
>>> "JP").stripExtensions()).build()
>>> loc ==> ja_JP
>>>
>>> jshell> loc = new
>>> Builder().setLocale(Locale.forLanguageTag("ja-JP-u-ca-foobar-x-lvariant-JP")).build()
>>> loc ==> ja_JP_#u-ca-foobar
>>
>> That is, it silently discards the ill-formed JP variant.
>>
>> With assertions on, this instead becomes a `NullPointerException` when the
>> extensions are not present, or an `AssertionError` when the extension has
>> the wrong value.
>>
>> For the example above, one would expect an `IllFormedLocaleException` to be
>> thrown, since without a correct compatibility extension, JP is merely an
>> invalid variant and `setLocale(Locale)` throws on ill-formed fields.
>>
>> The changes in this PR ensure that these cases throw as expected.
>>
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Justin Lu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Address other areas + narrow matching to exact matches only
src/java.base/share/classes/java/util/Locale.java line 524:
> 522: * in BCP 47 since the {@linkplain ##def_variant variants} are too
> short. To ease
> 523: * migration to BCP 47, these are treated specially during construction.
> Creation
> 524: * of these two cases generates a compatibility extension.
Since you replaced "constructor" with "Creation", you may also want to update
"during construction" here for consistency. Alternatively, these two sentences
could be combined to improve the flow
src/java.base/share/classes/java/util/Locale.java line 531:
> 529: * Unicode locale key {@code ca} (for "calendar") and type
> 530: * {@code japanese}. When a {@code Locale} is created with language
> "ja", an
> 531: * empty script, region "JP", variant "JP", and no extensions, the
> extension
"region" -> "country". Same for "th" below
test/jdk/java/util/Locale/LocaleEnhanceTest.java line 504:
> 502: // no/NO/NY case is normalized during `toLanguageTag`
> 503: // ja/JP/JP & th/TH/TH case is normalized during
> `forLanguageTag`
> 504: // Script prevents the legacy conversions
Maybe it was intentional, but I think aligning the comments (below as well)
would be more readable
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31728#discussion_r3547183764
PR Review Comment: https://git.openjdk.org/jdk/pull/31728#discussion_r3547202660
PR Review Comment: https://git.openjdk.org/jdk/pull/31728#discussion_r3547270067
