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

  Review - make empty script required for legacy locles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/31728/files
  - new: https://git.openjdk.org/jdk/pull/31728/files/280eb852..0f4c9fa8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=31728&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=31728&range=00-01

  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/31728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/31728/head:pull/31728

PR: https://git.openjdk.org/jdk/pull/31728

Reply via email to