<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks all for your comments.</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
If this was an end user application, the solution would certainly to be to tweak the system property as suggested.</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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).</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
I was just hoping that Locale would have such builder method, similar to Locale.forLanguageTag().</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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) ?</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Alan Bateman <Alan.Bateman@oracle.com><br>
<b>Sent:</b> July 10, 2023 11:51 PM<br>
<b>To:</b> Bruno Borges <Bruno.Borges@microsoft.com>; core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><br>
<b>Cc:</b> Naoto Sato <naoto.sato@oracle.com><br>
<b>Subject:</b> Re: [EXTERNAL] Re: 4-letter patterns in Date Format Style no longer give full text style</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
<br>
On 10/07/2023 21:09, Naoto Sato wrote:<br>
> :<br>
><br>
>><br>
>> And isn't this the case of a breaking change more than just updating <br>
>> the time database used by default in JDK?<br>
><br>
> You could specify the system property `java.locale.providers` to <br>
> COMPAT to use the JDK8 locales (although this has been deprecated in <br>
> JDK21). However, expecting US resources with Locale("en_US") is <br>
> incorrect in the first place.<br>
<br>
Just to add to Naoto's comments.<br>
<br>
JDK 8 was the first release to include CLDR locale data (JEP 127). JDK 8 <br>
continued to use the legacy JRE locale data by default but the system <br>
property could be use to try out CLDR data in advance of the switch to <br>
using it by default in JDK 9 (JEP 252). From JDK 9 to this day, the <br>
system property can be used to switch back to the JRE lcoale data <br>
although this locale data hasn't been maintained for several years.<br>
<br>
-Alan<br>
</div>
</span></font></div>
</body>
</html>