[EXTERNAL] Re: 4-letter patterns in Date Format Style no longer give full text style

[Bruno Borges]

Thanks all for your comments.

My issue has been on writing a library (baseline with 8, but support 9+ as well) that may take locale as a String input, and it is likely it will come in languaceCode_countryCode format (with underscore instead of dash). My questions started after noticing that in Java 8, new Locale("en_US") was working in our unit tests giving me the right locale with the correct language code, and the correct country code. Then, in Java 9+ due to JEP 252, the unit tests were failing.

If this was an end user application, the solution would certainly to be to tweak the system property as suggested.

To address the issue for the library, I implemented a simple locale parser to check whether the input has a dash, or an underscore. If underscore, then I split the string. Otherwise, I pass it on to Locale(String).

I was just hoping that Locale would have such builder method, similar to Locale.forLanguageTag().

Is it a fair conclusion that perhaps the issue has always been with Locale(String language) accepting languageCode_countryCode as input in Java 8 (due to the legacy database) ?


________________________________
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: July 10, 2023 11:51 PM
To: Bruno Borges <Bruno.Borges at microsoft.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Cc: Naoto Sato <naoto.sato at oracle.com>
Subject: Re: [EXTERNAL] Re: 4-letter patterns in Date Format Style no longer give full text style



On 10/07/2023 21:09, Naoto Sato wrote:
> :
>
>>
>> And isn't this the case of a breaking change more than just updating
>> the time database used by default in JDK?
>
> You could specify the system property `java.locale.providers` to
> COMPAT to use the JDK8 locales (although this has been deprecated in
> JDK21). However, expecting US resources with Locale("en_US") is
> incorrect in the first place.

Just to add to Naoto's comments.

JDK 8 was the first release to include CLDR locale data (JEP 127). JDK 8
continued to use the legacy JRE locale data by default but the system
property could be use to try out CLDR data in advance of the switch to
using it by default in JDK 9 (JEP 252). From JDK 9 to this day, the
system property can be used to switch back to the JRE lcoale data
although this locale data hasn't been maintained for several years.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230711/f3ab39cc/attachment.htm>