From ramanand.patil at oracle.com  Wed Jun  1 12:08:23 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Wed, 1 Jun 2016 05:08:23 -0700 (PDT)
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <f0ea741f-2873-a2ff-cdce-40785b5c442b@oracle.com>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
	<12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
	<57486210.7090205@oracle.com>
	<c2c8e2eb-79ad-f4d8-9380-aa9f021c73f6@oracle.com>
	<783f0b2f-43fb-40ed-9204-889b9a3c2570@default>
	<d9b71b38-caac-9fdb-a28d-614e8bb183d1@oracle.com>
	<f0ea741f-2873-a2ff-cdce-40785b5c442b@oracle.com>
Message-ID: <341b4c8c-48be-4f57-86d2-0f211179a8c9@default>

Hi all,

?

As mentioned by point 4 in my first review thread, one test case is still failing for which a separate JBS bug is created.( https://bugs.openjdk.java.net/browse/JDK-8157792 ).

Below edit is needed for green tests and issue will be revisited via JDK-8157792.

?

--- a/test/sun/util/calendar/zi/TestZoneInfo310.java

+++ b/test/sun/util/calendar/zi/TestZoneInfo310.java

@@ -164,6 +164,10 @@

???????? }

?????????for (String zid : zids_new) {

+??????????? if (zid.equals("Asia/Oral") || zid.equals("Asia/Qyzylorda")) {

+??????????????? // JDK-8157792 tracking this issue

+??????????????? continue;

+??????????? }

???????????? ZoneInfoOld zi = toZoneInfoOld(TimeZone.getTimeZone(zid));

???????????? ZoneInfoOld ziOLD = (ZoneInfoOld)ZoneInfoOld.getTimeZone(zid);

???????????? if (! zi.equalsTo(ziOLD)) {

?

?

Regards,

Ramanand.

?

?

From: Se?n Coffey 
Sent: Tuesday, May 31, 2016 3:05 PM
To: Masayoshi Okutsu; Ramanand Patil; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016d

?

Masayoshi,

I still think the test adds value. At minimum it identifies timezones which don't have a localised string in the JRE provider. 

We need to start another discussion about how best to represent timezone names for newly added timezones. At the moment, short and long formats will be of "GMT?hh:mm" format. I suggest we use the IANA timezone name for the long format name in future (e.g. "Asia/Tomsk" instead of "GMT+06:00")

For the sake of getting this into the JDK code lines, I suggest we go ahead with your suggestion to remove the test for now. I've also reviewed this Ramanand. Your edits look fine (including test removal for now)

Regards, 
Sean.

On 31/05/2016 07:06, Masayoshi Okutsu wrote:

The CheckDisplayNames.java change is different from what I suggested and doesn't make sense. But we no longer need the test. I'd suggest CheckDisplayNames.java be removed. Otherwise, the fix looks OK to me.

Masayoshi

?

On 5/31/2016 3:03 AM, Ramanand Patil wrote:

Hi Masayoshi and All,

?

Here is the updated Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.01/"http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/

?

As suggested by Masayoshi, I have kept the existing names unchanged.


Also, this patch contains extra test case fixes for


1.?? ?java/util/TimeZone/CheckDisplayNames.java 


2.?? java/util/TimeZone/Bug8149452.java


The exclusion for the newly added TimeZones is added in these test cases where the entries are not present in the resources and the Short/Long display names fallback to the GMT?hh:mm format.

?

?

Regards,

Ramanand.

?

From: Masayoshi Okutsu 
Sent: Saturday, May 28, 2016 10:58 AM
To: Se?n Coffey; Ramanand Patil; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016d

?

CLDR locale data defines time zone names, like this (in en.xml):

?????????????????????? <metazone type="Almaty">
??????????????????????????????? <long>
??????????????????????????????????????? <generic>Almaty Time</generic>
???????????????????????????????? ???????<standard>Almaty Standard Time</standard>
??????????????????????????????????????? <daylight>Almaty Summer Time</daylight>
??????????????????????????????? </long>
??????????????????????? </metazone>
?

The CLDR converter tool tries to fill in the missing short names from the legacy TimeZoneNames data. Removing existing names causes some unexpected behavior. I think JDK-8157814 is an example of the unexpected behavior. And the suggested fix in JDK-8157814 looks to me like a workaround.

I still think the existing names should be kept unchanged for this fix.

Thanks,
Masayoshi

On 5/28/2016 12:04 AM, Se?n Coffey wrote:

I guess there's a low risk of timezone not being identified if being parsed in through a formatter. Isn't such an approach discouraged though ? short IDs were already subject to change in tzdata releases. Ramanand found one issue by removal of these resource strings (so far) and that's captured in JDK-8157814

There's a decision to be made about how to use the GMT?hh:mm format for new releases given IANA's new short ID identifier mechanism. I think that could be discussed as a separate issue. I'd like to see us follow a similar approach to IANA and use GMT identifiers on new timezones and perhaps even consider using the IANA long name format also for the getDisplayName(..) calls that can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time" 

Regards,
Sean.

On 27/05/16 15:24, Masayoshi Okutsu wrote:

This change seems to beyond my proposal that the "GMT?hh:mm" format is used for *new* zones with the "?hh" format. But this change removes *existing* zones which have changed to use the "?hh" format in tzdata. Can this cause any compatibility issues? 

And have we agreed to use the "GMT?hh:mm" format? 

Thanks, 
Masayoshi 


On 5/27/2016 10:19 PM, Se?n Coffey wrote: 




Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. 

Regards, 
Sean. 

On 26/05/16 14:22, Ramanand Patil wrote: 




HI all, 

Please review the latest TZDATA integration (tzdata2016d) to JDK9. 

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/"http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ 

Patch Contains: 

1.?????? IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated]. 

2.?????? "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d. 

[This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] 

3.?????? Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names. 

4.?????? Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch. 


Regards, 

Ramanand. 

?

?

?

?

?

?

From sean.coffey at oracle.com  Wed Jun  1 12:16:46 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 1 Jun 2016 13:16:46 +0100
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <341b4c8c-48be-4f57-86d2-0f211179a8c9@default>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
	<12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
	<57486210.7090205@oracle.com>
	<c2c8e2eb-79ad-f4d8-9380-aa9f021c73f6@oracle.com>
	<783f0b2f-43fb-40ed-9204-889b9a3c2570@default>
	<d9b71b38-caac-9fdb-a28d-614e8bb183d1@oracle.com>
	<f0ea741f-2873-a2ff-cdce-40785b5c442b@oracle.com>
	<341b4c8c-48be-4f57-86d2-0f211179a8c9@default>
Message-ID: <574ED22E.9090207@oracle.com>

That test edit looks fine Ramanand and will ensure that the test runs 
remain green. I'll push this change for you now.

Regards,
Sean.

On 01/06/16 13:08, Ramanand Patil wrote:
>
> Hi all,
>
> As mentioned by point 4 in my first review thread, one test case is 
> still failing for which a separate JBS bug is created.( 
> https://bugs.openjdk.java.net/browse/JDK-8157792 ).
>
> Below edit is needed for green tests and issue will be revisited via 
> JDK-8157792.
>
> --- a/test/sun/util/calendar/zi/TestZoneInfo310.java
>
> +++ b/test/sun/util/calendar/zi/TestZoneInfo310.java
>
> @@ -164,6 +164,10 @@
>
> }
>
>          for (String zid : zids_new) {
>
> + if (zid.equals("Asia/Oral") || zid.equals("Asia/Qyzylorda")) {
>
> + // JDK-8157792 tracking this issue
>
> + continue;
>
> + }
>
> ZoneInfoOld zi = toZoneInfoOld(TimeZone.getTimeZone(zid));
>
> ZoneInfoOld ziOLD = (ZoneInfoOld)ZoneInfoOld.getTimeZone(zid);
>
> if (! zi.equalsTo(ziOLD)) {
>
> Regards,
>
> Ramanand.
>
> *From:*Se?n Coffey
> *Sent:* Tuesday, May 31, 2016 3:05 PM
> *To:* Masayoshi Okutsu; Ramanand Patil; i18n-dev at openjdk.java.net; 
> core-libs-dev at openjdk.java.net
> *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d
>
> Masayoshi,
>
> I still think the test adds value. At minimum it identifies timezones 
> which don't have a localised string in the JRE provider.
>
> We need to start another discussion about how best to represent 
> timezone names for newly added timezones. At the moment, short and 
> long formats will be of "GMT?hh:mm" format. I suggest we use the IANA 
> timezone name for the long format name in future (e.g. "Asia/Tomsk" 
> instead of "GMT+06:00")
>
> For the sake of getting this into the JDK code lines, I suggest we go 
> ahead with your suggestion to remove the test for now. I've also 
> reviewed this Ramanand. Your edits look fine (including test removal 
> for now)
>
> Regards,
> Sean.
>
> On 31/05/2016 07:06, Masayoshi Okutsu wrote:
>
>     The CheckDisplayNames.java change is different from what I
>     suggested and doesn't make sense. But we no longer need the test.
>     I'd suggest CheckDisplayNames.java be removed. Otherwise, the fix
>     looks OK to me.
>
>     Masayoshi
>
>     On 5/31/2016 3:03 AM, Ramanand Patil wrote:
>
>         Hi Masayoshi and All,
>
>         Here is the updated Webrev:
>         http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/
>         <http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.01/>
>
>         As suggested by Masayoshi, I have kept the existing names
>         unchanged.
>
>
>             Also, this patch contains extra test case fixes for
>
>
>             1./java/util/TimeZone/CheckDisplayNames.java/
>
>
>             2.java/util/TimeZone/Bug8149452.java
>
>         The exclusion for the *newly* added TimeZones is added in
>         these test cases where the entries are not present in the
>         resources and the Short/Long display names fallback to the
>         GMT?hh:mm format.
>
>         Regards,
>
>         Ramanand.
>
>         *From:*Masayoshi Okutsu
>         *Sent:* Saturday, May 28, 2016 10:58 AM
>         *To:* Se?n Coffey; Ramanand Patil; i18n-dev at openjdk.java.net
>         <mailto:i18n-dev at openjdk.java.net>;
>         core-libs-dev at openjdk.java.net
>         <mailto:core-libs-dev at openjdk.java.net>
>         *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d
>
>         CLDR locale data defines time zone names, like this (in en.xml):
>
>                                 <metazone type="Almaty">
>
>                                          <long>
>
>                                                  <generic>Almaty Time</generic>
>
>                                                  <standard>Almaty Standard Time</standard>
>
>                                                  <daylight>Almaty Summer Time</daylight>
>
>                                          </long>
>
>                                  </metazone>
>
>           
>
>         The CLDR converter tool tries to fill in the missing short
>         names from the legacy TimeZoneNames data. Removing existing
>         names causes some unexpected behavior. I think JDK-8157814 is
>         an example of the unexpected behavior. And the suggested fix
>         in JDK-8157814 looks to me like a workaround.
>
>         I still think the existing names should be kept unchanged for
>         this fix.
>
>         Thanks,
>         Masayoshi
>
>         On 5/28/2016 12:04 AM, Se?n Coffey wrote:
>
>             I guess there's a low risk of timezone not being
>             identified if being parsed in through a formatter. Isn't
>             such an approach discouraged though ? short IDs were
>             already subject to change in tzdata releases. Ramanand
>             found one issue by removal of these resource strings (so
>             far) and that's captured in JDK-8157814
>
>             There's a decision to be made about how to use the
>             GMT?hh:mm format for new releases given IANA's new short
>             ID identifier mechanism. I think that could be discussed
>             as a separate issue. I'd like to see us follow a similar
>             approach to IANA and use GMT identifiers on new timezones
>             and perhaps even consider using the IANA long name format
>             also for the getDisplayName(..) calls that can be made.
>             e.g. "Asia/Almaty" instead of "Alma-Ata Time"
>
>             Regards,
>
>             Sean.
>
>             On 27/05/16 15:24, Masayoshi Okutsu wrote:
>
>                 This change seems to beyond my proposal that the
>                 "GMT?hh:mm" format is used for *new* zones with the
>                 "?hh" format. But this change removes *existing* zones
>                 which have changed to use the "?hh" format in tzdata.
>                 Can this cause any compatibility issues?
>
>                 And have we agreed to use the "GMT?hh:mm" format?
>
>                 Thanks,
>                 Masayoshi
>
>
>                 On 5/27/2016 10:19 PM, Se?n Coffey wrote:
>
>
>                 Looks fine to me Ramanand. the recent 2016d changes
>                 have introduced some boundary issues for JDK rule
>                 parsing and those issues can be followed up in
>                 separate issues like you say.
>
>                 Regards,
>                 Sean.
>
>                 On 26/05/16 14:22, Ramanand Patil wrote:
>
>
>                 HI all,
>
>                 Please review the latest TZDATA integration
>                 (tzdata2016d) to JDK9.
>
>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>
>                 Webrev:
>                 http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>                 <http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/>
>
>                 Patch Contains:
>
>                 1.       IANA tzdata2016d integration into JDK. [It
>                 also includes tzdata2016b and tzdata2016c which was
>                 not integrated].
>
>                 2.       "GMT[+ -]hh:mm" is used for formatting of the
>                 modified or newly added TimeZones in tzdata2016d.
>
>                 [This is done to accommodate the IANA's new system
>                 where the zones use numeric time zone abbreviations
>                 like "+04" instead of invented abbreviations like
>                 "ASTT".]
>
>                 3.       Test case:
>                 java/time/test/java/time/format/TestZoneTextPrinterParser.java
>                 is updated to include the failures because of GMT[+
>                 -]hh:mm format names.
>
>                 4.       Few other failing tests: For few other
>                 failing tests, new linked bugs are created and will be
>                 addressed in a separate patch.
>
>
>                 Regards,
>
>                 Ramanand.
>


From mandy.chung at oracle.com  Fri Jun  3 04:09:13 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 2 Jun 2016 21:09:13 -0700
Subject: <i18n dev> Review request: JDK-8158604:
	test/java/util/ResourceBundle/modules/appbasic missing @test
Message-ID: <CF263F4C-3007-4077-BB27-DCF3BBF4E768@oracle.com>

Masayoshi,

test/java/util/ResourceBundle/modules/appbasic is not run because appbasic.sh was missed.  I notice it while looking at the existing tests.  I took the opportunity to improve the javadoc and update appbasic test to serve as a simple example of AbstractResourceBundleProvider.

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8158604/

Mandy


From masayoshi.okutsu at oracle.com  Fri Jun  3 06:34:23 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 3 Jun 2016 15:34:23 +0900
Subject: <i18n dev> Review request: JDK-8158604:
 test/java/util/ResourceBundle/modules/appbasic missing @test
In-Reply-To: <CF263F4C-3007-4077-BB27-DCF3BBF4E768@oracle.com>
References: <CF263F4C-3007-4077-BB27-DCF3BBF4E768@oracle.com>
Message-ID: <2b19c19a-8ebd-e090-099a-d3bedeeeb1d8@oracle.com>

Glad you fixed this earlier prototype of appbasic which had 
accidentally(?) been pushed to Jake. The copyright year of some files 
haven't been updated. Otherwise, this fix looks good to me.

Thanks,
Masayoshi


On 6/3/2016 1:09 PM, Mandy Chung wrote:
> Masayoshi,
>
> test/java/util/ResourceBundle/modules/appbasic is not run because appbasic.sh was missed.  I notice it while looking at the existing tests.  I took the opportunity to improve the javadoc and update appbasic test to serve as a simple example of AbstractResourceBundleProvider.
>
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8158604/
>
> Mandy
>


From Alan.Bateman at oracle.com  Fri Jun  3 07:23:38 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Jun 2016 08:23:38 +0100
Subject: <i18n dev> Review request: JDK-8158604:
 test/java/util/ResourceBundle/modules/appbasic missing @test
In-Reply-To: <CF263F4C-3007-4077-BB27-DCF3BBF4E768@oracle.com>
References: <CF263F4C-3007-4077-BB27-DCF3BBF4E768@oracle.com>
Message-ID: <f257dbf7-09e9-3d35-9844-e5190bf41e6e@oracle.com>



On 03/06/2016 05:09, Mandy Chung wrote:
> Masayoshi,
>
> test/java/util/ResourceBundle/modules/appbasic is not run because appbasic.sh was missed.  I notice it while looking at the existing tests.  I took the opportunity to improve the javadoc and update appbasic test to serve as a simple example of AbstractResourceBundleProvider.
>
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8158604/
>
>
Looks good except ResourceBundleProvider.java L33 where I assume the 
full spot has been removed so two sentences run into each other.

-Alan

From nishit.jain at oracle.com  Tue Jun  7 05:20:14 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 7 Jun 2016 10:50:14 +0530
Subject: <i18n dev> Review Request for JDK-8047780: Locale.LanguageRange()
 throws an undocumented IAE when range is ill-formed.
Message-ID: <0741de3c-0ae1-80cb-d590-d6eec3405c5e@oracle.com>

Hi,

Please review the fix for JDK-8047780

Bug: https://bugs.openjdk.java.net/browse/JDK-8047780
Webrev: http://cr.openjdk.java.net/~nishjain/8047780/webrev.01/

Fix: Added in the api spec that the IllegalArgumentException can be 
thrown if the given "range" is ill-formed

Regards,
Nishit Jain



From masayoshi.okutsu at oracle.com  Wed Jun  8 03:31:01 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 8 Jun 2016 12:31:01 +0900
Subject: <i18n dev> Review Request for JDK-8047780:
 Locale.LanguageRange() throws an undocumented IAE when range is ill-formed.
In-Reply-To: <0741de3c-0ae1-80cb-d590-d6eec3405c5e@oracle.com>
References: <0741de3c-0ae1-80cb-d590-d6eec3405c5e@oracle.com>
Message-ID: <3cef9e36-f913-3141-0bba-4b65de93109b@oracle.com>

Looks good.

Masayoshi


On 6/7/2016 2:20 PM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8047780
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8047780
> Webrev: http://cr.openjdk.java.net/~nishjain/8047780/webrev.01/
>
> Fix: Added in the api spec that the IllegalArgumentException can be 
> thrown if the given "range" is ill-formed
>
> Regards,
> Nishit Jain
>
>


From yuka.kamiya at oracle.com  Wed Jun  8 03:34:50 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 8 Jun 2016 12:34:50 +0900
Subject: <i18n dev> Review Request for JDK-8047780:
 Locale.LanguageRange() throws an undocumented IAE when range is ill-formed.
In-Reply-To: <3cef9e36-f913-3141-0bba-4b65de93109b@oracle.com>
References: <0741de3c-0ae1-80cb-d590-d6eec3405c5e@oracle.com>
	<3cef9e36-f913-3141-0bba-4b65de93109b@oracle.com>
Message-ID: <f7f2daae-6a14-f904-a598-2debc45f12d1@oracle.com>

+1

On 2016/06/08 12:31, Masayoshi Okutsu wrote:
> Looks good.
>
> Masayoshi
>
>
> On 6/7/2016 2:20 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8047780
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047780
>> Webrev: http://cr.openjdk.java.net/~nishjain/8047780/webrev.01/
>>
>> Fix: Added in the api spec that the IllegalArgumentException can be 
>> thrown if the given "range" is ill-formed
>>
>> Regards,
>> Nishit Jain
>>
>>
>


From nishit.jain at oracle.com  Fri Jun 10 06:20:08 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 10 Jun 2016 11:50:08 +0530
Subject: <i18n dev> Review Request for JDK-8040211: Update LSR datafile for
	BCP 47
Message-ID: <16f3919a-a341-fa5c-40ac-8a62f9ae39d0@oracle.com>

Hi,

Please review the fix for JDK-8040211

Bug: https://bugs.openjdk.java.net/browse/JDK-8040211
Webrev: http://cr.openjdk.java.net/~nishjain/8040211/webrev.02/

Fix: Updated the Language Subtag Registry data provided by IANA at 
"http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry" 
and the related java files

Regards,
Nishit Jain

From masayoshi.okutsu at oracle.com  Fri Jun 10 06:52:27 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 10 Jun 2016 15:52:27 +0900
Subject: <i18n dev> RFR: 8158272 & 8158468
 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
Message-ID: <a77a2697-0f00-ba78-a98c-ecd588e698f1@oracle.com>

Hi,

Please review fixes for 8158272 and 8158468. The test had several problems.

- A child process doesn't inherit IO. Any outputs from the child process 
are not logged.
- The exit code of a child process is ignored. The exit code needs to be 
checked by the test.
- A child process should use the exit code to report errors rather than 
throwing a RuntimeException.
- The golden data doesn't match the CLDR V29.
- It may not be a good idea to hard-code the full set of the available 
locales.

All have been fixed. Additional changes are:

- Removed -verbose:gc from @run
- Changed String to List<String> for the available locales data. It was 
hard to compare long strings.
- Changed output of the test so that it's easier to understand test 
activities.
- Replaced Locale.ROOT.toString() with "(root)"

As for the timeout issue, what happened is that a child process for 
checking available locales threw a RuntimeException due to the CLDR V29 
changes. But the parent process (the main test process) was waiting for 
the child process to terminate. I'm not sure if it's a Windows specific 
process management issue or jtreg specific issue or something else. But 
the timeout symptom is no longer reproducible with the change to call 
ProcessBuilder.inheritIO().

Issues:
https://bugs.openjdk.java.net/browse/JDK-8158272
https://bugs.openjdk.java.net/browse/JDK-8158468

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8158272.8158468/webrev.00

While I was working on these test problems, I noticed there are a few 
problems in the include locales plugin per se. For example, 
--include-locales=*-IN selects en-001 which is missing in the available 
locales list. (The missing "en-001" has been added to the test data, but 
it's commented out.) I will be filing a separate JBS issue.

Thanks,
Masayoshi


From masayoshi.okutsu at oracle.com  Fri Jun 10 07:08:59 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 10 Jun 2016 16:08:59 +0900
Subject: <i18n dev> RFR: 8158272 & 8158468
 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
Message-ID: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>

(re-sending to include jigsaw-dev)

Hi,

Please review fixes for 8158272 and 8158468. The test had several problems.

- A child process doesn't inherit IO. Any outputs from the child process 
are not logged.
- The exit code of a child process is ignored. The exit code needs to be 
checked by the test.
- A child process should use the exit code to report errors rather than 
throwing a RuntimeException.
- The golden data doesn't match the CLDR V29.
- It may not be a good idea to hard-code the full set of the available 
locales.

All have been fixed. Additional changes are:

- Removed -verbose:gc from @run
- Changed String to List<String> for the available locales data. It was 
hard to compare long strings.
- Changed output of the test so that it's easier to understand test 
activities.
- Replaced Locale.ROOT.toString() with "(root)"

As for the timeout issue, what happened is that a child process for 
checking available locales threw a RuntimeException due to the CLDR V29 
changes. But the parent process (the main test process) was waiting for 
the child process to terminate. I'm not sure if it's a Windows specific 
process management issue or jtreg specific issue or something else. But 
the timeout symptom is no longer reproducible with the change to call 
ProcessBuilder.inheritIO().

Issues:
https://bugs.openjdk.java.net/browse/JDK-8158272
https://bugs.openjdk.java.net/browse/JDK-8158468

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8158272.8158468/webrev.00

While I was working on these test problems, I noticed there are a few 
problems in the include locales plugin per se. For example, 
--include-locales=*-IN selects en-001 which is missing in the available 
locales list. (The missing "en-001" has been added to the test data, but 
it's commented out.) I will be filing a separate JBS issue.

Thanks,
Masayoshi


From masayoshi.okutsu at oracle.com  Fri Jun 10 08:17:50 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 10 Jun 2016 17:17:50 +0900
Subject: <i18n dev> Review Request for JDK-8040211: Update LSR datafile
 for BCP 47
In-Reply-To: <16f3919a-a341-fa5c-40ac-8a62f9ae39d0@oracle.com>
References: <16f3919a-a341-fa5c-40ac-8a62f9ae39d0@oracle.com>
Message-ID: <8d0bdc3a-53a0-90c9-351f-f8ecad03b5e3@oracle.com>

Looks good to me.

Masayoshi


On 6/10/2016 3:20 PM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8040211
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040211
> Webrev: http://cr.openjdk.java.net/~nishjain/8040211/webrev.02/
>
> Fix: Updated the Language Subtag Registry data provided by IANA at 
> "http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry" 
> and the related java files
>
> Regards,
> Nishit Jain


From yuka.kamiya at oracle.com  Fri Jun 10 10:11:58 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 10 Jun 2016 19:11:58 +0900
Subject: <i18n dev> Review Request for JDK-8040211: Update LSR datafile
 for BCP 47
In-Reply-To: <8d0bdc3a-53a0-90c9-351f-f8ecad03b5e3@oracle.com>
References: <16f3919a-a341-fa5c-40ac-8a62f9ae39d0@oracle.com>
	<8d0bdc3a-53a0-90c9-351f-f8ecad03b5e3@oracle.com>
Message-ID: <bc56ad51-6a59-8ebd-0740-5efc32e71c0f@oracle.com>

+1

On 2016/06/10 17:17, Masayoshi Okutsu wrote:
> Looks good to me.
>
> Masayoshi
>
>
> On 6/10/2016 3:20 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8040211
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040211
>> Webrev: http://cr.openjdk.java.net/~nishjain/8040211/webrev.02/
>>
>> Fix: Updated the Language Subtag Registry data provided by IANA at 
>> "http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry" 
>> and the related java files
>>
>> Regards,
>> Nishit Jain
>


From Alan.Bateman at oracle.com  Fri Jun 10 10:57:17 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 10 Jun 2016 11:57:17 +0100
Subject: <i18n dev> RFR: 8158272 & 8158468
 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
In-Reply-To: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
Message-ID: <ffeca960-2faf-e68c-8d10-d6124bbfe6d7@oracle.com>



On 10/06/2016 08:08, Masayoshi Okutsu wrote:
> (re-sending to include jigsaw-dev)
>
> Hi,
>
> Please review fixes for 8158272 and 8158468. The test had several 
> problems.
>
> - A child process doesn't inherit IO. Any outputs from the child 
> process are not logged.
> - The exit code of a child process is ignored. The exit code needs to 
> be checked by the test.
> - A child process should use the exit code to report errors rather 
> than throwing a RuntimeException.
> - The golden data doesn't match the CLDR V29.
> - It may not be a good idea to hard-code the full set of the available 
> locales.
>
> All have been fixed. Additional changes are:
>
> - Removed -verbose:gc from @run
> - Changed String to List<String> for the available locales data. It 
> was hard to compare long strings.
> - Changed output of the test so that it's easier to understand test 
> activities.
> - Replaced Locale.ROOT.toString() with "(root)"
>
> As for the timeout issue, what happened is that a child process for 
> checking available locales threw a RuntimeException due to the CLDR 
> V29 changes. But the parent process (the main test process) was 
> waiting for the child process to terminate. I'm not sure if it's a 
> Windows specific process management issue or jtreg specific issue or 
> something else. But the timeout symptom is no longer reproducible with 
> the change to call ProcessBuilder.inheritIO().
>
> Issues:
> https://bugs.openjdk.java.net/browse/JDK-8158272
> https://bugs.openjdk.java.net/browse/JDK-8158468
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8158272.8158468/webrev.00
>
> While I was working on these test problems, I noticed there are a few 
> problems in the include locales plugin per se. For example, 
> --include-locales=*-IN selects en-001 which is missing in the 
> available locales list. (The missing "en-001" has been added to the 
> test data, but it's commented out.) I will be filing a separate JBS 
> issue.
This looks quite good.

What would you think also changing testAvailableLocales to use 
ProcessTools. As it stands then it looks like the output/error streams 
from the child won't be printed to the test logs?

-Alan

From mark.reinhold at oracle.com  Fri Jun 10 14:07:03 2016
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 10 Jun 2016 07:07:03 -0700
Subject: <i18n dev> OpenJDK Governing Board CFV: New
	Internationalization Group Lead: Masayoshi Okutsu
In-Reply-To: <20160609082632.685067996eggemoggin.niobe.net>
References: <20160609082632.685067996eggemoggin.niobe.net>
Message-ID: <20160610070703.213413706eggemoggin.niobe.net>

2016/6/9 8:26:32 -0700, mark.reinhold at oracle.com:
> Naoto Sato recently resigned as the Lead of the Internationalization
> Group [1].  Masayoshi Okutsu was voted in as the new Group Lead shortly
> thereafter [2].
> 
> Governing Board members: Please vote on whether to ratify this change,
> as required by the Bylaws [3].  Votes are due in one week, by 16:00 UTC
> next Thursday, 16 June 2016.  Votes must be cast in the open by replying
> to this message.

Thank you for your votes.  A majority has voted in favor of ratification.
Masayoshi Okutsu is now the Lead of the Internationalization Group.

- Mark

From naoto.sato at oracle.com  Fri Jun 10 16:27:29 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 10 Jun 2016 09:27:29 -0700
Subject: <i18n dev> RFR: 8158272 & 8158468
 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
In-Reply-To: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
Message-ID: <f7fc7a45-db68-05e1-c06b-d088a577fe14@oracle.com>

+1. Thanks for fixing those issues.

Naoto

On 6/10/16 12:08 AM, Masayoshi Okutsu wrote:
> (re-sending to include jigsaw-dev)
>
> Hi,
>
> Please review fixes for 8158272 and 8158468. The test had several problems.
>
> - A child process doesn't inherit IO. Any outputs from the child process
> are not logged.
> - The exit code of a child process is ignored. The exit code needs to be
> checked by the test.
> - A child process should use the exit code to report errors rather than
> throwing a RuntimeException.
> - The golden data doesn't match the CLDR V29.
> - It may not be a good idea to hard-code the full set of the available
> locales.
>
> All have been fixed. Additional changes are:
>
> - Removed -verbose:gc from @run
> - Changed String to List<String> for the available locales data. It was
> hard to compare long strings.
> - Changed output of the test so that it's easier to understand test
> activities.
> - Replaced Locale.ROOT.toString() with "(root)"
>
> As for the timeout issue, what happened is that a child process for
> checking available locales threw a RuntimeException due to the CLDR V29
> changes. But the parent process (the main test process) was waiting for
> the child process to terminate. I'm not sure if it's a Windows specific
> process management issue or jtreg specific issue or something else. But
> the timeout symptom is no longer reproducible with the change to call
> ProcessBuilder.inheritIO().
>
> Issues:
> https://bugs.openjdk.java.net/browse/JDK-8158272
> https://bugs.openjdk.java.net/browse/JDK-8158468
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8158272.8158468/webrev.00
>
> While I was working on these test problems, I noticed there are a few
> problems in the include locales plugin per se. For example,
> --include-locales=*-IN selects en-001 which is missing in the available
> locales list. (The missing "en-001" has been added to the test data, but
> it's commented out.) I will be filing a separate JBS issue.
>
> Thanks,
> Masayoshi
>

From mandy.chung at oracle.com  Fri Jun 10 20:53:25 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 10 Jun 2016 13:53:25 -0700
Subject: <i18n dev> RFR: 8158272 & 8158468
	(tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
In-Reply-To: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
Message-ID: <15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>


> On Jun 10, 2016, at 12:08 AM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
> 
> (re-sending to include jigsaw-dev)
> 
> Hi,
> 
> Please review fixes for 8158272 and 8158468. The test had several problems.
> 
> :
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8158272.8158468/webrev.00

It?s good that you replace the hard-coded list of all available locales.  Is it possible to build the golden data programmatically to avoid hardcoding it?

As Alan already suggests, you should consider using ProcessTools testlibrary that will launch the child process with the options specified in jtreg command.

Otherwise looks okay.

Mandy


From masayoshi.okutsu at oracle.com  Mon Jun 13 06:10:50 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 13 Jun 2016 15:10:50 +0900
Subject: <i18n dev> RFR: 8158272 & 8158468
 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
In-Reply-To: <15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
Message-ID: <adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>

On 6/11/2016 5:53 AM, Mandy Chung wrote:
>> On Jun 10, 2016, at 12:08 AM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
>>
>> (re-sending to include jigsaw-dev)
>>
>> Hi,
>>
>> Please review fixes for 8158272 and 8158468. The test had several problems.
>>
>> :
>> Webrev:
>> http://cr.openjdk.java.net/~okutsu/9/8158272.8158468/webrev.00
> It?s good that you replace the hard-coded list of all available locales.  Is it possible to build the golden data programmatically to avoid hardcoding it?

I think that's possible, but it'll take time to develop it. I hope SQE 
will develop a better test.

> As Alan already suggests, you should consider using ProcessTools testlibrary that will launch the child process with the options specified in jtreg command.

I took a look at ProcessTools, but it doesn't seem to be very convenient 
for this test to use ProcessTools because the test needs to run java in 
the image produced by each jlink run. Do you think subprocesses created 
by the main test need to use jtreg options?

Thanks,
Masayoshi

From nishit.jain at oracle.com  Mon Jun 13 09:54:17 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 13 Jun 2016 15:24:17 +0530
Subject: <i18n dev> Review Request for JDK-8135061: java.util.Locale#lookup
 throws java.lang.StringIndexOutOfBoundsException for range having '-' as
 second character
Message-ID: <5e371ed5-7945-2586-3707-3d85d5987456@oracle.com>

Hi,

Please review the fix for JDK-8135061

Bug: https://bugs.openjdk.java.net/browse/JDK-8135061
Webrev: http://cr.openjdk.java.net/~nishjain/8135061/webrev.01/

Fix : Added a check on the lastIndexOf "-" before using substring for 
truncating the extension key

Regards,
Nishit Jain


From mandy.chung at oracle.com  Mon Jun 13 15:02:38 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 13 Jun 2016 08:02:38 -0700
Subject: <i18n dev> RFR: 8158272 & 8158468
	(tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
In-Reply-To: <adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
Message-ID: <A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>


> On Jun 12, 2016, at 11:10 PM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
> 
> On 6/11/2016 5:53 AM, Mandy Chung wrote:
>>> On Jun 10, 2016, at 12:08 AM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
>>> 
>>> (re-sending to include jigsaw-dev)
>>> 
>>> Hi,
>>> 
>>> Please review fixes for 8158272 and 8158468. The test had several problems.
>>> 
>>> :
>>> Webrev:
>>> http://cr.openjdk.java.net/~okutsu/9/8158272.8158468/webrev.00
>> It?s good that you replace the hard-coded list of all available locales.  Is it possible to build the golden data programmatically to avoid hardcoding it?
> 
> I think that's possible, but it'll take time to develop it. I hope SQE will develop a better test.
> 

OK.  It?d be good to file a JBS issue for it.

>> As Alan already suggests, you should consider using ProcessTools testlibrary that will launch the child process with the options specified in jtreg command.
> 
> I took a look at ProcessTools, but it doesn't seem to be very convenient for this test to use ProcessTools because the test needs to run java in the image produced by each jlink run. Do you think subprocesses created by the main test need to use jtreg options?

I see.  I?m fine with what you have.  We should enhance the jlink testlibrary to run java from a run-time image created for a test to run.  

Mandy

From Alan.Bateman at oracle.com  Mon Jun 13 20:18:33 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Jun 2016 21:18:33 +0100
Subject: <i18n dev> RFR: 8158272 & 8158468
 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
In-Reply-To: <A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
Message-ID: <34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>

On 13/06/2016 16:02, Mandy Chung wrote:

>
> I see.  I?m fine with what you have.  We should enhance the jlink testlibrary to run java from a run-time image created for a test to run.
>
I'm okay with it too.

-Alan

From naoto.sato at oracle.com  Mon Jun 13 21:43:03 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 13 Jun 2016 14:43:03 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
Message-ID: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>

Hi Brent,

On 6/13/16 1:58 PM, Brent Christian wrote:
>
> Apple suggested changing the JDK initialization order so any access to
> JRS happens only after the JLI_MemAlloc symbol is available.  We believe
> a better solution is to re-implement the JSR APIs in question, as a move
> toward eventually dropping reliance on JSR altogether.  The three main
> changes are:
>
> 1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using
> "CFLocaleCopyPreferredLanguages", which gives us the preferred language
> as set in "System Preferences"->"Language & Text"->"Language" in the
> form of "xx" (ie. just the language code - ex. "en", "fr", etc.).  The
> original Apple code then calls into
> "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
> "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though
> this appears to be unnecessary.  Following the call to
> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
> the language to a default country, per this comment:
>
>      * If the locale name (without .encoding at variant, if any) matches
>      * any of the names in the locale_aliases list, map it to the
>      * corresponding full locale name.  Most of the entries in the
>      * locale_aliases list are locales that include a language name but
>      * no country name, and this facility is used to map each language
>      * to a default country if that's possible.
>
> I tried out a few locales, for English (en_US, en_GB), German (de_DE,
> de_CH) and French (fr_FR, fr_CA).  Language/country system properties
> behave the same before and after this change, as does the
> java.util.Locale test attached to the bug.

So does this mean the new code will not honor the "Region" in the OSX's 
system preference? For example, what happens if the user sets "UK" for 
the "Region" in the preference, then the new code return "US" for the 
country?

Also, the array index "2" to assume the language length is 2 is not 
correct, as there are three letter language codes. So the code should 
literally look for "-" instead.

Naoto

From naoto.sato at oracle.com  Tue Jun 14 00:14:05 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 13 Jun 2016 17:14:05 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
Message-ID: <61cd19d5-53cc-b8c6-d4cd-eea45fc850ed@oracle.com>

On 13/06/2016 16:20, Brent Christian wrote:
> Hi, Naoto.  Thank you for having a look.
>
> On 13/06/2016 14:43, Naoto Sato wrote:
>> On 6/13/16 1:58 PM, Brent Christian wrote:
>>>
>>> The original Apple code then calls into
>>> "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
>>> "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though
>>> this appears to be unnecessary.  Following the call to
>>> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
>>> the language to a default country, per this comment:
>>>
>>>      * If the locale name (without .encoding at variant, if any) matches
>>>      * any of the names in the locale_aliases list, map it to the
>>>      * corresponding full locale name.  Most of the entries in the
>>>      * locale_aliases list are locales that include a language name but
>>>      * no country name, and this facility is used to map each language
>>>      * to a default country if that's possible.
>>>
>>> I tried out a few locales, for English (en_US, en_GB), German (de_DE,
>>> de_CH) and French (fr_FR, fr_CA).  Language/country system properties
>>> behave the same before and after this change, as does the
>>> java.util.Locale test attached to the bug.
>>
>> So does this mean the new code will not honor the "Region" in the OSX's
>> system preference? For example, what happens if the user sets "UK" for
>> the "Region" in the preference, then the new code return "US" for the
>> country?
>
> The new code has the same behavior as the existing code.
>
> OS X's Region preference is reflected as the locale's "format", through
> the "user.country.format" system property, and
> Locale.getDefault(Locale.FORMAT).
>
> The region is not reflected in the base "user.country" property or
> Locale.getDefault().  As the existing source comment indicates, the
> country is mapped to the default for the language, in this case, "US".
>
> It seemed a bit strange to me, too, but my testing indicates this has
> been the behavior since jdk 7u4.


I think that is a bug. It should adopt "UK" for the default/display 
locale too. Probably this should be addressed in a separate bug.

Naoto

From masayoshi.okutsu at oracle.com  Tue Jun 14 02:27:44 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 14 Jun 2016 11:27:44 +0900
Subject: <i18n dev> Review Request for JDK-8135061:
 java.util.Locale#lookup throws java.lang.StringIndexOutOfBoundsException
 for range having '-' as second character
In-Reply-To: <5e371ed5-7945-2586-3707-3d85d5987456@oracle.com>
References: <5e371ed5-7945-2586-3707-3d85d5987456@oracle.com>
Message-ID: <bb33dbe9-d3c1-31b7-decb-37854e8a274c@oracle.com>

Looks good to me.

Masayoshi

On 6/13/2016 6:54 PM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8135061
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8135061
> Webrev: http://cr.openjdk.java.net/~nishjain/8135061/webrev.01/
>
> Fix : Added a check on the lastIndexOf "-" before using substring for 
> truncating the extension key
>
> Regards,
> Nishit Jain
>


From yuka.kamiya at oracle.com  Tue Jun 14 03:28:33 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Tue, 14 Jun 2016 12:28:33 +0900
Subject: <i18n dev> Review Request for JDK-8135061:
 java.util.Locale#lookup throws java.lang.StringIndexOutOfBoundsException
 for range having '-' as second character
In-Reply-To: <bb33dbe9-d3c1-31b7-decb-37854e8a274c@oracle.com>
References: <5e371ed5-7945-2586-3707-3d85d5987456@oracle.com>
	<bb33dbe9-d3c1-31b7-decb-37854e8a274c@oracle.com>
Message-ID: <fd68cfcf-9841-98b5-5f08-e147e17f9daf@oracle.com>

+1

Thanks,
--
Yuka

On 2016/06/14 11:27, Masayoshi Okutsu wrote:
> Looks good to me.
>
> Masayoshi
>
> On 6/13/2016 6:54 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8135061
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135061
>> Webrev: http://cr.openjdk.java.net/~nishjain/8135061/webrev.01/
>>
>> Fix : Added a check on the lastIndexOf "-" before using substring for 
>> truncating the extension key
>>
>> Regards,
>> Nishit Jain
>>
>


From brent.christian at oracle.com  Mon Jun 13 20:58:23 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 13 Jun 2016 13:58:23 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
Message-ID: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>

Hi,

Please review this Mac-only fix:

http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-7131356

Thanks go to Gerard Ziemski for the thorough investigation and detailed 
write-up in the bug report.

The symptoms:

On those OS X machines where the default system Java is not installed, 
any attempt to instantiate JVM from a local JDK (for example via JNI as 
shown in the bug) presents "No Java installed. Do you want to install 
Java?" dialog and refuses to run. Clearly, a valid local JDK should be 
able to run in this case.

The problem:

In java_props_macosx.c, there is code that dynamically looks up 4 
methods in JavaRuntimeSupport.framework (JRS) and calls into them to 
find out localized OS version, default locale and the preferred 
language, but JRS checks for a system available Java and refuses to run 
if none found.

Background:

JavaRuntimeSupport.framework (JRS) is a framework implemented and 
provided by Apple for use by Java.  It is a "black box" that wraps SPIs 
required by the Apple-provided implementation of JDK, exposing them to 
the JDK as APIs.

Now that the JDK implementation ownership has changed from Apple to 
Oracle, we have the issue that we don't control the JRS implementation, 
but rely on Apple to support it for our JDK to continue to run. 
Depending on a private framework provided by a third party for our code 
to continue to run doesn't seem like a good long term bet (see also 
8024281).

Proposed solution:

Apple suggested changing the JDK initialization order so any access to 
JRS happens only after the JLI_MemAlloc symbol is available.  We believe 
a better solution is to re-implement the JSR APIs in question, as a move 
toward eventually dropping reliance on JSR altogether.  The three main 
changes are:

1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using 
"CFLocaleCopyPreferredLanguages", which gives us the preferred language 
as set in "System Preferences"->"Language & Text"->"Language" in the 
form of "xx" (ie. just the language code - ex. "en", "fr", etc.).  The 
original Apple code then calls into 
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into 
"language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though 
this appears to be unnecessary.  Following the call to 
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map 
the language to a default country, per this comment:

      * If the locale name (without .encoding at variant, if any) matches
      * any of the names in the locale_aliases list, map it to the
      * corresponding full locale name.  Most of the entries in the
      * locale_aliases list are locales that include a language name but
      * no country name, and this facility is used to map each language
      * to a default country if that's possible.

I tried out a few locales, for English (en_US, en_GB), German (de_DE, 
de_CH) and French (fr_FR, fr_CA).  Language/country system properties 
behave the same before and after this change, as does the 
java.util.Locale test attached to the bug.

2. In "setupMacOSXLocale" we simply drop the call to 
"JRSSetDefaultLocalization" as it appears to be a NOP. According to 
Apple, that API sets up native bundle locale, so that any access to 
native Cocoa UI (like FileOpenChooser) uses localized strings. Testing 
shows that this does not seem to work even in Apple's own JDK (ie. JDK 
6), so dropping the call to this SPI here does not result in a 
regression.  An issue was filed to investigate further (8024279, a dup 
of 8019464) which has since been closed as, "Not an Issue".

3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using 
[NSProcessInfo operatingSystemVersion].  (Use of JRSCopyOSName was 
already removed by 7178922).


Thanks,
-Brent

1. 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/79043a1c3547/src/java.base/unix/native/libjava/java_props_md.c


From brent.christian at oracle.com  Mon Jun 13 23:20:23 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 13 Jun 2016 16:20:23 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
Message-ID: <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>

Hi, Naoto.  Thank you for having a look.

On 13/06/2016 14:43, Naoto Sato wrote:
> On 6/13/16 1:58 PM, Brent Christian wrote:
>>
>> The original Apple code then calls into
>> "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
>> "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though
>> this appears to be unnecessary.  Following the call to
>> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
>> the language to a default country, per this comment:
>>
>>      * If the locale name (without .encoding at variant, if any) matches
>>      * any of the names in the locale_aliases list, map it to the
>>      * corresponding full locale name.  Most of the entries in the
>>      * locale_aliases list are locales that include a language name but
>>      * no country name, and this facility is used to map each language
>>      * to a default country if that's possible.
>>
>> I tried out a few locales, for English (en_US, en_GB), German (de_DE,
>> de_CH) and French (fr_FR, fr_CA).  Language/country system properties
>> behave the same before and after this change, as does the
>> java.util.Locale test attached to the bug.
>
> So does this mean the new code will not honor the "Region" in the OSX's
> system preference? For example, what happens if the user sets "UK" for
> the "Region" in the preference, then the new code return "US" for the
> country?

The new code has the same behavior as the existing code.

OS X's Region preference is reflected as the locale's "format", through 
the "user.country.format" system property, and 
Locale.getDefault(Locale.FORMAT).

The region is not reflected in the base "user.country" property or 
Locale.getDefault().  As the existing source comment indicates, the 
country is mapped to the default for the language, in this case, "US".

It seemed a bit strange to me, too, but my testing indicates this has 
been the behavior since jdk 7u4.

> Also, the array index "2" to assume the language length is 2 is not
> correct, as there are three letter language codes. So the code should
> literally look for "-" instead.

Great, thanks.  I will fix that.

-Brent

From astrange at apple.com  Mon Jun 13 23:51:26 2016
From: astrange at apple.com (Alex Strange)
Date: Mon, 13 Jun 2016 16:51:26 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
	requesting install" when creating VM from JNI [macosx]
In-Reply-To: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
Message-ID: <AD4C260B-F303-4EAA-A41C-579C2DCE2C77@apple.com>


> On Jun 13, 2016, at 1:58 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi,
> 
> Please review this Mac-only fix:
> 
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-7131356
> 
> Thanks go to Gerard Ziemski for the thorough investigation and detailed write-up in the bug report.
> 
> The symptoms:
> 
> On those OS X machines where the default system Java is not installed, any attempt to instantiate JVM from a local JDK (for example via JNI as shown in the bug) presents "No Java installed. Do you want to install Java?" dialog and refuses to run. Clearly, a valid local JDK should be able to run in this case.
> 
> The problem:
> 
> In java_props_macosx.c, there is code that dynamically looks up 4 methods in JavaRuntimeSupport.framework (JRS) and calls into them to find out localized OS version, default locale and the preferred language, but JRS checks for a system available Java and refuses to run if none found.
> 
> Background:
> 
> JavaRuntimeSupport.framework (JRS) is a framework implemented and provided by Apple for use by Java.  It is a "black box" that wraps SPIs required by the Apple-provided implementation of JDK, exposing them to the JDK as APIs.
> 
> Now that the JDK implementation ownership has changed from Apple to Oracle, we have the issue that we don't control the JRS implementation, but rely on Apple to support it for our JDK to continue to run. Depending on a private framework provided by a third party for our code to continue to run doesn't seem like a good long term bet (see also 8024281).
> 
> Proposed solution:
> 
> Apple suggested changing the JDK initialization order so any access to JRS happens only after the JLI_MemAlloc symbol is available.  We believe a better solution is to re-implement the JSR APIs in question, as a move toward eventually dropping reliance on JSR altogether.  The three main changes are:
> 
> 1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using "CFLocaleCopyPreferredLanguages", which gives us the preferred language as set in "System Preferences"->"Language & Text"->"Language" in the form of "xx" (ie. just the language code - ex. "en", "fr", etc.).  The original Apple code then calls into "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though this appears to be unnecessary.  Following the call to setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map the language to a default country, per this comment:
> 
>     * If the locale name (without .encoding at variant, if any) matches
>     * any of the names in the locale_aliases list, map it to the
>     * corresponding full locale name.  Most of the entries in the
>     * locale_aliases list are locales that include a language name but
>     * no country name, and this facility is used to map each language
>     * to a default country if that's possible.
> 
> I tried out a few locales, for English (en_US, en_GB), German (de_DE, de_CH) and French (fr_FR, fr_CA).  Language/country system properties behave the same before and after this change, as does the java.util.Locale test attached to the bug.

I think JRSCopyCanonicalLanguageForPrimaryLanguage() may be related to app bundles which don't have localizations in the user's language (for instance a Japanese-only app run on en_US). But I don't have an example of such an app or remember what the right behavior would be.

> 
> 2. In "setupMacOSXLocale" we simply drop the call to "JRSSetDefaultLocalization" as it appears to be a NOP. According to Apple, that API sets up native bundle locale, so that any access to native Cocoa UI (like FileOpenChooser) uses localized strings. Testing shows that this does not seem to work even in Apple's own JDK (ie. JDK 6), so dropping the call to this SPI here does not result in a regression.  An issue was filed to investigate further (8024279, a dup of 8019464) which has since been closed as, "Not an Issue".

This was added a very long time ago so that 'java -jar x.jar' would show properly localized menus in the menubar, instead of English menus, on a non-English system. It might no longer be a problem.

> 
> 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using [NSProcessInfo operatingSystemVersion].  (Use of JRSCopyOSName was already removed by 7178922).

You shouldn't need to use objc_msgSend_stret here. If you're not getting a warning when you use @selector in the line above, you should just be able to call -operationgSystemVersion directly inside the if.

If you are getting a warning, it'd be best to declare the selector yourself somewhere higher up:

typedef struct {
        NSInteger majorVersion;
        NSInteger minorVersion;
        NSInteger patchVersion;
} OSVerStruct;

@interface NSProcessInfo ()
- (OSVerStruct)operatingSystemVersion;
@end

> 
> 
> Thanks,
> -Brent
> 
> 1. http://hg.openjdk.java.net/jdk9/dev/jdk/file/79043a1c3547/src/java.base/unix/native/libjava/java_props_md.c
> 


From brent.christian at oracle.com  Tue Jun 14 16:35:21 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 14 Jun 2016 09:35:21 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
Message-ID: <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>

On 6/13/16 4:20 PM, Brent Christian wrote:
> On 13/06/2016 14:43, Naoto Sato wrote:
>>
>> Also, the array index "2" to assume the language length is 2 is not
>> correct, as there are three letter language codes. So the code should
>> literally look for "-" instead.
>
> Great, thanks.  I will fix that.

FYI, there will be a little more to this.  Some language IDs include a 
script ID: a four-character code separated from the main language 
designator by a '-'.  ("zh-Hans" for Simplified Chinese, for instance).
In this case, the '-' at index 2 should be left alone.  See [1].

-Brent

1. 
https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/LanguageandLocaleIDs/LanguageandLocaleIDs.html

From gerard.ziemski at oracle.com  Tue Jun 14 19:50:26 2016
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Tue, 14 Jun 2016 14:50:26 -0500
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
	requesting install" when creating VM from JNI [macosx]
In-Reply-To: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
Message-ID: <E5B52A05-C08B-4315-A16B-ECCD282B7080@oracle.com>

hi Brent,

Thank you very much for tackling this. The code overall looks good (aside from the 3 code language sub tag case that we need to handle, as Naoto pointed out)

Here are my 2 small comments:

#1

 63                 CFRelease(languages); // was missing from original patch

I think we can drop the comment from line 63?


#2

131 void setOSNameAndVersion(java_props_t *sprops) {
132     /* Don't rely on JRSCopyOSName because there's no guarantee the value will
133      * remain the same, or even if the JRS functions will continue to be part of
134      * Mac OS X.  So hardcode os_name, and fill in os_version if we can.
135      */

The comment from lines 132-135 should be dropped - we no longer use JSR - and just say that we're hardcoding the OS name?


cheers

> On Jun 13, 2016, at 3:58 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi,
> 
> Please review this Mac-only fix:
> 
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-7131356
> 
> Thanks go to Gerard Ziemski for the thorough investigation and detailed write-up in the bug report.
> 
> The symptoms:
> 
> On those OS X machines where the default system Java is not installed, any attempt to instantiate JVM from a local JDK (for example via JNI as shown in the bug) presents "No Java installed. Do you want to install Java?" dialog and refuses to run. Clearly, a valid local JDK should be able to run in this case.
> 
> The problem:
> 
> In java_props_macosx.c, there is code that dynamically looks up 4 methods in JavaRuntimeSupport.framework (JRS) and calls into them to find out localized OS version, default locale and the preferred language, but JRS checks for a system available Java and refuses to run if none found.
> 
> Background:
> 
> JavaRuntimeSupport.framework (JRS) is a framework implemented and provided by Apple for use by Java.  It is a "black box" that wraps SPIs required by the Apple-provided implementation of JDK, exposing them to the JDK as APIs.
> 
> Now that the JDK implementation ownership has changed from Apple to Oracle, we have the issue that we don't control the JRS implementation, but rely on Apple to support it for our JDK to continue to run. Depending on a private framework provided by a third party for our code to continue to run doesn't seem like a good long term bet (see also 8024281).
> 
> Proposed solution:
> 
> Apple suggested changing the JDK initialization order so any access to JRS happens only after the JLI_MemAlloc symbol is available.  We believe a better solution is to re-implement the JSR APIs in question, as a move toward eventually dropping reliance on JSR altogether.  The three main changes are:
> 
> 1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using "CFLocaleCopyPreferredLanguages", which gives us the preferred language as set in "System Preferences"->"Language & Text"->"Language" in the form of "xx" (ie. just the language code - ex. "en", "fr", etc.).  The original Apple code then calls into "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though this appears to be unnecessary.  Following the call to setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map the language to a default country, per this comment:
> 
>     * If the locale name (without .encoding at variant, if any) matches
>     * any of the names in the locale_aliases list, map it to the
>     * corresponding full locale name.  Most of the entries in the
>     * locale_aliases list are locales that include a language name but
>     * no country name, and this facility is used to map each language
>     * to a default country if that's possible.
> 
> I tried out a few locales, for English (en_US, en_GB), German (de_DE, de_CH) and French (fr_FR, fr_CA).  Language/country system properties behave the same before and after this change, as does the java.util.Locale test attached to the bug.
> 
> 2. In "setupMacOSXLocale" we simply drop the call to "JRSSetDefaultLocalization" as it appears to be a NOP. According to Apple, that API sets up native bundle locale, so that any access to native Cocoa UI (like FileOpenChooser) uses localized strings. Testing shows that this does not seem to work even in Apple's own JDK (ie. JDK 6), so dropping the call to this SPI here does not result in a regression.  An issue was filed to investigate further (8024279, a dup of 8019464) which has since been closed as, "Not an Issue".
> 
> 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using [NSProcessInfo operatingSystemVersion].  (Use of JRSCopyOSName was already removed by 7178922).
> 
> 
> Thanks,
> -Brent
> 
> 1. http://hg.openjdk.java.net/jdk9/dev/jdk/file/79043a1c3547/src/java.base/unix/native/libjava/java_props_md.c
> 


From masayoshi.okutsu at oracle.com  Fri Jun 17 08:14:38 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 17 Jun 2016 17:14:38 +0900
Subject: <i18n dev> RFR: 8158272 & 8158468
 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
In-Reply-To: <34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
Message-ID: <e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>

I've been waiting for JDK-8159206 to be fixed. But this test still fails 
after the JDK-8159206 fix. I've filed JDK-8159781 for the failure and 
pushed this test fix with the following ProblemList.txt change:

diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -387,7 +387,7 @@
  
  # core_tools
  
-tools/jlink/plugins/IncludeLocalesPluginTest.java               8158272 generic-all
+tools/jlink/plugins/IncludeLocalesPluginTest.java               8159781 generic-all
  
  tools/jlink/JLinkOptimTest.java                                 8159264 generic-all
  

This test passes with b122  which has the CLDR upgrade.

Masayoshi

On 6/14/2016 5:18 AM, Alan Bateman wrote:
> On 13/06/2016 16:02, Mandy Chung wrote:
>
>>
>> I see.  I?m fine with what you have.  We should enhance the jlink 
>> testlibrary to run java from a run-time image created for a test to run.
>>
> I'm okay with it too.
>
> -Alan


From nishit.jain at oracle.com  Fri Jun 17 08:16:05 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 17 Jun 2016 13:46:05 +0530
Subject: <i18n dev> Review Request for JDK-8159420 : The
 LanguageRange.parse() method is throwing IllegalArgumentException in
 Turkish Locale
Message-ID: <095c8c4f-1700-1197-709b-c185e99a3691@oracle.com>

Hi,

Please review the fix for JDK-8159420

Bug: https://bugs.openjdk.java.net/browse/JDK-8159420
Webrev: http://cr.openjdk.java.net/~nishjain/8159420/webrev.04/

Fix: Changed the toLowerCase() method on language-ranges and 
language-tags to toLowerCase(Locale.ROOT) because characters in language 
range and language tag must always be "a-z" "0-9" or '-'

Regards,
Nishit Jain

From masayoshi.okutsu at oracle.com  Fri Jun 17 08:40:35 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 17 Jun 2016 17:40:35 +0900
Subject: <i18n dev> Review Request for JDK-8159420 : The
 LanguageRange.parse() method is throwing IllegalArgumentException in
 Turkish Locale
In-Reply-To: <095c8c4f-1700-1197-709b-c185e99a3691@oracle.com>
References: <095c8c4f-1700-1197-709b-c185e99a3691@oracle.com>
Message-ID: <d52e6bbb-7a99-e8d7-3ab2-2847cd1ff93a@oracle.com>

Looks good.

Thanks,
Masayoshi

On 6/17/2016 5:16 PM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8159420
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8159420
> Webrev: http://cr.openjdk.java.net/~nishjain/8159420/webrev.04/
>
> Fix: Changed the toLowerCase() method on language-ranges and 
> language-tags to toLowerCase(Locale.ROOT) because characters in 
> language range and language tag must always be "a-z" "0-9" or '-'
>
> Regards,
> Nishit Jain


From yuka.kamiya at oracle.com  Fri Jun 17 11:38:04 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 17 Jun 2016 20:38:04 +0900
Subject: <i18n dev> Review Request for JDK-8159420 : The
 LanguageRange.parse() method is throwing IllegalArgumentException in
 Turkish Locale
In-Reply-To: <d52e6bbb-7a99-e8d7-3ab2-2847cd1ff93a@oracle.com>
References: <095c8c4f-1700-1197-709b-c185e99a3691@oracle.com>
	<d52e6bbb-7a99-e8d7-3ab2-2847cd1ff93a@oracle.com>
Message-ID: <41b196a4-0b90-c0bf-223b-5d744a71d9c3@oracle.com>

+1

On 2016/06/17 17:40, Masayoshi Okutsu wrote:
> Looks good.
>
> Thanks,
> Masayoshi
>
> On 6/17/2016 5:16 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8159420
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159420
>> Webrev: http://cr.openjdk.java.net/~nishjain/8159420/webrev.04/
>>
>> Fix: Changed the toLowerCase() method on language-ranges and 
>> language-tags to toLowerCase(Locale.ROOT) because characters in 
>> language range and language tag must always be "a-z" "0-9" or '-'
>>
>> Regards,
>> Nishit Jain
>


From naoto.sato at oracle.com  Fri Jun 17 16:09:15 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 17 Jun 2016 09:09:15 -0700
Subject: <i18n dev> RFR: 8158272 & 8158468
 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)
In-Reply-To: <e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
Message-ID: <a500fa2d-906a-2416-9395-568d6346d422@oracle.com>

I will take care of that along with other include locales issues.

Naoto

On 17/06/2016 01:14, Masayoshi Okutsu wrote:
> I've been waiting for JDK-8159206 to be fixed. But this test still fails
> after the JDK-8159206 fix. I've filed JDK-8159781 for the failure and
> pushed this test fix with the following ProblemList.txt change:
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -387,7 +387,7 @@
>
>  # core_tools
>
> -tools/jlink/plugins/IncludeLocalesPluginTest.java               8158272
> generic-all
> +tools/jlink/plugins/IncludeLocalesPluginTest.java               8159781
> generic-all
>
>  tools/jlink/JLinkOptimTest.java                                 8159264
> generic-all
>
>
> This test passes with b122  which has the CLDR upgrade.
>
> Masayoshi
>
> On 6/14/2016 5:18 AM, Alan Bateman wrote:
>> On 13/06/2016 16:02, Mandy Chung wrote:
>>
>>>
>>> I see.  I?m fine with what you have.  We should enhance the jlink
>>> testlibrary to run java from a run-time image created for a test to run.
>>>
>> I'm okay with it too.
>>
>> -Alan
>

From naoto.sato at oracle.com  Fri Jun 17 16:23:42 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 17 Jun 2016 09:23:42 -0700
Subject: <i18n dev> Review Request for JDK-8159420 : The
 LanguageRange.parse() method is throwing IllegalArgumentException in
 Turkish Locale
In-Reply-To: <095c8c4f-1700-1197-709b-c185e99a3691@oracle.com>
References: <095c8c4f-1700-1197-709b-c185e99a3691@oracle.com>
Message-ID: <d2ab70d8-1dac-2a93-a621-b88b41a5d622@oracle.com>

Looks good to me.

Naoto

On 17/06/2016 01:16, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8159420
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8159420
> Webrev: http://cr.openjdk.java.net/~nishjain/8159420/webrev.04/
>
> Fix: Changed the toLowerCase() method on language-ranges and
> language-tags to toLowerCase(Locale.ROOT) because characters in language
> range and language tag must always be "a-z" "0-9" or '-'
>
> Regards,
> Nishit Jain

From naoto.sato at oracle.com  Fri Jun 17 22:29:21 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 17 Jun 2016 15:29:21 -0700
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
 java.util.regex.PatternSyntaxException
In-Reply-To: <a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
Message-ID: <3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>

Decided to fix this separately from the other include locales issues. 
Here is the bug and the proposed fix:

https://bugs.openjdk.java.net/browse/JDK-8159781
http://cr.openjdk.java.net/~naoto/8159781/webrev.00/

The change is to explicitly specify "regex" path matching along with the 
pattern modifications. This is needed to cope with the fix to 8158402.

Please review.

Naoto

On 17/06/2016 09:09, Naoto Sato wrote:
> I will take care of that along with other include locales issues.
>
> Naoto
>
> On 17/06/2016 01:14, Masayoshi Okutsu wrote:
>> I've been waiting for JDK-8159206 to be fixed. But this test still fails
>> after the JDK-8159206 fix. I've filed JDK-8159781 for the failure and
>> pushed this test fix with the following ProblemList.txt change:
>>
>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
>> --- a/test/ProblemList.txt
>> +++ b/test/ProblemList.txt
>> @@ -387,7 +387,7 @@
>>
>>  # core_tools
>>
>> -tools/jlink/plugins/IncludeLocalesPluginTest.java               8158272
>> generic-all
>> +tools/jlink/plugins/IncludeLocalesPluginTest.java               8159781
>> generic-all
>>
>>  tools/jlink/JLinkOptimTest.java                                 8159264
>> generic-all
>>
>>
>> This test passes with b122  which has the CLDR upgrade.
>>
>> Masayoshi
>>
>> On 6/14/2016 5:18 AM, Alan Bateman wrote:
>>> On 13/06/2016 16:02, Mandy Chung wrote:
>>>
>>>>
>>>> I see.  I?m fine with what you have.  We should enhance the jlink
>>>> testlibrary to run java from a run-time image created for a test to
>>>> run.
>>>>
>>> I'm okay with it too.
>>>
>>> -Alan
>>

From mandy.chung at oracle.com  Fri Jun 17 22:50:33 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 17 Jun 2016 15:50:33 -0700
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
	java.util.regex.PatternSyntaxException
In-Reply-To: <3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
Message-ID: <5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>


> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Decided to fix this separately from the other include locales issues. Here is the bug and the proposed fix:
> 
> https://bugs.openjdk.java.net/browse/JDK-8159781
> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/

The change looks okay.   This can be converted to use ResourceFilter::includeFilter(List<String> patterns) rather than building a comma-separated patterns string.  That means META_FILES and INCLUDE_LOCALE_FILES can be made as List<String>.  You have an option to prepend ?regex:? when constructing the patterns to pass to ResourceFilter.  I think that?s a good clean up to do.

Mandy

From naoto.sato at oracle.com  Mon Jun 20 15:18:41 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 20 Jun 2016 08:18:41 -0700
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
 java.util.regex.PatternSyntaxException
In-Reply-To: <5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
	<5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
Message-ID: <860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>

Hi Mandy, thank you for the review.

INCLUDE_LOCALE_FILES is actually a pattern template, and the real filter 
patterns are constructed at the runtime with the passed argument, by 
replacing "%%" with locale patterns. So I think it is less complex to 
handle it as the current way.

I will modify the "regex:" prepending as you suggested.

Naoto

On 6/17/16 3:50 PM, Mandy Chung wrote:
>
>> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> Decided to fix this separately from the other include locales issues. Here is the bug and the proposed fix:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8159781
>> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/
>
> The change looks okay.   This can be converted to use ResourceFilter::includeFilter(List<String> patterns) rather than building a comma-separated patterns string.  That means META_FILES and INCLUDE_LOCALE_FILES can be made as List<String>.  You have an option to prepend ?regex:? when constructing the patterns to pass to ResourceFilter.  I think that?s a good clean up to do.
>
> Mandy
>

From brent.christian at oracle.com  Mon Jun 20 21:34:49 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 20 Jun 2016 14:34:49 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <61cd19d5-53cc-b8c6-d4cd-eea45fc850ed@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<61cd19d5-53cc-b8c6-d4cd-eea45fc850ed@oracle.com>
Message-ID: <bc09bd8f-3ecd-634a-61a6-81a1ec1c2ea2@oracle.com>

On 6/13/16 5:14 PM, Naoto Sato wrote:
> On 13/06/2016 16:20, Brent Christian wrote:
>>>>
>>>> Following the call to
>>>> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
>>>> the language to a default country
>>>
>>> So does this mean the new code will not honor the "Region" in the OSX's
>>> system preference? For example, what happens if the user sets "UK" for
>>> the "Region" in the preference, then the new code return "US" for the
>>> country?
>>
>> OS X's Region preference is reflected as the locale's "format", through
>> the "user.country.format" system property, and
>> Locale.getDefault(Locale.FORMAT).
>>
>> The region is not reflected in the base "user.country" property or
>> Locale.getDefault().  As the existing source comment indicates, the
>> country is mapped to the default for the language, in this case, "US".
>>
>> It seemed a bit strange to me, too, but my testing indicates this has
>> been the behavior since jdk 7u4.
>
> I think that is a bug. It should adopt "UK" for the default/display
> locale too. Probably this should be addressed in a separate bug.

After some more investigation, I don't believe there is a bug here.

The behavior I saw happened when using the basic 
"English"/"French"/"German" languages, and changing the country with Region.

OS X also provides regional options for the language itself (e.g. 
"British English", "Canadian French", "Swiss German", etc) in Preferred 
languages.  When using these languages, defaults are as expected (e.g. 
reflected in "user.country") without remapping with mapLookup().

Thanks,
-Brent

From naoto.sato at oracle.com  Mon Jun 20 21:56:18 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 20 Jun 2016 14:56:18 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <bc09bd8f-3ecd-634a-61a6-81a1ec1c2ea2@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<61cd19d5-53cc-b8c6-d4cd-eea45fc850ed@oracle.com>
	<bc09bd8f-3ecd-634a-61a6-81a1ec1c2ea2@oracle.com>
Message-ID: <c12053c0-69cc-9c9b-2efa-2a71ddee7415@oracle.com>

Good! Wasn't aware there is "British English" in the language selection. 
Looks like all is working as expected.

Naoto

On 6/20/16 2:34 PM, Brent Christian wrote:
> On 6/13/16 5:14 PM, Naoto Sato wrote:
>> On 13/06/2016 16:20, Brent Christian wrote:
>>>>>
>>>>> Following the call to
>>>>> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
>>>>> the language to a default country
>>>>
>>>> So does this mean the new code will not honor the "Region" in the OSX's
>>>> system preference? For example, what happens if the user sets "UK" for
>>>> the "Region" in the preference, then the new code return "US" for the
>>>> country?
>>>
>>> OS X's Region preference is reflected as the locale's "format", through
>>> the "user.country.format" system property, and
>>> Locale.getDefault(Locale.FORMAT).
>>>
>>> The region is not reflected in the base "user.country" property or
>>> Locale.getDefault().  As the existing source comment indicates, the
>>> country is mapped to the default for the language, in this case, "US".
>>>
>>> It seemed a bit strange to me, too, but my testing indicates this has
>>> been the behavior since jdk 7u4.
>>
>> I think that is a bug. It should adopt "UK" for the default/display
>> locale too. Probably this should be addressed in a separate bug.
>
> After some more investigation, I don't believe there is a bug here.
>
> The behavior I saw happened when using the basic
> "English"/"French"/"German" languages, and changing the country with
> Region.
>
> OS X also provides regional options for the language itself (e.g.
> "British English", "Canadian French", "Swiss German", etc) in Preferred
> languages.  When using these languages, defaults are as expected (e.g.
> reflected in "user.country") without remapping with mapLookup().
>
> Thanks,
> -Brent

From naoto.sato at oracle.com  Mon Jun 20 22:00:30 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 20 Jun 2016 15:00:30 -0700
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
 java.util.regex.PatternSyntaxException
In-Reply-To: <860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
	<5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
	<860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>
Message-ID: <2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>

Here is the updated webrev:

http://cr.openjdk.java.net/~naoto/8159781/webrev.01/

Naoto

On 6/20/16 8:18 AM, Naoto Sato wrote:
> Hi Mandy, thank you for the review.
>
> INCLUDE_LOCALE_FILES is actually a pattern template, and the real filter
> patterns are constructed at the runtime with the passed argument, by
> replacing "%%" with locale patterns. So I think it is less complex to
> handle it as the current way.
>
> I will modify the "regex:" prepending as you suggested.
>
> Naoto
>
> On 6/17/16 3:50 PM, Mandy Chung wrote:
>>
>>> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>
>>> Decided to fix this separately from the other include locales issues.
>>> Here is the bug and the proposed fix:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8159781
>>> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/
>>
>> The change looks okay.   This can be converted to use
>> ResourceFilter::includeFilter(List<String> patterns) rather than
>> building a comma-separated patterns string.  That means META_FILES and
>> INCLUDE_LOCALE_FILES can be made as List<String>.  You have an option
>> to prepend ?regex:? when constructing the patterns to pass to
>> ResourceFilter.  I think that?s a good clean up to do.
>>
>> Mandy
>>

From brent.christian at oracle.com  Mon Jun 20 22:44:32 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 20 Jun 2016 15:44:32 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <AD4C260B-F303-4EAA-A41C-579C2DCE2C77@apple.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<AD4C260B-F303-4EAA-A41C-579C2DCE2C77@apple.com>
Message-ID: <5462a432-6ae9-cf89-f2eb-0324c70ac80e@oracle.com>


Alex - thanks for your response.  More below...

On 6/13/16 4:51 PM, Alex Strange wrote:
>> 2. In "setupMacOSXLocale" we simply drop the call to
>> "JRSSetDefaultLocalization" as it appears to be a NOP. According to
>> Apple, that API sets up native bundle locale, so that any access to
>> native Cocoa UI (like FileOpenChooser) uses localized strings.
>> Testing shows that this does not seem to work even in Apple's own
>> JDK (ie. JDK 6), so dropping the call to this SPI here does not
>> result in a regression.  An issue was filed to investigate further
>> (8024279, a dup of 8019464) which has since been closed as, "Not an
>> Issue".
>
> This was added a very long time ago so that 'java -jar x.jar' would
> show properly localized menus in the menubar, instead of English
> menus, on a non-English system. It might no longer be a problem.

OK, thanks.

'java -jar x.jar' behavior is unchanged with this patch.  (From the bug 
report, it hasn't worked since JDK 7).

>> 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using
>> [NSProcessInfo operatingSystemVersion].  (Use of JRSCopyOSName was
>> already removed by 7178922).
>
> You shouldn't need to use objc_msgSend_stret here. If you're not
> getting a warning when you use @selector in the line above, you
> should just be able to call -operationgSystemVersion directly inside
> the if.
>
> If you are getting a warning, it'd be best to declare the selector
> yourself somewhere higher up:
>
> typedef struct {
>         NSInteger majorVersion;
>         NSInteger minorVersion;
>         NSInteger patchVersion;
> } OSVerStruct;
>
> @interface NSProcessInfo ()
> - (OSVerStruct)operatingSystemVersion;
> @end

Thanks - this works for building w/ the 10.9 SDK (the officially 
supported Mac SDK for building JDK).

But I believe people also build w/ the 10.10 SDK (I've not tried it 
myself).  Won't this cause problems, since NSProcessInfo already has 
"operatingSystemVersion", and it returns an NSOperatingSystemVersion, 
not an OSVerStruct ?

I'd prefer something that can build on SDK 10.9 and 10.10, etc.  Once 
the official build moves to 10.10/later, objc_msgSend() can be removed 
and we can use [NSProcessInfo operatingSystemVersion] directly.

Thanks,
-Brent

From brent.christian at oracle.com  Mon Jun 20 23:38:57 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 20 Jun 2016 16:38:57 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
Message-ID: <d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>

Hi,

I have an updated webrev at:
http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/

The comments have been updated as Gerard suggested.

The code to process the languageString now accounts for 3-character 
language codes, and 4-char script designations (line 86).

More extensive testing of languages with multiple scripts/regions
revealed that more changes were needed to maintain current behavior. 
Without knowing the internal workings of how
JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I 
believe the best options are to add a few more mappings as needed to 
locale_aliases (locale_str.h), and to add a special case for Portuguese 
(line 104).

OS X has 3 language options for Portuguese:
Portugues (Portugal)
Portugues (Brasil)
Portugues (Brasileiro)

CFLocaleCopyPreferredLanguages() gives the expected language code for
Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't 
include a region code (it's simply, "pt"), so gets mapped to the default 
country, Portugal.  To maintain current behavior, I added a special case 
to map "pt" to "pt_BR" when the Region system preference is set to Brazil.


This change introduces one notable behavior change, which I argue is 
actually a fix.  The bug report and test case do not list the "Spanish 
(Mexico)" language, but it is present on MaxOS 10.9 (presumably it was 
added to the OS since the original investigation).  The old code mapped 
this to "es_XL", XL being one of the "user-assigned" ISO 3166 country 
codes.  The new code maps to "es_MX", MX being the country code for Mexico.


I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried 
every language that includes multiple scripts/locales.  I also added a 
couple updated tests to the bug report.

General testing has looked good so far.

Thanks,
-Brent

From masayoshi.okutsu at oracle.com  Tue Jun 21 02:53:07 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 21 Jun 2016 11:53:07 +0900
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
 java.util.regex.PatternSyntaxException
In-Reply-To: <2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
	<5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
	<860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>
	<2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>
Message-ID: <1585534f-0021-137a-392f-0a748722d9f3@oracle.com>

If the long pattern string is avoided, it'll be unnecessary to use "%%" 
and replaceAll? I'm also concerned to keep concatenating strings to 
produce a long string (rather than using a StringBuilder). Would that be 
the reason to put -verbose:gc in the test program? Use of List<String> 
will simplify the processing as Mandy suggests.

Masayoshi


On 6/21/2016 7:00 AM, Naoto Sato wrote:
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8159781/webrev.01/
>
> Naoto
>
> On 6/20/16 8:18 AM, Naoto Sato wrote:
>> Hi Mandy, thank you for the review.
>>
>> INCLUDE_LOCALE_FILES is actually a pattern template, and the real filter
>> patterns are constructed at the runtime with the passed argument, by
>> replacing "%%" with locale patterns. So I think it is less complex to
>> handle it as the current way.
>>
>> I will modify the "regex:" prepending as you suggested.
>>
>> Naoto
>>
>> On 6/17/16 3:50 PM, Mandy Chung wrote:
>>>
>>>> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>>
>>>> Decided to fix this separately from the other include locales issues.
>>>> Here is the bug and the proposed fix:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8159781
>>>> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/
>>>
>>> The change looks okay.   This can be converted to use
>>> ResourceFilter::includeFilter(List<String> patterns) rather than
>>> building a comma-separated patterns string.  That means META_FILES and
>>> INCLUDE_LOCALE_FILES can be made as List<String>.  You have an option
>>> to prepend ?regex:? when constructing the patterns to pass to
>>> ResourceFilter.  I think that?s a good clean up to do.
>>>
>>> Mandy
>>>


From mandy.chung at oracle.com  Tue Jun 21 04:23:42 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 20 Jun 2016 21:23:42 -0700
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
	java.util.regex.PatternSyntaxException
In-Reply-To: <2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
	<5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
	<860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>
	<2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>
Message-ID: <8CBFF3EC-478B-490A-A4F3-74E886CFC4A6@oracle.com>

Looks okay.
Mandy

> On Jun 20, 2016, at 3:00 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Here is the updated webrev:
> 
> http://cr.openjdk.java.net/~naoto/8159781/webrev.01/
> 
> Naoto
> 
> On 6/20/16 8:18 AM, Naoto Sato wrote:
>> Hi Mandy, thank you for the review.
>> 
>> INCLUDE_LOCALE_FILES is actually a pattern template, and the real filter
>> patterns are constructed at the runtime with the passed argument, by
>> replacing "%%" with locale patterns. So I think it is less complex to
>> handle it as the current way.
>> 
>> I will modify the "regex:" prepending as you suggested.
>> 
>> Naoto
>> 
>> On 6/17/16 3:50 PM, Mandy Chung wrote:
>>> 
>>>> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>> 
>>>> Decided to fix this separately from the other include locales issues.
>>>> Here is the bug and the proposed fix:
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8159781
>>>> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/
>>> 
>>> The change looks okay.   This can be converted to use
>>> ResourceFilter::includeFilter(List<String> patterns) rather than
>>> building a comma-separated patterns string.  That means META_FILES and
>>> INCLUDE_LOCALE_FILES can be made as List<String>.  You have an option
>>> to prepend ?regex:? when constructing the patterns to pass to
>>> ResourceFilter.  I think that?s a good clean up to do.
>>> 
>>> Mandy
>>> 


From masayoshi.okutsu at oracle.com  Tue Jun 21 06:34:07 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 21 Jun 2016 15:34:07 +0900
Subject: <i18n dev> RFR: 8159766: "Switching encoding from UTF-8 to
 ISO-8859-1" log message should be trace/debug message
Message-ID: <ddfe3393-faaf-9b79-f2c2-c3cf9d8368bf@oracle.com>

Hi,

Please review the fix for JDK-8159766. The logging code has been removed 
after all. No additional regression test. The message should no longer 
be logged to the .jtr file with 
java/util/ResourceBundle/UTF8Properties/CodePointTest.java.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8159766
Wevrev:
http://cr.openjdk.java.net/~okutsu/9/8159766/webrev.00

Thanks,
Masayoshi


From Alan.Bateman at oracle.com  Tue Jun 21 07:39:21 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Jun 2016 08:39:21 +0100
Subject: <i18n dev> RFR: 8159766: "Switching encoding from UTF-8 to
 ISO-8859-1" log message should be trace/debug message
In-Reply-To: <ddfe3393-faaf-9b79-f2c2-c3cf9d8368bf@oracle.com>
References: <ddfe3393-faaf-9b79-f2c2-c3cf9d8368bf@oracle.com>
Message-ID: <47a516f2-9dde-9ce8-727d-00c810cca491@oracle.com>

On 21/06/2016 07:34, Masayoshi Okutsu wrote:

> Hi,
>
> Please review the fix for JDK-8159766. The logging code has been 
> removed after all. No additional regression test. The message should 
> no longer be logged to the .jtr file with 
> java/util/ResourceBundle/UTF8Properties/CodePointTest.java.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8159766
> Wevrev:
> http://cr.openjdk.java.net/~okutsu/9/8159766/webrev.00
This looks okay to me.

-Alan

From mandy.chung at oracle.com  Tue Jun 21 13:33:59 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 21 Jun 2016 06:33:59 -0700
Subject: <i18n dev> RFR: 8159766: "Switching encoding from UTF-8 to
	ISO-8859-1" log message should be trace/debug message
In-Reply-To: <ddfe3393-faaf-9b79-f2c2-c3cf9d8368bf@oracle.com>
References: <ddfe3393-faaf-9b79-f2c2-c3cf9d8368bf@oracle.com>
Message-ID: <E21B0ACC-23BA-4801-8D9B-61B6F255B232@oracle.com>


> On Jun 20, 2016, at 11:34 PM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
> 
> Hi,
> 
> Please review the fix for JDK-8159766. The logging code has been removed after all. No additional regression test. The message should no longer be logged to the .jtr file with java/util/ResourceBundle/UTF8Properties/CodePointTest.java.
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8159766
> Wevrev:
> http://cr.openjdk.java.net/~okutsu/9/8159766/webrev.00


+1

Mandy

From naoto.sato at oracle.com  Tue Jun 21 15:55:58 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Jun 2016 08:55:58 -0700
Subject: <i18n dev> RFR: 8159766: "Switching encoding from UTF-8 to
 ISO-8859-1" log message should be trace/debug message
In-Reply-To: <ddfe3393-faaf-9b79-f2c2-c3cf9d8368bf@oracle.com>
References: <ddfe3393-faaf-9b79-f2c2-c3cf9d8368bf@oracle.com>
Message-ID: <23636b49-d3da-03d9-db13-7f9719b39f91@oracle.com>

Looks good.

Naoto

On 6/20/16 11:34 PM, Masayoshi Okutsu wrote:
> Hi,
>
> Please review the fix for JDK-8159766. The logging code has been removed
> after all. No additional regression test. The message should no longer
> be logged to the .jtr file with
> java/util/ResourceBundle/UTF8Properties/CodePointTest.java.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8159766
> Wevrev:
> http://cr.openjdk.java.net/~okutsu/9/8159766/webrev.00
>
> Thanks,
> Masayoshi
>

From naoto.sato at oracle.com  Tue Jun 21 20:51:44 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Jun 2016 13:51:44 -0700
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
 java.util.regex.PatternSyntaxException
In-Reply-To: <1585534f-0021-137a-392f-0a748722d9f3@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
	<5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
	<860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>
	<2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>
	<1585534f-0021-137a-392f-0a748722d9f3@oracle.com>
Message-ID: <475280c0-59e7-eec3-0702-5f554f2e1da3@oracle.com>

Thank you for the review, Masayoshi.

I don't think that "-verbose:gc" has anything to do with the long 
pattern string (the option had been there before I wrote the locale 
plugin), but I see your point here. I modified the fix according to your 
suggestion:

http://cr.openjdk.java.net/~naoto/8159781/webrev.02/

Naoto

On 6/20/16 7:53 PM, Masayoshi Okutsu wrote:
> If the long pattern string is avoided, it'll be unnecessary to use "%%"
> and replaceAll? I'm also concerned to keep concatenating strings to
> produce a long string (rather than using a StringBuilder). Would that be
> the reason to put -verbose:gc in the test program? Use of List<String>
> will simplify the processing as Mandy suggests.
>
> Masayoshi
>
>
> On 6/21/2016 7:00 AM, Naoto Sato wrote:
>> Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8159781/webrev.01/
>>
>> Naoto
>>
>> On 6/20/16 8:18 AM, Naoto Sato wrote:
>>> Hi Mandy, thank you for the review.
>>>
>>> INCLUDE_LOCALE_FILES is actually a pattern template, and the real filter
>>> patterns are constructed at the runtime with the passed argument, by
>>> replacing "%%" with locale patterns. So I think it is less complex to
>>> handle it as the current way.
>>>
>>> I will modify the "regex:" prepending as you suggested.
>>>
>>> Naoto
>>>
>>> On 6/17/16 3:50 PM, Mandy Chung wrote:
>>>>
>>>>> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>>>
>>>>> Decided to fix this separately from the other include locales issues.
>>>>> Here is the bug and the proposed fix:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8159781
>>>>> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/
>>>>
>>>> The change looks okay.   This can be converted to use
>>>> ResourceFilter::includeFilter(List<String> patterns) rather than
>>>> building a comma-separated patterns string.  That means META_FILES and
>>>> INCLUDE_LOCALE_FILES can be made as List<String>.  You have an option
>>>> to prepend ?regex:? when constructing the patterns to pass to
>>>> ResourceFilter.  I think that?s a good clean up to do.
>>>>
>>>> Mandy
>>>>
>

From naoto.sato at oracle.com  Tue Jun 21 21:48:24 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Jun 2016 14:48:24 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
Message-ID: <e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>

Hi Brent,

I looked at the system preference setting panel and noticed there is 
"Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as 
the designate region. Can you make changes to deal with it? (sorry I 
should have noticed this earlier, and it's unfortunate not to be able to 
upcall Locale.forLanguageTag()!)

Naoto

On 6/20/16 4:38 PM, Brent Christian wrote:
> Hi,
>
> I have an updated webrev at:
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>
> The comments have been updated as Gerard suggested.
>
> The code to process the languageString now accounts for 3-character
> language codes, and 4-char script designations (line 86).
>
> More extensive testing of languages with multiple scripts/regions
> revealed that more changes were needed to maintain current behavior.
> Without knowing the internal workings of how
> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I
> believe the best options are to add a few more mappings as needed to
> locale_aliases (locale_str.h), and to add a special case for Portuguese
> (line 104).
>
> OS X has 3 language options for Portuguese:
> Portugues (Portugal)
> Portugues (Brasil)
> Portugues (Brasileiro)
>
> CFLocaleCopyPreferredLanguages() gives the expected language code for
> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
> include a region code (it's simply, "pt"), so gets mapped to the default
> country, Portugal.  To maintain current behavior, I added a special case
> to map "pt" to "pt_BR" when the Region system preference is set to Brazil.
>
>
> This change introduces one notable behavior change, which I argue is
> actually a fix.  The bug report and test case do not list the "Spanish
> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was
> added to the OS since the original investigation).  The old code mapped
> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country
> codes.  The new code maps to "es_MX", MX being the country code for Mexico.
>
>
> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried
> every language that includes multiple scripts/locales.  I also added a
> couple updated tests to the bug report.
>
> General testing has looked good so far.
>
> Thanks,
> -Brent

From brent.christian at oracle.com  Tue Jun 21 22:17:10 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 21 Jun 2016 15:17:10 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
Message-ID: <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>

Hi, Naoto

"Spanish (Latin America)" already works the same as it did before the 
change - it maps to "es_XL".  Because "es-419" has more than 2 
characters following the '-', no change is made and 
getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping for 
"es-419" -> "es_XL" in locale_str.h.

System property values are (still) set to:
   user.language: es
   user.country: XL
   user.country.format: (2-char country code for the selected Region)

Thanks,
-Brent

On 21/06/16 14:48, Naoto Sato wrote:
> Hi Brent,
>
> I looked at the system preference setting panel and noticed there is
> "Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as
> the designate region. Can you make changes to deal with it? (sorry I
> should have noticed this earlier, and it's unfortunate not to be able to
> upcall Locale.forLanguageTag()!)
>
> Naoto
>
> On 6/20/16 4:38 PM, Brent Christian wrote:
>> Hi,
>>
>> I have an updated webrev at:
>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>
>> The comments have been updated as Gerard suggested.
>>
>> The code to process the languageString now accounts for 3-character
>> language codes, and 4-char script designations (line 86).
>>
>> More extensive testing of languages with multiple scripts/regions
>> revealed that more changes were needed to maintain current behavior.
>> Without knowing the internal workings of how
>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I
>> believe the best options are to add a few more mappings as needed to
>> locale_aliases (locale_str.h), and to add a special case for Portuguese
>> (line 104).
>>
>> OS X has 3 language options for Portuguese:
>> Portugues (Portugal)
>> Portugues (Brasil)
>> Portugues (Brasileiro)
>>
>> CFLocaleCopyPreferredLanguages() gives the expected language code for
>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
>> include a region code (it's simply, "pt"), so gets mapped to the default
>> country, Portugal.  To maintain current behavior, I added a special case
>> to map "pt" to "pt_BR" when the Region system preference is set to
>> Brazil.
>>
>>
>> This change introduces one notable behavior change, which I argue is
>> actually a fix.  The bug report and test case do not list the "Spanish
>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was
>> added to the OS since the original investigation).  The old code mapped
>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country
>> codes.  The new code maps to "es_MX", MX being the country code for
>> Mexico.
>>
>>
>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried
>> every language that includes multiple scripts/locales.  I also added a
>> couple updated tests to the bug report.
>>
>> General testing has looked good so far.
>>
>> Thanks,
>> -Brent

From naoto.sato at oracle.com  Tue Jun 21 22:27:36 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Jun 2016 15:27:36 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
Message-ID: <f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>

Actually, j.u.Locale class' "country" code is defined as ISO-3166 
alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying 
setting is "es-419" for the preferred language, "user.country" should be 
"419".

Naoto

On 6/21/16 3:17 PM, Brent Christian wrote:
> Hi, Naoto
>
> "Spanish (Latin America)" already works the same as it did before the
> change - it maps to "es_XL".  Because "es-419" has more than 2
> characters following the '-', no change is made and
> getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping for
> "es-419" -> "es_XL" in locale_str.h.
>
> System property values are (still) set to:
>   user.language: es
>   user.country: XL
>   user.country.format: (2-char country code for the selected Region)
>
> Thanks,
> -Brent
>
> On 21/06/16 14:48, Naoto Sato wrote:
>> Hi Brent,
>>
>> I looked at the system preference setting panel and noticed there is
>> "Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as
>> the designate region. Can you make changes to deal with it? (sorry I
>> should have noticed this earlier, and it's unfortunate not to be able to
>> upcall Locale.forLanguageTag()!)
>>
>> Naoto
>>
>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>> Hi,
>>>
>>> I have an updated webrev at:
>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>>
>>> The comments have been updated as Gerard suggested.
>>>
>>> The code to process the languageString now accounts for 3-character
>>> language codes, and 4-char script designations (line 86).
>>>
>>> More extensive testing of languages with multiple scripts/regions
>>> revealed that more changes were needed to maintain current behavior.
>>> Without knowing the internal workings of how
>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I
>>> believe the best options are to add a few more mappings as needed to
>>> locale_aliases (locale_str.h), and to add a special case for Portuguese
>>> (line 104).
>>>
>>> OS X has 3 language options for Portuguese:
>>> Portugues (Portugal)
>>> Portugues (Brasil)
>>> Portugues (Brasileiro)
>>>
>>> CFLocaleCopyPreferredLanguages() gives the expected language code for
>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
>>> include a region code (it's simply, "pt"), so gets mapped to the default
>>> country, Portugal.  To maintain current behavior, I added a special case
>>> to map "pt" to "pt_BR" when the Region system preference is set to
>>> Brazil.
>>>
>>>
>>> This change introduces one notable behavior change, which I argue is
>>> actually a fix.  The bug report and test case do not list the "Spanish
>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was
>>> added to the OS since the original investigation).  The old code mapped
>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country
>>> codes.  The new code maps to "es_MX", MX being the country code for
>>> Mexico.
>>>
>>>
>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried
>>> every language that includes multiple scripts/locales.  I also added a
>>> couple updated tests to the bug report.
>>>
>>> General testing has looked good so far.
>>>
>>> Thanks,
>>> -Brent

From naoto.sato at oracle.com  Wed Jun 22 04:53:37 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Jun 2016 21:53:37 -0700
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
 java.util.regex.PatternSyntaxException
In-Reply-To: <475280c0-59e7-eec3-0702-5f554f2e1da3@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
	<5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
	<860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>
	<2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>
	<1585534f-0021-137a-392f-0a748722d9f3@oracle.com>
	<475280c0-59e7-eec3-0702-5f554f2e1da3@oracle.com>
Message-ID: <e1b173de-4766-505f-c142-ede981360254@oracle.com>

Modified line 243-246 to avoid generating a new List instance with 
Collectors.toList():

http://cr.openjdk.java.net/~naoto/8159781/webrev.03/

Naoto

On 6/21/16 1:51 PM, Naoto Sato wrote:
> Thank you for the review, Masayoshi.
>
> I don't think that "-verbose:gc" has anything to do with the long
> pattern string (the option had been there before I wrote the locale
> plugin), but I see your point here. I modified the fix according to your
> suggestion:
>
> http://cr.openjdk.java.net/~naoto/8159781/webrev.02/
>
> Naoto
>
> On 6/20/16 7:53 PM, Masayoshi Okutsu wrote:
>> If the long pattern string is avoided, it'll be unnecessary to use "%%"
>> and replaceAll? I'm also concerned to keep concatenating strings to
>> produce a long string (rather than using a StringBuilder). Would that be
>> the reason to put -verbose:gc in the test program? Use of List<String>
>> will simplify the processing as Mandy suggests.
>>
>> Masayoshi
>>
>>
>> On 6/21/2016 7:00 AM, Naoto Sato wrote:
>>> Here is the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~naoto/8159781/webrev.01/
>>>
>>> Naoto
>>>
>>> On 6/20/16 8:18 AM, Naoto Sato wrote:
>>>> Hi Mandy, thank you for the review.
>>>>
>>>> INCLUDE_LOCALE_FILES is actually a pattern template, and the real
>>>> filter
>>>> patterns are constructed at the runtime with the passed argument, by
>>>> replacing "%%" with locale patterns. So I think it is less complex to
>>>> handle it as the current way.
>>>>
>>>> I will modify the "regex:" prepending as you suggested.
>>>>
>>>> Naoto
>>>>
>>>> On 6/17/16 3:50 PM, Mandy Chung wrote:
>>>>>
>>>>>> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>> Decided to fix this separately from the other include locales issues.
>>>>>> Here is the bug and the proposed fix:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159781
>>>>>> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/
>>>>>
>>>>> The change looks okay.   This can be converted to use
>>>>> ResourceFilter::includeFilter(List<String> patterns) rather than
>>>>> building a comma-separated patterns string.  That means META_FILES and
>>>>> INCLUDE_LOCALE_FILES can be made as List<String>.  You have an option
>>>>> to prepend ?regex:? when constructing the patterns to pass to
>>>>> ResourceFilter.  I think that?s a good clean up to do.
>>>>>
>>>>> Mandy
>>>>>
>>

From mandy.chung at oracle.com  Wed Jun 22 14:41:42 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 22 Jun 2016 07:41:42 -0700
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
	java.util.regex.PatternSyntaxException
In-Reply-To: <e1b173de-4766-505f-c142-ede981360254@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
	<5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
	<860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>
	<2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>
	<1585534f-0021-137a-392f-0a748722d9f3@oracle.com>
	<475280c0-59e7-eec3-0702-5f554f2e1da3@oracle.com>
	<e1b173de-4766-505f-c142-ede981360254@oracle.com>
Message-ID: <24873FEE-1B7E-4504-9C64-2B0C427BDD86@oracle.com>


> On Jun 21, 2016, at 9:53 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Modified line 243-246 to avoid generating a new List instance with Collectors.toList():
> 
> http://cr.openjdk.java.net/~naoto/8159781/webrev.03/

+1

Mandy

From masayoshi.okutsu at oracle.com  Wed Jun 22 15:13:30 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 23 Jun 2016 00:13:30 +0900
Subject: <i18n dev> [9] RFR: 8159781: jlink --include-locales fails with
 java.util.regex.PatternSyntaxException
In-Reply-To: <e1b173de-4766-505f-c142-ede981360254@oracle.com>
References: <8d7da12b-1d76-1ae1-fadc-370ad5e4b9f4@oracle.com>
	<15177A4B-2625-46EA-B7F2-C02ACFFCED62@oracle.com>
	<adbab592-c1d0-82a5-8088-ba723124e112@oracle.com>
	<A242574C-6658-48D1-A3A1-4F27034FF354@oracle.com>
	<34199753-b7dc-1235-f34b-bffe9b513c0a@oracle.com>
	<e9afec42-7a32-b048-51f9-86978e8fc303@oracle.com>
	<a500fa2d-906a-2416-9395-568d6346d422@oracle.com>
	<3762adab-ceba-0284-ed82-618e5ea9e0ab@oracle.com>
	<5A96B27F-E13F-4DF5-BEFC-1307B2CA9EE1@oracle.com>
	<860925ce-787d-e1a4-307b-4345d37be72c@oracle.com>
	<2c0afdf4-bbc2-f8b3-114b-4be89e71b6a6@oracle.com>
	<1585534f-0021-137a-392f-0a748722d9f3@oracle.com>
	<475280c0-59e7-eec3-0702-5f554f2e1da3@oracle.com>
	<e1b173de-4766-505f-c142-ede981360254@oracle.com>
Message-ID: <a00beee4-28a7-d041-d692-fad58055822e@oracle.com>

Looks good.

Masayoshi


On 6/22/2016 1:53 PM, Naoto Sato wrote:
> Modified line 243-246 to avoid generating a new List instance with 
> Collectors.toList():
>
> http://cr.openjdk.java.net/~naoto/8159781/webrev.03/
>
> Naoto
>
> On 6/21/16 1:51 PM, Naoto Sato wrote:
>> Thank you for the review, Masayoshi.
>>
>> I don't think that "-verbose:gc" has anything to do with the long
>> pattern string (the option had been there before I wrote the locale
>> plugin), but I see your point here. I modified the fix according to your
>> suggestion:
>>
>> http://cr.openjdk.java.net/~naoto/8159781/webrev.02/
>>
>> Naoto
>>
>> On 6/20/16 7:53 PM, Masayoshi Okutsu wrote:
>>> If the long pattern string is avoided, it'll be unnecessary to use "%%"
>>> and replaceAll? I'm also concerned to keep concatenating strings to
>>> produce a long string (rather than using a StringBuilder). Would 
>>> that be
>>> the reason to put -verbose:gc in the test program? Use of List<String>
>>> will simplify the processing as Mandy suggests.
>>>
>>> Masayoshi
>>>
>>>
>>> On 6/21/2016 7:00 AM, Naoto Sato wrote:
>>>> Here is the updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8159781/webrev.01/
>>>>
>>>> Naoto
>>>>
>>>> On 6/20/16 8:18 AM, Naoto Sato wrote:
>>>>> Hi Mandy, thank you for the review.
>>>>>
>>>>> INCLUDE_LOCALE_FILES is actually a pattern template, and the real
>>>>> filter
>>>>> patterns are constructed at the runtime with the passed argument, by
>>>>> replacing "%%" with locale patterns. So I think it is less complex to
>>>>> handle it as the current way.
>>>>>
>>>>> I will modify the "regex:" prepending as you suggested.
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 6/17/16 3:50 PM, Mandy Chung wrote:
>>>>>>
>>>>>>> On Jun 17, 2016, at 3:29 PM, Naoto Sato <naoto.sato at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Decided to fix this separately from the other include locales 
>>>>>>> issues.
>>>>>>> Here is the bug and the proposed fix:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159781
>>>>>>> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/
>>>>>>
>>>>>> The change looks okay.   This can be converted to use
>>>>>> ResourceFilter::includeFilter(List<String> patterns) rather than
>>>>>> building a comma-separated patterns string.  That means 
>>>>>> META_FILES and
>>>>>> INCLUDE_LOCALE_FILES can be made as List<String>. You have an option
>>>>>> to prepend ?regex:? when constructing the patterns to pass to
>>>>>> ResourceFilter.  I think that?s a good clean up to do.
>>>>>>
>>>>>> Mandy
>>>>>>
>>>


From brent.christian at oracle.com  Wed Jun 22 21:45:19 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 22 Jun 2016 14:45:19 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
	<f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
Message-ID: <be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>

On 6/21/16 3:27 PM, Naoto Sato wrote:
> Actually, j.u.Locale class' "country" code is defined as ISO-3166
> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying
> setting is "es-419" for the preferred language, "user.country" should be
> "419".

OK, thanks - looks like another latent locale bug on Mac.  I've uploaded 
output comparing the old [1] and new[2] behavior WRT java.util.Locale 
under Spanish (Latin America).  It looks correct to me, based on my 
reading of Locale.toString()/getCountry()toLanguageTag().

The updated webrev is here:
http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/

The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region 
designators.  The es-419 mapping is no longer needed in locale_str.h.

Thanks!
-Brent

1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt
2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt

> On 6/21/16 3:17 PM, Brent Christian wrote:
>> Hi, Naoto
>>
>> "Spanish (Latin America)" already works the same as it did before the
>> change - it maps to "es_XL".  Because "es-419" has more than 2
>> characters following the '-', no change is made and
>> getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping for
>> "es-419" -> "es_XL" in locale_str.h.
>>
>> System property values are (still) set to:
>>   user.language: es
>>   user.country: XL
>>   user.country.format: (2-char country code for the selected Region)
>>
>> Thanks,
>> -Brent
>>
>> On 21/06/16 14:48, Naoto Sato wrote:
>>> Hi Brent,
>>>
>>> I looked at the system preference setting panel and noticed there is
>>> "Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as
>>> the designate region. Can you make changes to deal with it? (sorry I
>>> should have noticed this earlier, and it's unfortunate not to be able to
>>> upcall Locale.forLanguageTag()!)
>>>
>>> Naoto
>>>
>>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>>> Hi,
>>>>
>>>> I have an updated webrev at:
>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>>>
>>>> The comments have been updated as Gerard suggested.
>>>>
>>>> The code to process the languageString now accounts for 3-character
>>>> language codes, and 4-char script designations (line 86).
>>>>
>>>> More extensive testing of languages with multiple scripts/regions
>>>> revealed that more changes were needed to maintain current behavior.
>>>> Without knowing the internal workings of how
>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I
>>>> believe the best options are to add a few more mappings as needed to
>>>> locale_aliases (locale_str.h), and to add a special case for Portuguese
>>>> (line 104).
>>>>
>>>> OS X has 3 language options for Portuguese:
>>>> Portugues (Portugal)
>>>> Portugues (Brasil)
>>>> Portugues (Brasileiro)
>>>>
>>>> CFLocaleCopyPreferredLanguages() gives the expected language code for
>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
>>>> include a region code (it's simply, "pt"), so gets mapped to the
>>>> default
>>>> country, Portugal.  To maintain current behavior, I added a special
>>>> case
>>>> to map "pt" to "pt_BR" when the Region system preference is set to
>>>> Brazil.
>>>>
>>>>
>>>> This change introduces one notable behavior change, which I argue is
>>>> actually a fix.  The bug report and test case do not list the "Spanish
>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was
>>>> added to the OS since the original investigation).  The old code mapped
>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country
>>>> codes.  The new code maps to "es_MX", MX being the country code for
>>>> Mexico.
>>>>
>>>>
>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried
>>>> every language that includes multiple scripts/locales.  I also added a
>>>> couple updated tests to the bug report.
>>>>
>>>> General testing has looked good so far.
>>>>
>>>> Thanks,
>>>> -Brent

From brent.christian at oracle.com  Wed Jun 22 22:27:10 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 22 Jun 2016 15:27:10 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <B5E026FF-F7D2-40B2-A1DD-BE809151D542@apple.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<AD4C260B-F303-4EAA-A41C-579C2DCE2C77@apple.com>
	<5462a432-6ae9-cf89-f2eb-0324c70ac80e@oracle.com>
	<B5E026FF-F7D2-40B2-A1DD-BE809151D542@apple.com>
Message-ID: <3c09bc21-0ad1-6387-7464-2d98fc7109f0@oracle.com>

On 22/06/16 15:10, Alex Strange wrote:
>> On Jun 20, 2016, at 3:44 PM, Brent Christian <brent.christian at oracle.com> wrote:
>>
>> I'd prefer something that can build on SDK 10.9 and 10.10, etc.
>
> There might be a way to #ifdef it out (not sure), but it's not worth it.

I came to the same conclusion. :)

Thanks!

-Brent


From naoto.sato at oracle.com  Wed Jun 22 22:58:27 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 22 Jun 2016 15:58:27 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
	<f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
	<be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>
Message-ID: <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com>

Hi Brent,

1. It seems that the display language in the new code seems to have some 
problems. I see (in es-419.txt):

---
locale[Default|Display|Format].getLanguage () is
user.language: it is
---

And in fact, display strings are no longer in Spanish in the new version 
(as the language is "is").

2. I think mapping language/script combination to a typical locale is ok 
to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS, 
right?) In the meantime, I would like to have "user.script" set to 
"Latn" in such a case.

Naoto

On 6/22/16 2:45 PM, Brent Christian wrote:
> On 6/21/16 3:27 PM, Naoto Sato wrote:
>> Actually, j.u.Locale class' "country" code is defined as ISO-3166
>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying
>> setting is "es-419" for the preferred language, "user.country" should be
>> "419".
>
> OK, thanks - looks like another latent locale bug on Mac.  I've uploaded
> output comparing the old [1] and new[2] behavior WRT java.util.Locale
> under Spanish (Latin America).  It looks correct to me, based on my
> reading of Locale.toString()/getCountry()toLanguageTag().
>
> The updated webrev is here:
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/
>
> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region
> designators.  The es-419 mapping is no longer needed in locale_str.h.
>
> Thanks!
> -Brent
>
> 1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt
> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt
>
>> On 6/21/16 3:17 PM, Brent Christian wrote:
>>> Hi, Naoto
>>>
>>> "Spanish (Latin America)" already works the same as it did before the
>>> change - it maps to "es_XL".  Because "es-419" has more than 2
>>> characters following the '-', no change is made and
>>> getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping for
>>> "es-419" -> "es_XL" in locale_str.h.
>>>
>>> System property values are (still) set to:
>>>   user.language: es
>>>   user.country: XL
>>>   user.country.format: (2-char country code for the selected Region)
>>>
>>> Thanks,
>>> -Brent
>>>
>>> On 21/06/16 14:48, Naoto Sato wrote:
>>>> Hi Brent,
>>>>
>>>> I looked at the system preference setting panel and noticed there is
>>>> "Spanish (Latin America)", which I think uses UN M.49 code
>>>> ("es-419") as
>>>> the designate region. Can you make changes to deal with it? (sorry I
>>>> should have noticed this earlier, and it's unfortunate not to be
>>>> able to
>>>> upcall Locale.forLanguageTag()!)
>>>>
>>>> Naoto
>>>>
>>>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>>>> Hi,
>>>>>
>>>>> I have an updated webrev at:
>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>>>>
>>>>> The comments have been updated as Gerard suggested.
>>>>>
>>>>> The code to process the languageString now accounts for 3-character
>>>>> language codes, and 4-char script designations (line 86).
>>>>>
>>>>> More extensive testing of languages with multiple scripts/regions
>>>>> revealed that more changes were needed to maintain current behavior.
>>>>> Without knowing the internal workings of how
>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I
>>>>> believe the best options are to add a few more mappings as needed to
>>>>> locale_aliases (locale_str.h), and to add a special case for
>>>>> Portuguese
>>>>> (line 104).
>>>>>
>>>>> OS X has 3 language options for Portuguese:
>>>>> Portugues (Portugal)
>>>>> Portugues (Brasil)
>>>>> Portugues (Brasileiro)
>>>>>
>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code for
>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
>>>>> include a region code (it's simply, "pt"), so gets mapped to the
>>>>> default
>>>>> country, Portugal.  To maintain current behavior, I added a special
>>>>> case
>>>>> to map "pt" to "pt_BR" when the Region system preference is set to
>>>>> Brazil.
>>>>>
>>>>>
>>>>> This change introduces one notable behavior change, which I argue is
>>>>> actually a fix.  The bug report and test case do not list the "Spanish
>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was
>>>>> added to the OS since the original investigation).  The old code
>>>>> mapped
>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country
>>>>> codes.  The new code maps to "es_MX", MX being the country code for
>>>>> Mexico.
>>>>>
>>>>>
>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried
>>>>> every language that includes multiple scripts/locales.  I also added a
>>>>> couple updated tests to the bug report.
>>>>>
>>>>> General testing has looked good so far.
>>>>>
>>>>> Thanks,
>>>>> -Brent

From astrange at apple.com  Wed Jun 22 22:10:52 2016
From: astrange at apple.com (Alex Strange)
Date: Wed, 22 Jun 2016 15:10:52 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
	requesting install" when creating VM from JNI [macosx]
In-Reply-To: <5462a432-6ae9-cf89-f2eb-0324c70ac80e@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<AD4C260B-F303-4EAA-A41C-579C2DCE2C77@apple.com>
	<5462a432-6ae9-cf89-f2eb-0324c70ac80e@oracle.com>
Message-ID: <B5E026FF-F7D2-40B2-A1DD-BE809151D542@apple.com>


> On Jun 20, 2016, at 3:44 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> 
> Alex - thanks for your response.  More below...
> 
> On 6/13/16 4:51 PM, Alex Strange wrote:
>>> 2. In "setupMacOSXLocale" we simply drop the call to
>>> "JRSSetDefaultLocalization" as it appears to be a NOP. According to
>>> Apple, that API sets up native bundle locale, so that any access to
>>> native Cocoa UI (like FileOpenChooser) uses localized strings.
>>> Testing shows that this does not seem to work even in Apple's own
>>> JDK (ie. JDK 6), so dropping the call to this SPI here does not
>>> result in a regression.  An issue was filed to investigate further
>>> (8024279, a dup of 8019464) which has since been closed as, "Not an
>>> Issue".
>> 
>> This was added a very long time ago so that 'java -jar x.jar' would
>> show properly localized menus in the menubar, instead of English
>> menus, on a non-English system. It might no longer be a problem.
> 
> OK, thanks.
> 
> 'java -jar x.jar' behavior is unchanged with this patch.  (From the bug report, it hasn't worked since JDK 7).

That's unfortunate, since it probably means I broke it back then. Sorry about that.

> 
>>> 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using
>>> [NSProcessInfo operatingSystemVersion].  (Use of JRSCopyOSName was
>>> already removed by 7178922).
>> 
>> You shouldn't need to use objc_msgSend_stret here. If you're not
>> getting a warning when you use @selector in the line above, you
>> should just be able to call -operationgSystemVersion directly inside
>> the if.
>> 
>> If you are getting a warning, it'd be best to declare the selector
>> yourself somewhere higher up:
>> 
>> typedef struct {
>>        NSInteger majorVersion;
>>        NSInteger minorVersion;
>>        NSInteger patchVersion;
>> } OSVerStruct;
>> 
>> @interface NSProcessInfo ()
>> - (OSVerStruct)operatingSystemVersion;
>> @end
> 
> Thanks - this works for building w/ the 10.9 SDK (the officially supported Mac SDK for building JDK).
> 
> But I believe people also build w/ the 10.10 SDK (I've not tried it myself).  Won't this cause problems, since NSProcessInfo already has "operatingSystemVersion", and it returns an NSOperatingSystemVersion, not an OSVerStruct ?
> 
> I'd prefer something that can build on SDK 10.9 and 10.10, etc.  Once the official build moves to 10.10/later, objc_msgSend() can be removed and we can use [NSProcessInfo operatingSystemVersion] directly.

Ah, I see. Your way is correct, then. There might be a way to #ifdef it out (not sure), but it's not worth it.

> 
> Thanks,
> -Brent


From brent.christian at oracle.com  Thu Jun 23 04:48:28 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 22 Jun 2016 21:48:28 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
	<f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
	<be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>
	<7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com>
Message-ID: <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com>

On 6/22/16 3:58 PM, Naoto Sato wrote:
> Hi Brent,
>
> 1. It seems that the display language in the new code seems to have some
> problems. I see (in es-419.txt):
>
> ---
> locale[Default|Display|Format].getLanguage () is
> user.language: it is
> ---
>
> And in fact, display strings are no longer in Spanish in the new version
> (as the language is "is").

Strange - something in your local environment?  It looks right to me.

> 2. I think mapping language/script combination to a typical locale is ok
> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS,
> right?) In the meantime, I would like to have "user.script" set to
> "Latn" in such a case.

Is this something that I could file a follow-on issue for?  The existing 
code doesn't set "user.script" in these cases, either, and it looks like 
that would take some digging into java_props_md.c...

-Brent

> On 6/22/16 2:45 PM, Brent Christian wrote:
>> On 6/21/16 3:27 PM, Naoto Sato wrote:
>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166
>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying
>>> setting is "es-419" for the preferred language, "user.country" should be
>>> "419".
>>
>> OK, thanks - looks like another latent locale bug on Mac.  I've uploaded
>> output comparing the old [1] and new[2] behavior WRT java.util.Locale
>> under Spanish (Latin America).  It looks correct to me, based on my
>> reading of Locale.toString()/getCountry()toLanguageTag().
>>
>> The updated webrev is here:
>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/
>>
>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region
>> designators.  The es-419 mapping is no longer needed in locale_str.h.
>>
>> Thanks!
>> -Brent
>>
>> 1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt
>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt
>>
>>> On 6/21/16 3:17 PM, Brent Christian wrote:
>>>> Hi, Naoto
>>>>
>>>> "Spanish (Latin America)" already works the same as it did before the
>>>> change - it maps to "es_XL".  Because "es-419" has more than 2
>>>> characters following the '-', no change is made and
>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping for
>>>> "es-419" -> "es_XL" in locale_str.h.
>>>>
>>>> System property values are (still) set to:
>>>>   user.language: es
>>>>   user.country: XL
>>>>   user.country.format: (2-char country code for the selected Region)
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>> On 21/06/16 14:48, Naoto Sato wrote:
>>>>> Hi Brent,
>>>>>
>>>>> I looked at the system preference setting panel and noticed there is
>>>>> "Spanish (Latin America)", which I think uses UN M.49 code
>>>>> ("es-419") as
>>>>> the designate region. Can you make changes to deal with it? (sorry I
>>>>> should have noticed this earlier, and it's unfortunate not to be
>>>>> able to
>>>>> upcall Locale.forLanguageTag()!)
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have an updated webrev at:
>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>>>>>
>>>>>> The comments have been updated as Gerard suggested.
>>>>>>
>>>>>> The code to process the languageString now accounts for 3-character
>>>>>> language codes, and 4-char script designations (line 86).
>>>>>>
>>>>>> More extensive testing of languages with multiple scripts/regions
>>>>>> revealed that more changes were needed to maintain current behavior.
>>>>>> Without knowing the internal workings of how
>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I
>>>>>> believe the best options are to add a few more mappings as needed to
>>>>>> locale_aliases (locale_str.h), and to add a special case for
>>>>>> Portuguese
>>>>>> (line 104).
>>>>>>
>>>>>> OS X has 3 language options for Portuguese:
>>>>>> Portugues (Portugal)
>>>>>> Portugues (Brasil)
>>>>>> Portugues (Brasileiro)
>>>>>>
>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code for
>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
>>>>>> include a region code (it's simply, "pt"), so gets mapped to the
>>>>>> default
>>>>>> country, Portugal.  To maintain current behavior, I added a special
>>>>>> case
>>>>>> to map "pt" to "pt_BR" when the Region system preference is set to
>>>>>> Brazil.
>>>>>>
>>>>>>
>>>>>> This change introduces one notable behavior change, which I argue is
>>>>>> actually a fix.  The bug report and test case do not list the
>>>>>> "Spanish
>>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it
>>>>>> was
>>>>>> added to the OS since the original investigation).  The old code
>>>>>> mapped
>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country
>>>>>> codes.  The new code maps to "es_MX", MX being the country code for
>>>>>> Mexico.
>>>>>>
>>>>>>
>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried
>>>>>> every language that includes multiple scripts/locales.  I also
>>>>>> added a
>>>>>> couple updated tests to the bug report.
>>>>>>
>>>>>> General testing has looked good so far.
>>>>>>
>>>>>> Thanks,
>>>>>> -Brent

From rachna.goel at oracle.com  Thu Jun 23 09:09:59 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Thu, 23 Jun 2016 14:39:59 +0530
Subject: <i18n dev> Review request : JDK-8158504 -
 test/sun/util/locale/provider/Bug8038436.java fails
Message-ID: <b809b2d6-5bcc-ef29-ca00-f94bd3de3660@oracle.com>

Hi,

Please review fix for JDK-8158504.

Bug : https://bugs.openjdk.java.net/browse/JDK-8158504

Webrev : http://cr.openjdk.java.net/~nishjain/rgoel/8158504/webrev.03/

Fix : Removed java.ext.dirs System property as it is no longer supported 
in JDK9 and used "-limitmods java.base"  to load only java.base.
         (To hide jdk.localedata module).
         JRE is COMPAT in JDK9.
         outputted some useful information if test fails somewhere.

-- 
Thanks,
Rachna


From naoto.sato at oracle.com  Thu Jun 23 15:24:48 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 23 Jun 2016 08:24:48 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
	<f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
	<be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>
	<7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com>
	<885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com>
Message-ID: <de4f426c-cf4b-50eb-f46e-e21b4e43c9d6@oracle.com>

On 6/22/16 9:48 PM, Brent Christian wrote:
> On 6/22/16 3:58 PM, Naoto Sato wrote:
>> Hi Brent,
>>
>> 1. It seems that the display language in the new code seems to have some
>> problems. I see (in es-419.txt):
>>
>> ---
>> locale[Default|Display|Format].getLanguage () is
>> user.language: it is
>> ---
>>
>> And in fact, display strings are no longer in Spanish in the new version
>> (as the language is "is").
>
> Strange - something in your local environment?  It looks right to me.

Never mind. Thanks to Chrome, it was automatically converted to English 
:-) Funny thing was that the browser did not translate to English for 
es-419.old.txt...

>
>> 2. I think mapping language/script combination to a typical locale is ok
>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS,
>> right?) In the meantime, I would like to have "user.script" set to
>> "Latn" in such a case.
>
> Is this something that I could file a follow-on issue for?  The existing
> code doesn't set "user.script" in these cases, either, and it looks like
> that would take some digging into java_props_md.c...

Fine by me.

Naoto

>
> -Brent
>
>> On 6/22/16 2:45 PM, Brent Christian wrote:
>>> On 6/21/16 3:27 PM, Naoto Sato wrote:
>>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166
>>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying
>>>> setting is "es-419" for the preferred language, "user.country"
>>>> should be
>>>> "419".
>>>
>>> OK, thanks - looks like another latent locale bug on Mac.  I've uploaded
>>> output comparing the old [1] and new[2] behavior WRT java.util.Locale
>>> under Spanish (Latin America).  It looks correct to me, based on my
>>> reading of Locale.toString()/getCountry()toLanguageTag().
>>>
>>> The updated webrev is here:
>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/
>>>
>>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region
>>> designators.  The es-419 mapping is no longer needed in locale_str.h.
>>>
>>> Thanks!
>>> -Brent
>>>
>>> 1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt
>>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt
>>>
>>>> On 6/21/16 3:17 PM, Brent Christian wrote:
>>>>> Hi, Naoto
>>>>>
>>>>> "Spanish (Latin America)" already works the same as it did before the
>>>>> change - it maps to "es_XL".  Because "es-419" has more than 2
>>>>> characters following the '-', no change is made and
>>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping for
>>>>> "es-419" -> "es_XL" in locale_str.h.
>>>>>
>>>>> System property values are (still) set to:
>>>>>   user.language: es
>>>>>   user.country: XL
>>>>>   user.country.format: (2-char country code for the selected Region)
>>>>>
>>>>> Thanks,
>>>>> -Brent
>>>>>
>>>>> On 21/06/16 14:48, Naoto Sato wrote:
>>>>>> Hi Brent,
>>>>>>
>>>>>> I looked at the system preference setting panel and noticed there is
>>>>>> "Spanish (Latin America)", which I think uses UN M.49 code
>>>>>> ("es-419") as
>>>>>> the designate region. Can you make changes to deal with it? (sorry I
>>>>>> should have noticed this earlier, and it's unfortunate not to be
>>>>>> able to
>>>>>> upcall Locale.forLanguageTag()!)
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have an updated webrev at:
>>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>>>>>>
>>>>>>> The comments have been updated as Gerard suggested.
>>>>>>>
>>>>>>> The code to process the languageString now accounts for 3-character
>>>>>>> language codes, and 4-char script designations (line 86).
>>>>>>>
>>>>>>> More extensive testing of languages with multiple scripts/regions
>>>>>>> revealed that more changes were needed to maintain current behavior.
>>>>>>> Without knowing the internal workings of how
>>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language
>>>>>>> ID, I
>>>>>>> believe the best options are to add a few more mappings as needed to
>>>>>>> locale_aliases (locale_str.h), and to add a special case for
>>>>>>> Portuguese
>>>>>>> (line 104).
>>>>>>>
>>>>>>> OS X has 3 language options for Portuguese:
>>>>>>> Portugues (Portugal)
>>>>>>> Portugues (Brasil)
>>>>>>> Portugues (Brasileiro)
>>>>>>>
>>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code
>>>>>>> for
>>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
>>>>>>> include a region code (it's simply, "pt"), so gets mapped to the
>>>>>>> default
>>>>>>> country, Portugal.  To maintain current behavior, I added a special
>>>>>>> case
>>>>>>> to map "pt" to "pt_BR" when the Region system preference is set to
>>>>>>> Brazil.
>>>>>>>
>>>>>>>
>>>>>>> This change introduces one notable behavior change, which I argue is
>>>>>>> actually a fix.  The bug report and test case do not list the
>>>>>>> "Spanish
>>>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it
>>>>>>> was
>>>>>>> added to the OS since the original investigation).  The old code
>>>>>>> mapped
>>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166
>>>>>>> country
>>>>>>> codes.  The new code maps to "es_MX", MX being the country code for
>>>>>>> Mexico.
>>>>>>>
>>>>>>>
>>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried
>>>>>>> every language that includes multiple scripts/locales.  I also
>>>>>>> added a
>>>>>>> couple updated tests to the bug report.
>>>>>>>
>>>>>>> General testing has looked good so far.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Brent

From naoto.sato at oracle.com  Thu Jun 23 16:05:55 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 23 Jun 2016 09:05:55 -0700
Subject: <i18n dev> Review request : JDK-8158504 -
 test/sun/util/locale/provider/Bug8038436.java fails
In-Reply-To: <b809b2d6-5bcc-ef29-ca00-f94bd3de3660@oracle.com>
References: <b809b2d6-5bcc-ef29-ca00-f94bd3de3660@oracle.com>
Message-ID: <b6b76e70-f855-f72b-3a78-ef59d868390a@oracle.com>

Hi Rachna,

The test needs to be modified to ensure locales only for ROOT and en_US* 
locales for java.base module. Currently it would pass if 
getAvailableLocales() included English locales other than US ones, say 
en_GB. I should have corrected it, but apparently I overlooked.

 > if (nonEnglishLocales.size() > 0) {

You could use !isEmpty() instead.

Naoto

On 6/23/16 2:09 AM, Rachna Goel wrote:
> Hi,
>
> Please review fix for JDK-8158504.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8158504
>
> Webrev : http://cr.openjdk.java.net/~nishjain/rgoel/8158504/webrev.03/
>
> Fix : Removed java.ext.dirs System property as it is no longer supported
> in JDK9 and used "-limitmods java.base"  to load only java.base.
>         (To hide jdk.localedata module).
>         JRE is COMPAT in JDK9.
>         outputted some useful information if test fails somewhere.
>

From naoto.sato at oracle.com  Thu Jun 23 17:34:59 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 23 Jun 2016 10:34:59 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <de4f426c-cf4b-50eb-f46e-e21b4e43c9d6@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
	<f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
	<be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>
	<7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com>
	<885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com>
	<de4f426c-cf4b-50eb-f46e-e21b4e43c9d6@oracle.com>
Message-ID: <c8094303-e51f-8a84-feab-cde5220f1e47@oracle.com>

I reviewed webrev.04 thoroughly this time and comments below:

- Although the OSX API returns the cases as in the spec, BCP 47 language 
tags are case insensitive, so it would be  better to check [a-z] in line 
94/95 as well.

- Line 82: Does the API actually returns "zh-Hans_HK"? Underscore ('_') 
is not a part of language tags.

Other than those, it looks good to me.

Naoto

On 6/23/16 8:24 AM, Naoto Sato wrote:
> On 6/22/16 9:48 PM, Brent Christian wrote:
>> On 6/22/16 3:58 PM, Naoto Sato wrote:
>>> Hi Brent,
>>>
>>> 1. It seems that the display language in the new code seems to have some
>>> problems. I see (in es-419.txt):
>>>
>>> ---
>>> locale[Default|Display|Format].getLanguage () is
>>> user.language: it is
>>> ---
>>>
>>> And in fact, display strings are no longer in Spanish in the new version
>>> (as the language is "is").
>>
>> Strange - something in your local environment?  It looks right to me.
>
> Never mind. Thanks to Chrome, it was automatically converted to English
> :-) Funny thing was that the browser did not translate to English for
> es-419.old.txt...
>
>>
>>> 2. I think mapping language/script combination to a typical locale is ok
>>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS,
>>> right?) In the meantime, I would like to have "user.script" set to
>>> "Latn" in such a case.
>>
>> Is this something that I could file a follow-on issue for?  The existing
>> code doesn't set "user.script" in these cases, either, and it looks like
>> that would take some digging into java_props_md.c...
>
> Fine by me.
>
> Naoto
>
>>
>> -Brent
>>
>>> On 6/22/16 2:45 PM, Brent Christian wrote:
>>>> On 6/21/16 3:27 PM, Naoto Sato wrote:
>>>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166
>>>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying
>>>>> setting is "es-419" for the preferred language, "user.country"
>>>>> should be
>>>>> "419".
>>>>
>>>> OK, thanks - looks like another latent locale bug on Mac.  I've
>>>> uploaded
>>>> output comparing the old [1] and new[2] behavior WRT java.util.Locale
>>>> under Spanish (Latin America).  It looks correct to me, based on my
>>>> reading of Locale.toString()/getCountry()toLanguageTag().
>>>>
>>>> The updated webrev is here:
>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/
>>>>
>>>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region
>>>> designators.  The es-419 mapping is no longer needed in locale_str.h.
>>>>
>>>> Thanks!
>>>> -Brent
>>>>
>>>> 1.
>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt
>>>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt
>>>>
>>>>> On 6/21/16 3:17 PM, Brent Christian wrote:
>>>>>> Hi, Naoto
>>>>>>
>>>>>> "Spanish (Latin America)" already works the same as it did before the
>>>>>> change - it maps to "es_XL".  Because "es-419" has more than 2
>>>>>> characters following the '-', no change is made and
>>>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping for
>>>>>> "es-419" -> "es_XL" in locale_str.h.
>>>>>>
>>>>>> System property values are (still) set to:
>>>>>>   user.language: es
>>>>>>   user.country: XL
>>>>>>   user.country.format: (2-char country code for the selected Region)
>>>>>>
>>>>>> Thanks,
>>>>>> -Brent
>>>>>>
>>>>>> On 21/06/16 14:48, Naoto Sato wrote:
>>>>>>> Hi Brent,
>>>>>>>
>>>>>>> I looked at the system preference setting panel and noticed there is
>>>>>>> "Spanish (Latin America)", which I think uses UN M.49 code
>>>>>>> ("es-419") as
>>>>>>> the designate region. Can you make changes to deal with it? (sorry I
>>>>>>> should have noticed this earlier, and it's unfortunate not to be
>>>>>>> able to
>>>>>>> upcall Locale.forLanguageTag()!)
>>>>>>>
>>>>>>> Naoto
>>>>>>>
>>>>>>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have an updated webrev at:
>>>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>>>>>>>
>>>>>>>> The comments have been updated as Gerard suggested.
>>>>>>>>
>>>>>>>> The code to process the languageString now accounts for 3-character
>>>>>>>> language codes, and 4-char script designations (line 86).
>>>>>>>>
>>>>>>>> More extensive testing of languages with multiple scripts/regions
>>>>>>>> revealed that more changes were needed to maintain current
>>>>>>>> behavior.
>>>>>>>> Without knowing the internal workings of how
>>>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language
>>>>>>>> ID, I
>>>>>>>> believe the best options are to add a few more mappings as
>>>>>>>> needed to
>>>>>>>> locale_aliases (locale_str.h), and to add a special case for
>>>>>>>> Portuguese
>>>>>>>> (line 104).
>>>>>>>>
>>>>>>>> OS X has 3 language options for Portuguese:
>>>>>>>> Portugues (Portugal)
>>>>>>>> Portugues (Brasil)
>>>>>>>> Portugues (Brasileiro)
>>>>>>>>
>>>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code
>>>>>>>> for
>>>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
>>>>>>>> include a region code (it's simply, "pt"), so gets mapped to the
>>>>>>>> default
>>>>>>>> country, Portugal.  To maintain current behavior, I added a special
>>>>>>>> case
>>>>>>>> to map "pt" to "pt_BR" when the Region system preference is set to
>>>>>>>> Brazil.
>>>>>>>>
>>>>>>>>
>>>>>>>> This change introduces one notable behavior change, which I
>>>>>>>> argue is
>>>>>>>> actually a fix.  The bug report and test case do not list the
>>>>>>>> "Spanish
>>>>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it
>>>>>>>> was
>>>>>>>> added to the OS since the original investigation).  The old code
>>>>>>>> mapped
>>>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166
>>>>>>>> country
>>>>>>>> codes.  The new code maps to "es_MX", MX being the country code for
>>>>>>>> Mexico.
>>>>>>>>
>>>>>>>>
>>>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I
>>>>>>>> tried
>>>>>>>> every language that includes multiple scripts/locales.  I also
>>>>>>>> added a
>>>>>>>> couple updated tests to the bug report.
>>>>>>>>
>>>>>>>> General testing has looked good so far.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Brent

From brent.christian at oracle.com  Thu Jun 23 17:39:03 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 23 Jun 2016 10:39:03 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <de4f426c-cf4b-50eb-f46e-e21b4e43c9d6@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
	<f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
	<be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>
	<7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com>
	<885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com>
	<de4f426c-cf4b-50eb-f46e-e21b4e43c9d6@oracle.com>
Message-ID: <566324bd-19bf-3ec2-840d-2292f8264c0d@oracle.com>

On 6/23/16 8:24 AM, Naoto Sato wrote:
> On 6/22/16 9:48 PM, Brent Christian wrote:
>> On 6/22/16 3:58 PM, Naoto Sato wrote:
>>>
>>> 2. I think mapping language/script combination to a typical locale is ok
>>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS,
>>> right?) In the meantime, I would like to have "user.script" set to
>>> "Latn" in such a case.
>>
>> Is this something that I could file a follow-on issue for?  The existing
>> code doesn't set "user.script" in these cases, either, and it looks like
>> that would take some digging into java_props_md.c...
>
> Fine by me.

I have filed 8160199, "Language's script should be reflected in 
user.script on Mac OS X".

Thanks,
-Brent


From brent.christian at oracle.com  Thu Jun 23 20:13:40 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 23 Jun 2016 13:13:40 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <c8094303-e51f-8a84-feab-cde5220f1e47@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
	<f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
	<be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>
	<7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com>
	<885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com>
	<de4f426c-cf4b-50eb-f46e-e21b4e43c9d6@oracle.com>
	<c8094303-e51f-8a84-feab-cde5220f1e47@oracle.com>
Message-ID: <9da91e57-ad56-bdbf-996e-e0a1a5b7a98a@oracle.com>

On 23/6/16 ??10:34, Naoto Sato wrote:
> I reviewed webrev.04 thoroughly this time and comments below:
>
> - Although the OSX API returns the cases as in the spec, BCP 47 language
> tags are case insensitive, so it would be  better to check [a-z] in line
> 94/95 as well.

Done (and I've simplified the assert code to use isalpha() and isdigit()).

> - Line 82: Does the API actually returns "zh-Hans_HK"? Underscore ('_')
> is not a part of language tags.

Ah, thanks.  No, "zh-Hans_HK" is not returned by 
CFLocaleCopyPreferredLanguages().  We do see it in the default switch 
case when we call CFLocaleGetIdentifier(), which I guess was the source 
of my confusion.

I've removed that comment line, and reworked the comment a little bit.

http://cr.openjdk.java.net/~bchristi/7131356/webrev.05/

Thanks,
-Brent

> On 6/23/16 8:24 AM, Naoto Sato wrote:
>> On 6/22/16 9:48 PM, Brent Christian wrote:
>>> On 6/22/16 3:58 PM, Naoto Sato wrote:
>>>> Hi Brent,
>>>>
>>>> 1. It seems that the display language in the new code seems to have
>>>> some
>>>> problems. I see (in es-419.txt):
>>>>
>>>> ---
>>>> locale[Default|Display|Format].getLanguage () is
>>>> user.language: it is
>>>> ---
>>>>
>>>> And in fact, display strings are no longer in Spanish in the new
>>>> version
>>>> (as the language is "is").
>>>
>>> Strange - something in your local environment?  It looks right to me.
>>
>> Never mind. Thanks to Chrome, it was automatically converted to English
>> :-) Funny thing was that the browser did not translate to English for
>> es-419.old.txt...
>>
>>>
>>>> 2. I think mapping language/script combination to a typical locale
>>>> is ok
>>>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS,
>>>> right?) In the meantime, I would like to have "user.script" set to
>>>> "Latn" in such a case.
>>>
>>> Is this something that I could file a follow-on issue for?  The existing
>>> code doesn't set "user.script" in these cases, either, and it looks like
>>> that would take some digging into java_props_md.c...
>>
>> Fine by me.
>>
>> Naoto
>>
>>>
>>> -Brent
>>>
>>>> On 6/22/16 2:45 PM, Brent Christian wrote:
>>>>> On 6/21/16 3:27 PM, Naoto Sato wrote:
>>>>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166
>>>>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying
>>>>>> setting is "es-419" for the preferred language, "user.country"
>>>>>> should be
>>>>>> "419".
>>>>>
>>>>> OK, thanks - looks like another latent locale bug on Mac.  I've
>>>>> uploaded
>>>>> output comparing the old [1] and new[2] behavior WRT java.util.Locale
>>>>> under Spanish (Latin America).  It looks correct to me, based on my
>>>>> reading of Locale.toString()/getCountry()toLanguageTag().
>>>>>
>>>>> The updated webrev is here:
>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/
>>>>>
>>>>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region
>>>>> designators.  The es-419 mapping is no longer needed in locale_str.h.
>>>>>
>>>>> Thanks!
>>>>> -Brent
>>>>>
>>>>> 1.
>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt
>>>>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt
>>>>>
>>>>>> On 6/21/16 3:17 PM, Brent Christian wrote:
>>>>>>> Hi, Naoto
>>>>>>>
>>>>>>> "Spanish (Latin America)" already works the same as it did before
>>>>>>> the
>>>>>>> change - it maps to "es_XL".  Because "es-419" has more than 2
>>>>>>> characters following the '-', no change is made and
>>>>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping
>>>>>>> for
>>>>>>> "es-419" -> "es_XL" in locale_str.h.
>>>>>>>
>>>>>>> System property values are (still) set to:
>>>>>>>   user.language: es
>>>>>>>   user.country: XL
>>>>>>>   user.country.format: (2-char country code for the selected Region)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Brent
>>>>>>>
>>>>>>> On 21/06/16 14:48, Naoto Sato wrote:
>>>>>>>> Hi Brent,
>>>>>>>>
>>>>>>>> I looked at the system preference setting panel and noticed
>>>>>>>> there is
>>>>>>>> "Spanish (Latin America)", which I think uses UN M.49 code
>>>>>>>> ("es-419") as
>>>>>>>> the designate region. Can you make changes to deal with it?
>>>>>>>> (sorry I
>>>>>>>> should have noticed this earlier, and it's unfortunate not to be
>>>>>>>> able to
>>>>>>>> upcall Locale.forLanguageTag()!)
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>>
>>>>>>>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have an updated webrev at:
>>>>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>>>>>>>>
>>>>>>>>> The comments have been updated as Gerard suggested.
>>>>>>>>>
>>>>>>>>> The code to process the languageString now accounts for
>>>>>>>>> 3-character
>>>>>>>>> language codes, and 4-char script designations (line 86).
>>>>>>>>>
>>>>>>>>> More extensive testing of languages with multiple scripts/regions
>>>>>>>>> revealed that more changes were needed to maintain current
>>>>>>>>> behavior.
>>>>>>>>> Without knowing the internal workings of how
>>>>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language
>>>>>>>>> ID, I
>>>>>>>>> believe the best options are to add a few more mappings as
>>>>>>>>> needed to
>>>>>>>>> locale_aliases (locale_str.h), and to add a special case for
>>>>>>>>> Portuguese
>>>>>>>>> (line 104).
>>>>>>>>>
>>>>>>>>> OS X has 3 language options for Portuguese:
>>>>>>>>> Portugues (Portugal)
>>>>>>>>> Portugues (Brasil)
>>>>>>>>> Portugues (Brasileiro)
>>>>>>>>>
>>>>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code
>>>>>>>>> for
>>>>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
>>>>>>>>> include a region code (it's simply, "pt"), so gets mapped to the
>>>>>>>>> default
>>>>>>>>> country, Portugal.  To maintain current behavior, I added a
>>>>>>>>> special
>>>>>>>>> case
>>>>>>>>> to map "pt" to "pt_BR" when the Region system preference is set to
>>>>>>>>> Brazil.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This change introduces one notable behavior change, which I
>>>>>>>>> argue is
>>>>>>>>> actually a fix.  The bug report and test case do not list the
>>>>>>>>> "Spanish
>>>>>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it
>>>>>>>>> was
>>>>>>>>> added to the OS since the original investigation).  The old code
>>>>>>>>> mapped
>>>>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166
>>>>>>>>> country
>>>>>>>>> codes.  The new code maps to "es_MX", MX being the country code
>>>>>>>>> for
>>>>>>>>> Mexico.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I
>>>>>>>>> tried
>>>>>>>>> every language that includes multiple scripts/locales.  I also
>>>>>>>>> added a
>>>>>>>>> couple updated tests to the bug report.
>>>>>>>>>
>>>>>>>>> General testing has looked good so far.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> -Brent

From naoto.sato at oracle.com  Thu Jun 23 20:42:59 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 23 Jun 2016 13:42:59 -0700
Subject: <i18n dev> RFR 9 7131356 : (props) "No Java runtime present,
 requesting install" when creating VM from JNI [macosx]
In-Reply-To: <9da91e57-ad56-bdbf-996e-e0a1a5b7a98a@oracle.com>
References: <a0db45d8-b13a-529b-f6df-7c6d0b4d3d72@oracle.com>
	<2e01f888-972a-d77b-a8b8-a548db567595@oracle.com>
	<5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com>
	<7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com>
	<d952775c-1ac8-507b-f84a-9aa66816def5@oracle.com>
	<e000df39-c18a-3a3e-9df4-8f8bc67465b2@oracle.com>
	<41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com>
	<f7734eaf-22fb-9c34-c632-9a8368ef3be2@oracle.com>
	<be719595-1feb-03cf-a49d-ca0a60fc707e@oracle.com>
	<7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com>
	<885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com>
	<de4f426c-cf4b-50eb-f46e-e21b4e43c9d6@oracle.com>
	<c8094303-e51f-8a84-feab-cde5220f1e47@oracle.com>
	<9da91e57-ad56-bdbf-996e-e0a1a5b7a98a@oracle.com>
Message-ID: <493c3a33-0cec-22e9-1a39-5a26186ce1ca@oracle.com>

+1

 > On 23/6/16 ??10:34, Naoto Sato wrote:

I see that you tested thoroughly :-)

Naoto

On 6/23/16 1:13 PM, Brent Christian wrote:
> On 23/6/16 ??10:34, Naoto Sato wrote:
>> I reviewed webrev.04 thoroughly this time and comments below:
>>
>> - Although the OSX API returns the cases as in the spec, BCP 47 language
>> tags are case insensitive, so it would be  better to check [a-z] in line
>> 94/95 as well.
>
> Done (and I've simplified the assert code to use isalpha() and isdigit()).
>
>> - Line 82: Does the API actually returns "zh-Hans_HK"? Underscore ('_')
>> is not a part of language tags.
>
> Ah, thanks.  No, "zh-Hans_HK" is not returned by
> CFLocaleCopyPreferredLanguages().  We do see it in the default switch
> case when we call CFLocaleGetIdentifier(), which I guess was the source
> of my confusion.
>
> I've removed that comment line, and reworked the comment a little bit.
>
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.05/
>
> Thanks,
> -Brent
>
>> On 6/23/16 8:24 AM, Naoto Sato wrote:
>>> On 6/22/16 9:48 PM, Brent Christian wrote:
>>>> On 6/22/16 3:58 PM, Naoto Sato wrote:
>>>>> Hi Brent,
>>>>>
>>>>> 1. It seems that the display language in the new code seems to have
>>>>> some
>>>>> problems. I see (in es-419.txt):
>>>>>
>>>>> ---
>>>>> locale[Default|Display|Format].getLanguage () is
>>>>> user.language: it is
>>>>> ---
>>>>>
>>>>> And in fact, display strings are no longer in Spanish in the new
>>>>> version
>>>>> (as the language is "is").
>>>>
>>>> Strange - something in your local environment?  It looks right to me.
>>>
>>> Never mind. Thanks to Chrome, it was automatically converted to English
>>> :-) Funny thing was that the browser did not translate to English for
>>> es-419.old.txt...
>>>
>>>>
>>>>> 2. I think mapping language/script combination to a typical locale
>>>>> is ok
>>>>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the
>>>>> JRS,
>>>>> right?) In the meantime, I would like to have "user.script" set to
>>>>> "Latn" in such a case.
>>>>
>>>> Is this something that I could file a follow-on issue for?  The
>>>> existing
>>>> code doesn't set "user.script" in these cases, either, and it looks
>>>> like
>>>> that would take some digging into java_props_md.c...
>>>
>>> Fine by me.
>>>
>>> Naoto
>>>
>>>>
>>>> -Brent
>>>>
>>>>> On 6/22/16 2:45 PM, Brent Christian wrote:
>>>>>> On 6/21/16 3:27 PM, Naoto Sato wrote:
>>>>>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166
>>>>>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying
>>>>>>> setting is "es-419" for the preferred language, "user.country"
>>>>>>> should be
>>>>>>> "419".
>>>>>>
>>>>>> OK, thanks - looks like another latent locale bug on Mac.  I've
>>>>>> uploaded
>>>>>> output comparing the old [1] and new[2] behavior WRT java.util.Locale
>>>>>> under Spanish (Latin America).  It looks correct to me, based on my
>>>>>> reading of Locale.toString()/getCountry()toLanguageTag().
>>>>>>
>>>>>> The updated webrev is here:
>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/
>>>>>>
>>>>>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region
>>>>>> designators.  The es-419 mapping is no longer needed in locale_str.h.
>>>>>>
>>>>>> Thanks!
>>>>>> -Brent
>>>>>>
>>>>>> 1.
>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt
>>>>>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt
>>>>>>
>>>>>>> On 6/21/16 3:17 PM, Brent Christian wrote:
>>>>>>>> Hi, Naoto
>>>>>>>>
>>>>>>>> "Spanish (Latin America)" already works the same as it did before
>>>>>>>> the
>>>>>>>> change - it maps to "es_XL".  Because "es-419" has more than 2
>>>>>>>> characters following the '-', no change is made and
>>>>>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419".  I added a mapping
>>>>>>>> for
>>>>>>>> "es-419" -> "es_XL" in locale_str.h.
>>>>>>>>
>>>>>>>> System property values are (still) set to:
>>>>>>>>   user.language: es
>>>>>>>>   user.country: XL
>>>>>>>>   user.country.format: (2-char country code for the selected
>>>>>>>> Region)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Brent
>>>>>>>>
>>>>>>>> On 21/06/16 14:48, Naoto Sato wrote:
>>>>>>>>> Hi Brent,
>>>>>>>>>
>>>>>>>>> I looked at the system preference setting panel and noticed
>>>>>>>>> there is
>>>>>>>>> "Spanish (Latin America)", which I think uses UN M.49 code
>>>>>>>>> ("es-419") as
>>>>>>>>> the designate region. Can you make changes to deal with it?
>>>>>>>>> (sorry I
>>>>>>>>> should have noticed this earlier, and it's unfortunate not to be
>>>>>>>>> able to
>>>>>>>>> upcall Locale.forLanguageTag()!)
>>>>>>>>>
>>>>>>>>> Naoto
>>>>>>>>>
>>>>>>>>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have an updated webrev at:
>>>>>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
>>>>>>>>>>
>>>>>>>>>> The comments have been updated as Gerard suggested.
>>>>>>>>>>
>>>>>>>>>> The code to process the languageString now accounts for
>>>>>>>>>> 3-character
>>>>>>>>>> language codes, and 4-char script designations (line 86).
>>>>>>>>>>
>>>>>>>>>> More extensive testing of languages with multiple scripts/regions
>>>>>>>>>> revealed that more changes were needed to maintain current
>>>>>>>>>> behavior.
>>>>>>>>>> Without knowing the internal workings of how
>>>>>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language
>>>>>>>>>> ID, I
>>>>>>>>>> believe the best options are to add a few more mappings as
>>>>>>>>>> needed to
>>>>>>>>>> locale_aliases (locale_str.h), and to add a special case for
>>>>>>>>>> Portuguese
>>>>>>>>>> (line 104).
>>>>>>>>>>
>>>>>>>>>> OS X has 3 language options for Portuguese:
>>>>>>>>>> Portugues (Portugal)
>>>>>>>>>> Portugues (Brasil)
>>>>>>>>>> Portugues (Brasileiro)
>>>>>>>>>>
>>>>>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code
>>>>>>>>>> for
>>>>>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)"
>>>>>>>>>> doesn't
>>>>>>>>>> include a region code (it's simply, "pt"), so gets mapped to the
>>>>>>>>>> default
>>>>>>>>>> country, Portugal.  To maintain current behavior, I added a
>>>>>>>>>> special
>>>>>>>>>> case
>>>>>>>>>> to map "pt" to "pt_BR" when the Region system preference is
>>>>>>>>>> set to
>>>>>>>>>> Brazil.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This change introduces one notable behavior change, which I
>>>>>>>>>> argue is
>>>>>>>>>> actually a fix.  The bug report and test case do not list the
>>>>>>>>>> "Spanish
>>>>>>>>>> (Mexico)" language, but it is present on MaxOS 10.9
>>>>>>>>>> (presumably it
>>>>>>>>>> was
>>>>>>>>>> added to the OS since the original investigation).  The old code
>>>>>>>>>> mapped
>>>>>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166
>>>>>>>>>> country
>>>>>>>>>> codes.  The new code maps to "es_MX", MX being the country code
>>>>>>>>>> for
>>>>>>>>>> Mexico.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I
>>>>>>>>>> tried
>>>>>>>>>> every language that includes multiple scripts/locales.  I also
>>>>>>>>>> added a
>>>>>>>>>> couple updated tests to the bug report.
>>>>>>>>>>
>>>>>>>>>> General testing has looked good so far.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> -Brent

From rachna.goel at oracle.com  Mon Jun 27 09:46:11 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Mon, 27 Jun 2016 15:16:11 +0530
Subject: <i18n dev> Review request : JDK-8158504 -
 test/sun/util/locale/provider/Bug8038436.java fails
In-Reply-To: <b6b76e70-f855-f72b-3a78-ef59d868390a@oracle.com>
References: <b809b2d6-5bcc-ef29-ca00-f94bd3de3660@oracle.com>
	<b6b76e70-f855-f72b-3a78-ef59d868390a@oracle.com>
Message-ID: <10bf6544-9ed4-cb6e-4f19-326dcf4eaa82@oracle.com>

Hi Naoto,

Thanks for the review.
I have modified test as per suggestions.

Please have a look at :
http://cr.openjdk.java.net/~rgoel/8158504/webrev.06/

Regards,
Rachna

On 6/23/2016 9:35 PM, Naoto Sato wrote:
> Hi Rachna,
>
> The test needs to be modified to ensure locales only for ROOT and 
> en_US* locales for java.base module. Currently it would pass if 
> getAvailableLocales() included English locales other than US ones, say 
> en_GB. I should have corrected it, but apparently I overlooked.
>
> > if (nonEnglishLocales.size() > 0) {
>
> You could use !isEmpty() instead.
>
> Naoto
>
> On 6/23/16 2:09 AM, Rachna Goel wrote:
>> Hi,
>>
>> Please review fix for JDK-8158504.
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8158504
>>
>> Webrev : http://cr.openjdk.java.net/~nishjain/rgoel/8158504/webrev.03/
>>
>> Fix : Removed java.ext.dirs System property as it is no longer supported
>> in JDK9 and used "-limitmods java.base"  to load only java.base.
>>         (To hide jdk.localedata module).
>>         JRE is COMPAT in JDK9.
>>         outputted some useful information if test fails somewhere.
>>

-- 
Thanks,
Rachna


From naoto.sato at oracle.com  Mon Jun 27 17:12:03 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 27 Jun 2016 10:12:03 -0700
Subject: <i18n dev> Review request : JDK-8158504 -
 test/sun/util/locale/provider/Bug8038436.java fails
In-Reply-To: <10bf6544-9ed4-cb6e-4f19-326dcf4eaa82@oracle.com>
References: <b809b2d6-5bcc-ef29-ca00-f94bd3de3660@oracle.com>
	<b6b76e70-f855-f72b-3a78-ef59d868390a@oracle.com>
	<10bf6544-9ed4-cb6e-4f19-326dcf4eaa82@oracle.com>
Message-ID: <95cfaaf3-6d26-4f2f-3dad-bed92ce85788@oracle.com>

I'd wrap long lines, others look good to me.

Naoto

On 6/27/16 2:46 AM, Rachna Goel wrote:
> Hi Naoto,
>
> Thanks for the review.
> I have modified test as per suggestions.
>
> Please have a look at :
> http://cr.openjdk.java.net/~rgoel/8158504/webrev.06/
>
> Regards,
> Rachna
>
> On 6/23/2016 9:35 PM, Naoto Sato wrote:
>> Hi Rachna,
>>
>> The test needs to be modified to ensure locales only for ROOT and
>> en_US* locales for java.base module. Currently it would pass if
>> getAvailableLocales() included English locales other than US ones, say
>> en_GB. I should have corrected it, but apparently I overlooked.
>>
>> > if (nonEnglishLocales.size() > 0) {
>>
>> You could use !isEmpty() instead.
>>
>> Naoto
>>
>> On 6/23/16 2:09 AM, Rachna Goel wrote:
>>> Hi,
>>>
>>> Please review fix for JDK-8158504.
>>>
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8158504
>>>
>>> Webrev : http://cr.openjdk.java.net/~nishjain/rgoel/8158504/webrev.03/
>>>
>>> Fix : Removed java.ext.dirs System property as it is no longer supported
>>> in JDK9 and used "-limitmods java.base"  to load only java.base.
>>>         (To hide jdk.localedata module).
>>>         JRE is COMPAT in JDK9.
>>>         outputted some useful information if test fails somewhere.
>>>
>

From masayoshi.okutsu at oracle.com  Mon Jun 27 22:53:29 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 28 Jun 2016 07:53:29 +0900
Subject: <i18n dev> Review request : JDK-8158504 -
 test/sun/util/locale/provider/Bug8038436.java fails
In-Reply-To: <95cfaaf3-6d26-4f2f-3dad-bed92ce85788@oracle.com>
References: <b809b2d6-5bcc-ef29-ca00-f94bd3de3660@oracle.com>
	<b6b76e70-f855-f72b-3a78-ef59d868390a@oracle.com>
	<10bf6544-9ed4-cb6e-4f19-326dcf4eaa82@oracle.com>
	<95cfaaf3-6d26-4f2f-3dad-bed92ce85788@oracle.com>
Message-ID: <de70674a-d1ff-d84f-30ea-34e938e16d92@oracle.com>

+1

Masayoshi


On 6/28/2016 2:12 AM, Naoto Sato wrote:
> I'd wrap long lines, others look good to me.
>
> Naoto
>
> On 6/27/16 2:46 AM, Rachna Goel wrote:
>> Hi Naoto,
>>
>> Thanks for the review.
>> I have modified test as per suggestions.
>>
>> Please have a look at :
>> http://cr.openjdk.java.net/~rgoel/8158504/webrev.06/
>>
>> Regards,
>> Rachna
>>
>> On 6/23/2016 9:35 PM, Naoto Sato wrote:
>>> Hi Rachna,
>>>
>>> The test needs to be modified to ensure locales only for ROOT and
>>> en_US* locales for java.base module. Currently it would pass if
>>> getAvailableLocales() included English locales other than US ones, say
>>> en_GB. I should have corrected it, but apparently I overlooked.
>>>
>>> > if (nonEnglishLocales.size() > 0) {
>>>
>>> You could use !isEmpty() instead.
>>>
>>> Naoto
>>>
>>> On 6/23/16 2:09 AM, Rachna Goel wrote:
>>>> Hi,
>>>>
>>>> Please review fix for JDK-8158504.
>>>>
>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8158504
>>>>
>>>> Webrev : http://cr.openjdk.java.net/~nishjain/rgoel/8158504/webrev.03/
>>>>
>>>> Fix : Removed java.ext.dirs System property as it is no longer 
>>>> supported
>>>> in JDK9 and used "-limitmods java.base"  to load only java.base.
>>>>         (To hide jdk.localedata module).
>>>>         JRE is COMPAT in JDK9.
>>>>         outputted some useful information if test fails somewhere.
>>>>
>>


From yuka.kamiya at oracle.com  Thu Jun 30 07:07:05 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Thu, 30 Jun 2016 16:07:05 +0900
Subject: <i18n dev> RFR: JDK-7090039: Wrong link in comment of
 java.text.DateFormatSymbols
Message-ID: <87d7e89b-139e-dbde-5c72-f28509f8c341@oracle.com>

Hi,

Please review a simple doc fix.

https://bugs.openjdk.java.net/browse/JDK-7090039

--- a/src/java.base/share/classes/java/text/DateFormatSymbols.java
+++ b/src/java.base/share/classes/java/text/DateFormatSymbols.java
@@ -221,7 +221,7 @@
       * The zone ID is <em>not</em> localized; it's one of the valid IDs of
       * the {@link java.util.TimeZone TimeZone} class that are not
-     * <a href="../java/util/TimeZone.html#CustomID">custom IDs</a>.
+     * <a href="../util/TimeZone.html#CustomID">custom IDs</a>.
       * All other entries are localized names.


Thanks,
--
Yuka

From masayoshi.okutsu at oracle.com  Thu Jun 30 07:37:35 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 30 Jun 2016 16:37:35 +0900
Subject: <i18n dev> RFR: JDK-7090039: Wrong link in comment of
 java.text.DateFormatSymbols
In-Reply-To: <87d7e89b-139e-dbde-5c72-f28509f8c341@oracle.com>
References: <87d7e89b-139e-dbde-5c72-f28509f8c341@oracle.com>
Message-ID: <13445c7a-93fb-c32f-8eb1-5ac58cb871fd@oracle.com>

Looks good.

Masayoshi


On 6/30/2016 4:07 PM, Yuka Kamiya wrote:
> Hi,
>
> Please review a simple doc fix.
>
> https://bugs.openjdk.java.net/browse/JDK-7090039
>
> --- a/src/java.base/share/classes/java/text/DateFormatSymbols.java
> +++ b/src/java.base/share/classes/java/text/DateFormatSymbols.java
> @@ -221,7 +221,7 @@
>       * The zone ID is <em>not</em> localized; it's one of the valid 
> IDs of
>       * the {@link java.util.TimeZone TimeZone} class that are not
> -     * <a href="../java/util/TimeZone.html#CustomID">custom IDs</a>.
> +     * <a href="../util/TimeZone.html#CustomID">custom IDs</a>.
>       * All other entries are localized names.
>
>
> Thanks,
> -- 
> Yuka