From masayoshi.okutsu at oracle.com  Thu Dec  1 00:00:00 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 1 Dec 2016 09:00:00 +0900
Subject: <i18n dev> CFV: New Internationalization Group Lead: Naoto Sato
Message-ID: <e5286079-bc73-5048-d3fd-a76a61c6d451@oracle.com>

I hereby nominate Naoto Sato to Internationalization Group Lead [1].

Naoto had been the lead of the Internationalization group until he left 
the team in April this year.

Votes are due by 2016-12-14T00:00:00Z.

Only the current Members of the Internationalization Group [2] are 
eligible to vote on this nomination.  Votes must be cast in the open by 
replying to this mailing list.

For Simple Majority voting instructions, see [3].

Masayoshi Okutsu

[1]: http://openjdk.java.net/bylaws#group-lead
[2]: http://openjdk.java.net/census#i18n
[3]: http://openjdk.java.net/groups#lead-vote


From naoto.sato at oracle.com  Thu Dec  1 16:59:55 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 1 Dec 2016 08:59:55 -0800
Subject: <i18n dev> Request for Review : JDK-8071929
 -Locale.getISOCountries() has inconsistent behaviour for "AN",
 "BU" and "CS" country codes.
In-Reply-To: <31fbe667-8ca5-ab9d-617a-5cd100848d41@oracle.com>
References: <27108efc-2ff4-368a-8fc6-c8ded5689a45@oracle.com>
	<CACzrW9By4kcALojo_-VowJ0640fpwQe0HzNsXAREkvaqiGm0HA@mail.gmail.com>
	<dc76bfcc-1dd4-6216-e528-e63d1a7926f0@oracle.com>
	<CACzrW9A2zcZ1Z6X_Avs3R0_OOSy1SWqOkD3KgjdPGH4MEet0rw@mail.gmail.com>
	<31fbe667-8ca5-ab9d-617a-5cd100848d41@oracle.com>
Message-ID: <22d9255a-d6f7-4dd9-eb92-1188c8286113@oracle.com>

I think what we can improve here is to add extra descriptions to each 
enum constant. You can refer to the definitions to each country code 
sets at the ISO site [1]. That clarification can be done with a separate 
JBS issue.

Naoto

[1]: 
http://www.iso.org/iso/home/standards/country_codes/country_codes_glossary.htm

On 11/30/16 7:33 AM, Rachna Goel wrote:
>  Hi Stephen,
>
> Please find my comments inlined.
>
> On 30/11/16 5:07 PM, Stephen Colebourne wrote:
>> The ISO-3166-3 code is of a complex form and not widely used as far as
>> I know. As far as I can tell, it is not legal to create a Locale
>> instance using the ISO-3166-3 code as the country.
> Yes, Agreed..API doc of Locale constructors mentions that, which type of
> country codes are valid input.
>> At the very least, the PART3 constant should describe the meaning and
>> structure of the codes.
> I think, API doc of getISOCountries() to be updated mentions that :
>
>
> * ISO3166-3 codes which designate country codes for those obsolete codes,
>      * can be retrieved from {@link
> #getISOCountries(Locale.IsoCountryCode type)} with
>       * {@code type}  {@link IsoCountryCode#PART3}.
>>
>> What might be useful would be a much more detailed result, where a
>> user could lookup an old code and find out when it expired, and what
>> replaced it.
> I think that again depends on applications requirements.
> For this new method may need to be added, may be handled under separate
> JBS entry.
>> Stephen
>>
>>
>> On 30 November 2016 at 09:31, Rachna Goel <rachna.goel at oracle.com> wrote:
>>> Hi Stephen,
>>>
>>> Thanks a lot for the review.
>>>
>>> On 30/11/16 3:15 AM, Stephen Colebourne wrote:
>>>
>>> I'm concerned that this is not the friendliest of new APIs. There is
>>> little description of the meaning of the ISO-3166 parts - what is
>>> being added is directly exposing the underlying data rather than
>>> providing any kind of abstraction.
>>>
>>> Could you throw more light on this? Country code data is already
>>> encapsulated, and there is no direct reference to map accessing those
>>> data.
>>> If you have some suggestions on improving it, kindly share.
>>>
>>> There is also an inconsistency between "ISO" and "Iso" in the
>>> class/method
>>> names.
>>>
>>> There has been lot of discussion regarding "ISO" and "Iso". CCC has
>>> suggested use of "IsoCountryCode" for enum name which I proposed to be
>>> "ISOCountrycode" .
>>>
>>> I have tried to keep constants as "ISO", variables as "iso" as per
>>> with JDK
>>> naming conventions. But Locale class has methods names with  "ISO", So I
>>> think I will update all internal method names to have "ISO".
>>>
>>> Thanks,
>>> Rachna
>>>
>>>
>>> Stephen
>>>
>>>
>>> On 29 November 2016 at 09:07, Rachna Goel <rachna.goel at oracle.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please review fix for JDK-8071929.
>>>
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8071929
>>>
>>> patch : http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.02/
>>>
>>> Fix is to remove obsolete country code "AN" and provide support for
>>> retrieving of ISO3166-1 alpha-2,  ISO3166-1 alpha-3, ISO3166-3 country
>>> codes.
>>>
>>> Thanks,
>>> Rachna
>>>
>>>
>

From naoto.sato at oracle.com  Thu Dec  1 21:02:41 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 1 Dec 2016 13:02:41 -0800
Subject: <i18n dev> RFR: 7037368: Currency names missing in some locales
In-Reply-To: <0d1d973e-3dce-d7fe-3fa7-f8e30f640ba3@oracle.com>
References: <0d1d973e-3dce-d7fe-3fa7-f8e30f640ba3@oracle.com>
Message-ID: <2f557246-5c96-4ef2-a5c1-b46c9f622045@oracle.com>

Looks OK to me, Leo.

Naoto

On 11/30/16 8:16 AM, Leo Jiang wrote:
> Hi,
>
> Please review
> http://cr.openjdk.java.net/~ljiang/7037368/
>
> for bug
> https://bugs.openjdk.java.net/browse/JDK-7037368
>
> I checked the currency names listed in the bug description, and got the
> fix according to CLDR data.
>
> Thanks,
> Leo

From rachna.goel at oracle.com  Fri Dec  2 10:35:29 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 2 Dec 2016 16:05:29 +0530
Subject: <i18n dev> Request for Review : JDK-8071929
 -Locale.getISOCountries() has inconsistent behaviour for "AN",
 "BU" and "CS" country codes.
In-Reply-To: <22d9255a-d6f7-4dd9-eb92-1188c8286113@oracle.com>
References: <27108efc-2ff4-368a-8fc6-c8ded5689a45@oracle.com>
	<CACzrW9By4kcALojo_-VowJ0640fpwQe0HzNsXAREkvaqiGm0HA@mail.gmail.com>
	<dc76bfcc-1dd4-6216-e528-e63d1a7926f0@oracle.com>
	<CACzrW9A2zcZ1Z6X_Avs3R0_OOSy1SWqOkD3KgjdPGH4MEet0rw@mail.gmail.com>
	<31fbe667-8ca5-ab9d-617a-5cd100848d41@oracle.com>
	<22d9255a-d6f7-4dd9-eb92-1188c8286113@oracle.com>
Message-ID: <fe4f5b9a-7da9-c92a-ce7d-471a6124fed9@oracle.com>

Hi Stephen, Masayoshi,

Thanks for review and suggestions.

Please have a look at updated patch on this issue.

http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.03/index.html

Updations in new patch:

1. Updated all method names to have "ISO".

2. Changed implementation of mapping function to be inside enum so that 
default case can be avoided, as suggested by Masayoshi.

As suggested from Naoto, adding extra descriptions and clarifications 
can be handled with a separate JBS issue.

Thanks,
Rachna



On 01/12/16 10:29 PM, Naoto Sato wrote:
> I think what we can improve here is to add extra descriptions to each 
> enum constant. You can refer to the definitions to each country code 
> sets at the ISO site [1]. That clarification can be done with a 
> separate JBS issue.
>
> Naoto
>
> [1]: 
> http://www.iso.org/iso/home/standards/country_codes/country_codes_glossary.htm
>
> On 11/30/16 7:33 AM, Rachna Goel wrote:
>>  Hi Stephen,
>>
>> Please find my comments inlined.
>>
>> On 30/11/16 5:07 PM, Stephen Colebourne wrote:
>>> The ISO-3166-3 code is of a complex form and not widely used as far as
>>> I know. As far as I can tell, it is not legal to create a Locale
>>> instance using the ISO-3166-3 code as the country.
>> Yes, Agreed..API doc of Locale constructors mentions that, which type of
>> country codes are valid input.
>>> At the very least, the PART3 constant should describe the meaning and
>>> structure of the codes.
>> I think, API doc of getISOCountries() to be updated mentions that :
>>
>>
>> * ISO3166-3 codes which designate country codes for those obsolete 
>> codes,
>>      * can be retrieved from {@link
>> #getISOCountries(Locale.IsoCountryCode type)} with
>>       * {@code type}  {@link IsoCountryCode#PART3}.
>>>
>>> What might be useful would be a much more detailed result, where a
>>> user could lookup an old code and find out when it expired, and what
>>> replaced it.
>> I think that again depends on applications requirements.
>> For this new method may need to be added, may be handled under separate
>> JBS entry.
>>> Stephen
>>>
>>>
>>> On 30 November 2016 at 09:31, Rachna Goel <rachna.goel at oracle.com> 
>>> wrote:
>>>> Hi Stephen,
>>>>
>>>> Thanks a lot for the review.
>>>>
>>>> On 30/11/16 3:15 AM, Stephen Colebourne wrote:
>>>>
>>>> I'm concerned that this is not the friendliest of new APIs. There is
>>>> little description of the meaning of the ISO-3166 parts - what is
>>>> being added is directly exposing the underlying data rather than
>>>> providing any kind of abstraction.
>>>>
>>>> Could you throw more light on this? Country code data is already
>>>> encapsulated, and there is no direct reference to map accessing those
>>>> data.
>>>> If you have some suggestions on improving it, kindly share.
>>>>
>>>> There is also an inconsistency between "ISO" and "Iso" in the
>>>> class/method
>>>> names.
>>>>
>>>> There has been lot of discussion regarding "ISO" and "Iso". CCC has
>>>> suggested use of "IsoCountryCode" for enum name which I proposed to be
>>>> "ISOCountrycode" .
>>>>
>>>> I have tried to keep constants as "ISO", variables as "iso" as per
>>>> with JDK
>>>> naming conventions. But Locale class has methods names with "ISO", 
>>>> So I
>>>> think I will update all internal method names to have "ISO".
>>>>
>>>> Thanks,
>>>> Rachna
>>>>
>>>>
>>>> Stephen
>>>>
>>>>
>>>> On 29 November 2016 at 09:07, Rachna Goel <rachna.goel at oracle.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review fix for JDK-8071929.
>>>>
>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8071929
>>>>
>>>> patch : http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.02/
>>>>
>>>> Fix is to remove obsolete country code "AN" and provide support for
>>>> retrieving of ISO3166-1 alpha-2,  ISO3166-1 alpha-3, ISO3166-3 country
>>>> codes.
>>>>
>>>> Thanks,
>>>> Rachna
>>>>
>>>>
>>


From naoto.sato at oracle.com  Mon Dec  5 23:17:32 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 5 Dec 2016 15:17:32 -0800
Subject: <i18n dev> Request for Review : JDK-8071929
 -Locale.getISOCountries() has inconsistent behaviour for "AN",
 "BU" and "CS" country codes.
In-Reply-To: <fe4f5b9a-7da9-c92a-ce7d-471a6124fed9@oracle.com>
References: <27108efc-2ff4-368a-8fc6-c8ded5689a45@oracle.com>
	<CACzrW9By4kcALojo_-VowJ0640fpwQe0HzNsXAREkvaqiGm0HA@mail.gmail.com>
	<dc76bfcc-1dd4-6216-e528-e63d1a7926f0@oracle.com>
	<CACzrW9A2zcZ1Z6X_Avs3R0_OOSy1SWqOkD3KgjdPGH4MEet0rw@mail.gmail.com>
	<31fbe667-8ca5-ab9d-617a-5cd100848d41@oracle.com>
	<22d9255a-d6f7-4dd9-eb92-1188c8286113@oracle.com>
	<fe4f5b9a-7da9-c92a-ce7d-471a6124fed9@oracle.com>
Message-ID: <3a62fd19-114b-f5ee-7ec4-b11e6540cb5b@oracle.com>

Additional nit comments:

Locale.java

- Extra blank lines at line 628, 639.

- The method name "getISOCountriesImpl" inside IsoCountryCode is 
somewhat strange. How about just "createCountryCodeSet()"? Also, its 
comment does not describe the method correctly. It does not seem a 
"mapping function".

Naoto

On 12/2/16 2:35 AM, Rachna Goel wrote:
> Hi Stephen, Masayoshi,
>
> Thanks for review and suggestions.
>
> Please have a look at updated patch on this issue.
>
> http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.03/index.html
>
> Updations in new patch:
>
> 1. Updated all method names to have "ISO".
>
> 2. Changed implementation of mapping function to be inside enum so that
> default case can be avoided, as suggested by Masayoshi.
>
> As suggested from Naoto, adding extra descriptions and clarifications
> can be handled with a separate JBS issue.
>
> Thanks,
> Rachna
>
>
>
> On 01/12/16 10:29 PM, Naoto Sato wrote:
>> I think what we can improve here is to add extra descriptions to each
>> enum constant. You can refer to the definitions to each country code
>> sets at the ISO site [1]. That clarification can be done with a
>> separate JBS issue.
>>
>> Naoto
>>
>> [1]:
>> http://www.iso.org/iso/home/standards/country_codes/country_codes_glossary.htm
>>
>> On 11/30/16 7:33 AM, Rachna Goel wrote:
>>>  Hi Stephen,
>>>
>>> Please find my comments inlined.
>>>
>>> On 30/11/16 5:07 PM, Stephen Colebourne wrote:
>>>> The ISO-3166-3 code is of a complex form and not widely used as far as
>>>> I know. As far as I can tell, it is not legal to create a Locale
>>>> instance using the ISO-3166-3 code as the country.
>>> Yes, Agreed..API doc of Locale constructors mentions that, which type of
>>> country codes are valid input.
>>>> At the very least, the PART3 constant should describe the meaning and
>>>> structure of the codes.
>>> I think, API doc of getISOCountries() to be updated mentions that :
>>>
>>>
>>> * ISO3166-3 codes which designate country codes for those obsolete
>>> codes,
>>>      * can be retrieved from {@link
>>> #getISOCountries(Locale.IsoCountryCode type)} with
>>>       * {@code type}  {@link IsoCountryCode#PART3}.
>>>>
>>>> What might be useful would be a much more detailed result, where a
>>>> user could lookup an old code and find out when it expired, and what
>>>> replaced it.
>>> I think that again depends on applications requirements.
>>> For this new method may need to be added, may be handled under separate
>>> JBS entry.
>>>> Stephen
>>>>
>>>>
>>>> On 30 November 2016 at 09:31, Rachna Goel <rachna.goel at oracle.com>
>>>> wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> Thanks a lot for the review.
>>>>>
>>>>> On 30/11/16 3:15 AM, Stephen Colebourne wrote:
>>>>>
>>>>> I'm concerned that this is not the friendliest of new APIs. There is
>>>>> little description of the meaning of the ISO-3166 parts - what is
>>>>> being added is directly exposing the underlying data rather than
>>>>> providing any kind of abstraction.
>>>>>
>>>>> Could you throw more light on this? Country code data is already
>>>>> encapsulated, and there is no direct reference to map accessing those
>>>>> data.
>>>>> If you have some suggestions on improving it, kindly share.
>>>>>
>>>>> There is also an inconsistency between "ISO" and "Iso" in the
>>>>> class/method
>>>>> names.
>>>>>
>>>>> There has been lot of discussion regarding "ISO" and "Iso". CCC has
>>>>> suggested use of "IsoCountryCode" for enum name which I proposed to be
>>>>> "ISOCountrycode" .
>>>>>
>>>>> I have tried to keep constants as "ISO", variables as "iso" as per
>>>>> with JDK
>>>>> naming conventions. But Locale class has methods names with  "ISO",
>>>>> So I
>>>>> think I will update all internal method names to have "ISO".
>>>>>
>>>>> Thanks,
>>>>> Rachna
>>>>>
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>> On 29 November 2016 at 09:07, Rachna Goel <rachna.goel at oracle.com>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please review fix for JDK-8071929.
>>>>>
>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8071929
>>>>>
>>>>> patch : http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.02/
>>>>>
>>>>> Fix is to remove obsolete country code "AN" and provide support for
>>>>> retrieving of ISO3166-1 alpha-2,  ISO3166-1 alpha-3, ISO3166-3 country
>>>>> codes.
>>>>>
>>>>> Thanks,
>>>>> Rachna
>>>>>
>>>>>
>>>
>

From rachna.goel at oracle.com  Tue Dec  6 06:56:05 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Tue, 6 Dec 2016 12:26:05 +0530
Subject: <i18n dev> Request for Review : JDK-8071929
 -Locale.getISOCountries() has inconsistent behaviour for "AN",
 "BU" and "CS" country codes.
In-Reply-To: <3a62fd19-114b-f5ee-7ec4-b11e6540cb5b@oracle.com>
References: <27108efc-2ff4-368a-8fc6-c8ded5689a45@oracle.com>
	<CACzrW9By4kcALojo_-VowJ0640fpwQe0HzNsXAREkvaqiGm0HA@mail.gmail.com>
	<dc76bfcc-1dd4-6216-e528-e63d1a7926f0@oracle.com>
	<CACzrW9A2zcZ1Z6X_Avs3R0_OOSy1SWqOkD3KgjdPGH4MEet0rw@mail.gmail.com>
	<31fbe667-8ca5-ab9d-617a-5cd100848d41@oracle.com>
	<22d9255a-d6f7-4dd9-eb92-1188c8286113@oracle.com>
	<fe4f5b9a-7da9-c92a-ce7d-471a6124fed9@oracle.com>
	<3a62fd19-114b-f5ee-7ec4-b11e6540cb5b@oracle.com>
Message-ID: <7391c7e4-d4d7-a2e4-4c60-72036ccdf2d5@oracle.com>

Hi Naoto,

Thanks for suggestions.

updated patch is at :

http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.04/

Thanks,
Rachna

On 06/12/16 4:47 AM, Naoto Sato wrote:
> Additional nit comments:
>
> Locale.java
>
> - Extra blank lines at line 628, 639.
>
> - The method name "getISOCountriesImpl" inside IsoCountryCode is 
> somewhat strange. How about just "createCountryCodeSet()"? Also, its 
> comment does not describe the method correctly. It does not seem a 
> "mapping function".
>
> Naoto
>
> On 12/2/16 2:35 AM, Rachna Goel wrote:
>> Hi Stephen, Masayoshi,
>>
>> Thanks for review and suggestions.
>>
>> Please have a look at updated patch on this issue.
>>
>> http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.03/index.html
>>
>> Updations in new patch:
>>
>> 1. Updated all method names to have "ISO".
>>
>> 2. Changed implementation of mapping function to be inside enum so that
>> default case can be avoided, as suggested by Masayoshi.
>>
>> As suggested from Naoto, adding extra descriptions and clarifications
>> can be handled with a separate JBS issue.
>>
>> Thanks,
>> Rachna
>>
>>
>>
>> On 01/12/16 10:29 PM, Naoto Sato wrote:
>>> I think what we can improve here is to add extra descriptions to each
>>> enum constant. You can refer to the definitions to each country code
>>> sets at the ISO site [1]. That clarification can be done with a
>>> separate JBS issue.
>>>
>>> Naoto
>>>
>>> [1]:
>>> http://www.iso.org/iso/home/standards/country_codes/country_codes_glossary.htm 
>>>
>>>
>>> On 11/30/16 7:33 AM, Rachna Goel wrote:
>>>>  Hi Stephen,
>>>>
>>>> Please find my comments inlined.
>>>>
>>>> On 30/11/16 5:07 PM, Stephen Colebourne wrote:
>>>>> The ISO-3166-3 code is of a complex form and not widely used as 
>>>>> far as
>>>>> I know. As far as I can tell, it is not legal to create a Locale
>>>>> instance using the ISO-3166-3 code as the country.
>>>> Yes, Agreed..API doc of Locale constructors mentions that, which 
>>>> type of
>>>> country codes are valid input.
>>>>> At the very least, the PART3 constant should describe the meaning and
>>>>> structure of the codes.
>>>> I think, API doc of getISOCountries() to be updated mentions that :
>>>>
>>>>
>>>> * ISO3166-3 codes which designate country codes for those obsolete
>>>> codes,
>>>>      * can be retrieved from {@link
>>>> #getISOCountries(Locale.IsoCountryCode type)} with
>>>>       * {@code type}  {@link IsoCountryCode#PART3}.
>>>>>
>>>>> What might be useful would be a much more detailed result, where a
>>>>> user could lookup an old code and find out when it expired, and what
>>>>> replaced it.
>>>> I think that again depends on applications requirements.
>>>> For this new method may need to be added, may be handled under 
>>>> separate
>>>> JBS entry.
>>>>> Stephen
>>>>>
>>>>>
>>>>> On 30 November 2016 at 09:31, Rachna Goel <rachna.goel at oracle.com>
>>>>> wrote:
>>>>>> Hi Stephen,
>>>>>>
>>>>>> Thanks a lot for the review.
>>>>>>
>>>>>> On 30/11/16 3:15 AM, Stephen Colebourne wrote:
>>>>>>
>>>>>> I'm concerned that this is not the friendliest of new APIs. There is
>>>>>> little description of the meaning of the ISO-3166 parts - what is
>>>>>> being added is directly exposing the underlying data rather than
>>>>>> providing any kind of abstraction.
>>>>>>
>>>>>> Could you throw more light on this? Country code data is already
>>>>>> encapsulated, and there is no direct reference to map accessing 
>>>>>> those
>>>>>> data.
>>>>>> If you have some suggestions on improving it, kindly share.
>>>>>>
>>>>>> There is also an inconsistency between "ISO" and "Iso" in the
>>>>>> class/method
>>>>>> names.
>>>>>>
>>>>>> There has been lot of discussion regarding "ISO" and "Iso". CCC has
>>>>>> suggested use of "IsoCountryCode" for enum name which I proposed 
>>>>>> to be
>>>>>> "ISOCountrycode" .
>>>>>>
>>>>>> I have tried to keep constants as "ISO", variables as "iso" as per
>>>>>> with JDK
>>>>>> naming conventions. But Locale class has methods names with  "ISO",
>>>>>> So I
>>>>>> think I will update all internal method names to have "ISO".
>>>>>>
>>>>>> Thanks,
>>>>>> Rachna
>>>>>>
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On 29 November 2016 at 09:07, Rachna Goel <rachna.goel at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please review fix for JDK-8071929.
>>>>>>
>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8071929
>>>>>>
>>>>>> patch : http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.02/
>>>>>>
>>>>>> Fix is to remove obsolete country code "AN" and provide support for
>>>>>> retrieving of ISO3166-1 alpha-2,  ISO3166-1 alpha-3, ISO3166-3 
>>>>>> country
>>>>>> codes.
>>>>>>
>>>>>> Thanks,
>>>>>> Rachna
>>>>>>
>>>>>>
>>>>
>>


From naoto.sato at oracle.com  Tue Dec  6 18:04:05 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 6 Dec 2016 10:04:05 -0800
Subject: <i18n dev> Request for Review : JDK-8071929
 -Locale.getISOCountries() has inconsistent behaviour for "AN",
 "BU" and "CS" country codes.
In-Reply-To: <7391c7e4-d4d7-a2e4-4c60-72036ccdf2d5@oracle.com>
References: <27108efc-2ff4-368a-8fc6-c8ded5689a45@oracle.com>
	<CACzrW9By4kcALojo_-VowJ0640fpwQe0HzNsXAREkvaqiGm0HA@mail.gmail.com>
	<dc76bfcc-1dd4-6216-e528-e63d1a7926f0@oracle.com>
	<CACzrW9A2zcZ1Z6X_Avs3R0_OOSy1SWqOkD3KgjdPGH4MEet0rw@mail.gmail.com>
	<31fbe667-8ca5-ab9d-617a-5cd100848d41@oracle.com>
	<22d9255a-d6f7-4dd9-eb92-1188c8286113@oracle.com>
	<fe4f5b9a-7da9-c92a-ce7d-471a6124fed9@oracle.com>
	<3a62fd19-114b-f5ee-7ec4-b11e6540cb5b@oracle.com>
	<7391c7e4-d4d7-a2e4-4c60-72036ccdf2d5@oracle.com>
Message-ID: <d229c758-3393-238a-1a15-be0596e4bc7c@oracle.com>

Looks good to me. The map could be implemented using EnumMap with 
Collections.synchronizedMap, but I am not sure that would make any 
significant improvement in this particular case.

Naoto

On 12/5/16 10:56 PM, Rachna Goel wrote:
> Hi Naoto,
>
> Thanks for suggestions.
>
> updated patch is at :
>
> http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.04/
>
> Thanks,
> Rachna
>
> On 06/12/16 4:47 AM, Naoto Sato wrote:
>> Additional nit comments:
>>
>> Locale.java
>>
>> - Extra blank lines at line 628, 639.
>>
>> - The method name "getISOCountriesImpl" inside IsoCountryCode is
>> somewhat strange. How about just "createCountryCodeSet()"? Also, its
>> comment does not describe the method correctly. It does not seem a
>> "mapping function".
>>
>> Naoto
>>
>> On 12/2/16 2:35 AM, Rachna Goel wrote:
>>> Hi Stephen, Masayoshi,
>>>
>>> Thanks for review and suggestions.
>>>
>>> Please have a look at updated patch on this issue.
>>>
>>> http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.03/index.html
>>>
>>> Updations in new patch:
>>>
>>> 1. Updated all method names to have "ISO".
>>>
>>> 2. Changed implementation of mapping function to be inside enum so that
>>> default case can be avoided, as suggested by Masayoshi.
>>>
>>> As suggested from Naoto, adding extra descriptions and clarifications
>>> can be handled with a separate JBS issue.
>>>
>>> Thanks,
>>> Rachna
>>>
>>>
>>>
>>> On 01/12/16 10:29 PM, Naoto Sato wrote:
>>>> I think what we can improve here is to add extra descriptions to each
>>>> enum constant. You can refer to the definitions to each country code
>>>> sets at the ISO site [1]. That clarification can be done with a
>>>> separate JBS issue.
>>>>
>>>> Naoto
>>>>
>>>> [1]:
>>>> http://www.iso.org/iso/home/standards/country_codes/country_codes_glossary.htm
>>>>
>>>>
>>>> On 11/30/16 7:33 AM, Rachna Goel wrote:
>>>>>  Hi Stephen,
>>>>>
>>>>> Please find my comments inlined.
>>>>>
>>>>> On 30/11/16 5:07 PM, Stephen Colebourne wrote:
>>>>>> The ISO-3166-3 code is of a complex form and not widely used as
>>>>>> far as
>>>>>> I know. As far as I can tell, it is not legal to create a Locale
>>>>>> instance using the ISO-3166-3 code as the country.
>>>>> Yes, Agreed..API doc of Locale constructors mentions that, which
>>>>> type of
>>>>> country codes are valid input.
>>>>>> At the very least, the PART3 constant should describe the meaning and
>>>>>> structure of the codes.
>>>>> I think, API doc of getISOCountries() to be updated mentions that :
>>>>>
>>>>>
>>>>> * ISO3166-3 codes which designate country codes for those obsolete
>>>>> codes,
>>>>>      * can be retrieved from {@link
>>>>> #getISOCountries(Locale.IsoCountryCode type)} with
>>>>>       * {@code type}  {@link IsoCountryCode#PART3}.
>>>>>>
>>>>>> What might be useful would be a much more detailed result, where a
>>>>>> user could lookup an old code and find out when it expired, and what
>>>>>> replaced it.
>>>>> I think that again depends on applications requirements.
>>>>> For this new method may need to be added, may be handled under
>>>>> separate
>>>>> JBS entry.
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On 30 November 2016 at 09:31, Rachna Goel <rachna.goel at oracle.com>
>>>>>> wrote:
>>>>>>> Hi Stephen,
>>>>>>>
>>>>>>> Thanks a lot for the review.
>>>>>>>
>>>>>>> On 30/11/16 3:15 AM, Stephen Colebourne wrote:
>>>>>>>
>>>>>>> I'm concerned that this is not the friendliest of new APIs. There is
>>>>>>> little description of the meaning of the ISO-3166 parts - what is
>>>>>>> being added is directly exposing the underlying data rather than
>>>>>>> providing any kind of abstraction.
>>>>>>>
>>>>>>> Could you throw more light on this? Country code data is already
>>>>>>> encapsulated, and there is no direct reference to map accessing
>>>>>>> those
>>>>>>> data.
>>>>>>> If you have some suggestions on improving it, kindly share.
>>>>>>>
>>>>>>> There is also an inconsistency between "ISO" and "Iso" in the
>>>>>>> class/method
>>>>>>> names.
>>>>>>>
>>>>>>> There has been lot of discussion regarding "ISO" and "Iso". CCC has
>>>>>>> suggested use of "IsoCountryCode" for enum name which I proposed
>>>>>>> to be
>>>>>>> "ISOCountrycode" .
>>>>>>>
>>>>>>> I have tried to keep constants as "ISO", variables as "iso" as per
>>>>>>> with JDK
>>>>>>> naming conventions. But Locale class has methods names with  "ISO",
>>>>>>> So I
>>>>>>> think I will update all internal method names to have "ISO".
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rachna
>>>>>>>
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>>
>>>>>>> On 29 November 2016 at 09:07, Rachna Goel <rachna.goel at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review fix for JDK-8071929.
>>>>>>>
>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8071929
>>>>>>>
>>>>>>> patch : http://cr.openjdk.java.net/~rgoel/JDK_8071929/webrev.02/
>>>>>>>
>>>>>>> Fix is to remove obsolete country code "AN" and provide support for
>>>>>>> retrieving of ISO3166-1 alpha-2,  ISO3166-1 alpha-3, ISO3166-3
>>>>>>> country
>>>>>>> codes.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rachna
>>>>>>>
>>>>>>>
>>>>>
>>>
>

From rachna.goel at oracle.com  Wed Dec  7 12:03:00 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Wed, 7 Dec 2016 17:33:00 +0530
Subject: <i18n dev> RFR : JDK-8170840 : java/util/Locale/LocaleTest.java
	failed
Message-ID: <a225753c-37cd-76f0-4400-ef7f66d17328@oracle.com>

Hi,

Kindly review fix for JDK-8170840.

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

Fix : http://cr.openjdk.java.net/~rgoel/JDK-8170840/webrev/

Fix is to correct no of country codes returned in 
TestGetLangsAndCountries() method.

Thanks,
Rachna

From naoto.sato at oracle.com  Wed Dec  7 16:39:21 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 7 Dec 2016 08:39:21 -0800
Subject: <i18n dev> RFR : JDK-8170840 : java/util/Locale/LocaleTest.java
 failed
In-Reply-To: <a225753c-37cd-76f0-4400-ef7f66d17328@oracle.com>
References: <a225753c-37cd-76f0-4400-ef7f66d17328@oracle.com>
Message-ID: <f1c54798-755a-f3f6-b44c-1d6c04d02587@oracle.com>

Hi Rachna,

The fix looks OK to me. Here are two nits:

- The bug id in the comment should be 8170840, since it is a regression 
caused by the fix to 8071929.

- The JIRA issue should have "noreg-self" keyword, and the link to 
8071929 would be helpful.

Naoto

On 12/7/16 4:03 AM, Rachna Goel wrote:
> Hi,
>
> Kindly review fix for JDK-8170840.
>
>  Bug :https://bugs.openjdk.java.net/browse/JDK-8170840
>
> Fix : http://cr.openjdk.java.net/~rgoel/JDK-8170840/webrev/
>
> Fix is to correct no of country codes returned in
> TestGetLangsAndCountries() method.
>
> Thanks,
> Rachna

From naoto.sato at oracle.com  Wed Dec  7 22:01:04 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 7 Dec 2016 14:01:04 -0800
Subject: <i18n dev> RFR : JDK-8170840 : java/util/Locale/LocaleTest.java
 failed
In-Reply-To: <f1c54798-755a-f3f6-b44c-1d6c04d02587@oracle.com>
References: <a225753c-37cd-76f0-4400-ef7f66d17328@oracle.com>
	<f1c54798-755a-f3f6-b44c-1d6c04d02587@oracle.com>
Message-ID: <86c03cab-1f21-06d2-7150-aceb0162cfdc@oracle.com>

Joe just excluded this failing test with 8170875, so please modify 
ProblemList.txt with this fix as well.

Naoto

On 12/7/16 8:39 AM, Naoto Sato wrote:
> Hi Rachna,
>
> The fix looks OK to me. Here are two nits:
>
> - The bug id in the comment should be 8170840, since it is a regression
> caused by the fix to 8071929.
>
> - The JIRA issue should have "noreg-self" keyword, and the link to
> 8071929 would be helpful.
>
> Naoto
>
> On 12/7/16 4:03 AM, Rachna Goel wrote:
>> Hi,
>>
>> Kindly review fix for JDK-8170840.
>>
>>  Bug :https://bugs.openjdk.java.net/browse/JDK-8170840
>>
>> Fix : http://cr.openjdk.java.net/~rgoel/JDK-8170840/webrev/
>>
>> Fix is to correct no of country codes returned in
>> TestGetLangsAndCountries() method.
>>
>> Thanks,
>> Rachna

From masayoshi.okutsu at oracle.com  Thu Dec  8 08:55:36 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 8 Dec 2016 17:55:36 +0900
Subject: <i18n dev> RFR: 8054214: JapaneseEra.getDisplayName doesn't return
 names if it's an additional era
Message-ID: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com>

Hi,

Please review the fix for JDK-8054214. It was necessary to override 
Era::getDisplayName to get era names from the specified property. This 
one fixes getAbbreviation() as well.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8054214

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

Thanks,
Masayoshi


From naoto.sato at oracle.com  Thu Dec  8 18:20:03 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 8 Dec 2016 10:20:03 -0800
Subject: <i18n dev> RFR: 8054214: JapaneseEra.getDisplayName doesn't
 return names if it's an additional era
In-Reply-To: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com>
References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com>
Message-ID: <ab8c6a80-48c9-5511-5a2d-34dea3c54165@oracle.com>

Okutsu-san,

In JapaneseEra::getDisplayName, Should there be Objects.requireNonNull() 
check for "style"? The current impl seems to return abbreviated era if 
null is passed as "style".

Naoto

On 12/8/16 12:55 AM, Masayoshi Okutsu wrote:
> Hi,
>
> Please review the fix for JDK-8054214. It was necessary to override
> Era::getDisplayName to get era names from the specified property. This
> one fixes getAbbreviation() as well.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8054214
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/
>
> Thanks,
> Masayoshi
>

From philip.race at oracle.com  Thu Dec  8 20:01:03 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 8 Dec 2016 12:01:03 -0800
Subject: <i18n dev> RFR: 8039273: Font related files should not be modified
 in ${java.home}/lib
Message-ID: <d8fd3e3a-1164-f17e-9f78-20fa05737e60@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8039273
Webrev : http://cr.openjdk.java.net/~prr/8039273/

A CCC request and documentation are being prepared.

-phil

From jbluettduncan at gmail.com  Thu Dec  8 11:52:47 2016
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Thu, 8 Dec 2016 11:52:47 +0000
Subject: <i18n dev> RFR: 8054214: JapaneseEra.getDisplayName doesn't
 return names if it's an additional era
In-Reply-To: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com>
References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com>
Message-ID: <CAPMys85ia+o-mQNNZsQ2gnNeYAqQvoP_tP7_RkfYmXnpZGQh0g@mail.gmail.com>

Hi Masayoshi,

I'm not a reviewer, but there's something in JapaneseEra.java.cdiff.html
<http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/src/java.base/share/classes/java/time/chrono/JapaneseEra.java.cdiff.html>
which
isn't terribly clear to me, so I wonder if you could clarify it for me.

In the method `getDisplayName(TextStyle style, Locale locale)`, it's not
clear to me why the call to `Objects.requireNonNull(locale, "locale");` is
within the if-statement rather than on the first line. Is this because
`Era.super::getDisplayName` already has a null check of its own?

Kind regards,
Jonathan

On 8 December 2016 at 08:55, Masayoshi Okutsu <masayoshi.okutsu at oracle.com>
wrote:

> Hi,
>
> Please review the fix for JDK-8054214. It was necessary to override
> Era::getDisplayName to get era names from the specified property. This one
> fixes getAbbreviation() as well.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8054214
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/
>
> Thanks,
> Masayoshi
>
>

From mandy.chung at oracle.com  Fri Dec  9 16:49:57 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 9 Dec 2016 08:49:57 -0800
Subject: <i18n dev> Review Request JDK-8170772: ResourceBundle improper
	caching causes tools/javadoc tests intermittently
Message-ID: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>

Naoto,

Can you review this ResourceBundle caching fix?  The caller module
may be different than the specified module to 
ResourceBundle.getBundle(String, Module) method and it should also
part of the cache key.

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/

The new test shows the issue there and the first loading of the 
resource bundle of a specific module (success or fail) will be 
put in the cache and used by subsequent calls.

Thanks
Mandy

From naoto.sato at oracle.com  Fri Dec  9 17:44:54 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 9 Dec 2016 09:44:54 -0800
Subject: <i18n dev> RFR: 8039273: Font related files should not be
 modified in ${java.home}/lib
In-Reply-To: <d8fd3e3a-1164-f17e-9f78-20fa05737e60@oracle.com>
References: <d8fd3e3a-1164-f17e-9f78-20fa05737e60@oracle.com>
Message-ID: <5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com>

Hi Phil,

In FontConfiguration.java, line 193-195 can be inserted just after line 
191, as fontConfigFile is guaranteed to be non-null if userConfigFile is 
non null. Otherwise it looks good to me.

Naoto

On 12/8/16 12:01 PM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039273
> Webrev : http://cr.openjdk.java.net/~prr/8039273/
>
> A CCC request and documentation are being prepared.
>
> -phil

From naoto.sato at oracle.com  Fri Dec  9 18:25:51 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 9 Dec 2016 10:25:51 -0800
Subject: <i18n dev> Review Request JDK-8170772: ResourceBundle improper
 caching causes tools/javadoc tests intermittently
In-Reply-To: <e071dd80-4ecd-fbf8-a7dc-aaf1046f996c@oracle.com>
References: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
	<e071dd80-4ecd-fbf8-a7dc-aaf1046f996c@oracle.com>
Message-ID: <941a03e9-a8df-de21-ef46-4102ed3fad49@oracle.com>

Hi Mandy,

The fix looks fine to me.

Naoto

On 12/9/16 10:05 AM, Daniel Fuchs wrote:
> Hi Mandy,
>
> It will be good to have Naoto's opinion on this.
> But what you propose makes sense to me.
>
> best regards,
>
> -- daniel
>
> On 09/12/16 16:49, Mandy Chung wrote:
>> Naoto,
>>
>> Can you review this ResourceBundle caching fix?  The caller module
>> may be different than the specified module to
>> ResourceBundle.getBundle(String, Module) method and it should also
>> part of the cache key.
>>
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/
>>
>> The new test shows the issue there and the first loading of the
>> resource bundle of a specific module (success or fail) will be
>> put in the cache and used by subsequent calls.
>>
>> Thanks
>> Mandy
>>
>

From srl at icu-project.org  Fri Dec  9 19:31:07 2016
From: srl at icu-project.org (Steven R. Loomis)
Date: Fri, 09 Dec 2016 11:31:07 -0800
Subject: <i18n dev> CFV: New Internationalization Group Lead: Naoto Sato
Message-ID: <1DD05B04-CC1A-492E-BE1B-1EEB9CCD00FC@icu-project.org>

Vote: yes



From daniel.fuchs at oracle.com  Fri Dec  9 18:05:50 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 9 Dec 2016 18:05:50 +0000
Subject: <i18n dev> Review Request JDK-8170772: ResourceBundle improper
 caching causes tools/javadoc tests intermittently
In-Reply-To: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
References: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
Message-ID: <e071dd80-4ecd-fbf8-a7dc-aaf1046f996c@oracle.com>

Hi Mandy,

It will be good to have Naoto's opinion on this.
But what you propose makes sense to me.

best regards,

-- daniel

On 09/12/16 16:49, Mandy Chung wrote:
> Naoto,
>
> Can you review this ResourceBundle caching fix?  The caller module
> may be different than the specified module to
> ResourceBundle.getBundle(String, Module) method and it should also
> part of the cache key.
>
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/
>
> The new test shows the issue there and the first loading of the
> resource bundle of a specific module (success or fail) will be
> put in the cache and used by subsequent calls.
>
> Thanks
> Mandy
>


From masayoshi.okutsu at oracle.com  Sun Dec 11 02:26:12 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Sun, 11 Dec 2016 11:26:12 +0900
Subject: <i18n dev> RFR: 8054214: JapaneseEra.getDisplayName doesn't
 return names if it's an additional era
In-Reply-To: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com>
References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com>
Message-ID: <178ecdb7-cc41-1fcb-a4b3-c55eae2adeaa@oracle.com>

Thank you for the review comments. I realized that only TextStyle.NARROW 
and NARROW_STANDALONE should return the abbreviation to be consistent 
with locale data. I've changed the implementation, which should have 
"fixed" the NPE issue, and added more test cases.

Revised webrev:
http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.01/

While I was testing more, I realized the default implementation of 
Era.getDisplayName doesn't work with non-IsoChronology. I filed new bug 
report JDK-8171049.

Thanks,
Masayoshi

On 12/8/2016 5:55 PM, Masayoshi Okutsu wrote:
> Hi,
>
> Please review the fix for JDK-8054214. It was necessary to override 
> Era::getDisplayName to get era names from the specified property. This 
> one fixes getAbbreviation() as well.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8054214
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/
>
> Thanks,
> Masayoshi
>


From philip.race at oracle.com  Wed Dec 14 21:16:07 2016
From: philip.race at oracle.com (Phil Race)
Date: Wed, 14 Dec 2016 13:16:07 -0800
Subject: <i18n dev> RFR: 8039273: Font related files should not be
 modified in ${java.home}/lib
In-Reply-To: <5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com>
References: <d8fd3e3a-1164-f17e-9f78-20fa05737e60@oracle.com>
	<5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com>
Message-ID: <15bc5a48-1644-cf33-3e57-49d08b7f07d4@oracle.com>

The fix has been updated.
http://cr.openjdk.java.net/~prr/8039273.1/
2nd reviewer anyone ?

-phil.


On 12/09/2016 09:44 AM, Naoto Sato wrote:
> Hi Phil,
>
> In FontConfiguration.java, line 193-195 can be inserted just after 
> line 191, as fontConfigFile is guaranteed to be non-null if 
> userConfigFile is non null. Otherwise it looks good to me.
>
> Naoto
>
> On 12/8/16 12:01 PM, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039273
>> Webrev : http://cr.openjdk.java.net/~prr/8039273/
>>
>> A CCC request and documentation are being prepared.
>>
>> -phil


From masayoshi.okutsu at oracle.com  Thu Dec 15 05:06:57 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 15 Dec 2016 14:06:57 +0900
Subject: <i18n dev> Result: New Internationalization Group Lead: Naoto Sato
Message-ID: <05bdcdfb-bc24-80b0-b9ec-9b62d28133bd@oracle.com>

Voting for Internationalization Group Lead Naoto Sato [1] is now closed.

Yes: 1
No: 0
Abstain: 0

According to the Bylaws definition of Simple Majority, this is
sufficient to approve the new Group Lead.  The OpenJDK Lead will
ask the Governing Board to ratify this nomination.

Masayoshi Okutsu

[1] 
http://mail.openjdk.java.net/pipermail/i18n-dev/2016-December/002208.html

From sergey.bylokhov at oracle.com  Thu Dec 15 13:16:15 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 Dec 2016 16:16:15 +0300
Subject: <i18n dev> [OpenJDK 2D-Dev] RFR: 8039273: Font related files
 should not be modified in ${java.home}/lib
In-Reply-To: <15bc5a48-1644-cf33-3e57-49d08b7f07d4@oracle.com>
References: <d8fd3e3a-1164-f17e-9f78-20fa05737e60@oracle.com>
	<5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com>
	<15bc5a48-1644-cf33-3e57-49d08b7f07d4@oracle.com>
Message-ID: <B73BC589-1643-4B75-A5A9-0ACC9C5FE6E5@oracle.com>

Hi, Phil.

> The fix has been updated.
> http://cr.openjdk.java.net/~prr/8039273.1/
> 2nd reviewer anyone ?

Looks fine. I assume that SecurityException from File.exists() is expected, or the code is executed under doPriviliged() block.

> 
> -phil.
> 
> 
> On 12/09/2016 09:44 AM, Naoto Sato wrote:
>> Hi Phil,
>> 
>> In FontConfiguration.java, line 193-195 can be inserted just after line 191, as fontConfigFile is guaranteed to be non-null if userConfigFile is non null. Otherwise it looks good to me.
>> 
>> Naoto
>> 
>> On 12/8/16 12:01 PM, Phil Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039273
>>> Webrev : http://cr.openjdk.java.net/~prr/8039273/
>>> 
>>> A CCC request and documentation are being prepared.
>>> 
>>> -phil
> 


From naoto.sato at oracle.com  Thu Dec 15 18:52:55 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 15 Dec 2016 10:52:55 -0800
Subject: <i18n dev> CFV: New Internationalization Group Member: Rachna Goel
Message-ID: <d0b819d6-4337-22a3-c7da-1749a8a82243@oracle.com>

I hereby nominate Rachna Goel (OpenJDK user name: rgoel) to Membership 
in the Internationalization Group.

Rachna is an Oracle engineer, working for the Internationalization team. 
She has been working in the Internationalization team since September 
2015. Rachna is an Author in the jdk9 project and has currently 
contributed 16 changes.

Votes are due by 2016-12-29T00:00:00Z.

Only current Members of the Internationalization Group [1] are eligible 
to vote on this nomination. Votes must be cast in the open by replying 
to this mailing list.
For Lazy Consensus voting instructions, see [2].

Kind Regards,
Naoto

[1] http://openjdk.java.net/census/#i18n
[2] http://openjdk.java.net/groups/#member-vote

From naoto.sato at oracle.com  Thu Dec 15 18:56:00 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 15 Dec 2016 10:56:00 -0800
Subject: <i18n dev> CFV: New Internationalization Group Member: Nishit Jain
Message-ID: <7b1944a6-63c4-1442-610a-aadf0226b437@oracle.com>

I hereby nominate Nishit Jain (OpenJDK user name: nishjain) to 
Membership in the Internationalization Group.

Nishit is an Oracle engineer, working for the Internationalization team. 
He has been working in the Internationalization team since December 
2015. Nishit is a Committer in the jdk9 project and has currently 
contributed 15 changes.

Votes are due by 2016-12-29T00:00:00Z.

Only current Members of the Internationalization Group [1] are eligible 
to vote on this nomination. Votes must be cast in the open by replying 
to this mailing list.
For Lazy Consensus voting instructions, see [2].

Kind Regards,
Naoto

[1] http://openjdk.java.net/census/#i18n
[2] http://openjdk.java.net/groups/#member-vote

From philip.race at oracle.com  Thu Dec 15 22:26:59 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 15 Dec 2016 14:26:59 -0800
Subject: <i18n dev> [OpenJDK 2D-Dev] RFR: 8039273: Font related files
 should not be modified in ${java.home}/lib
In-Reply-To: <B73BC589-1643-4B75-A5A9-0ACC9C5FE6E5@oracle.com>
References: <d8fd3e3a-1164-f17e-9f78-20fa05737e60@oracle.com>
	<5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com>
	<15bc5a48-1644-cf33-3e57-49d08b7f07d4@oracle.com>
	<B73BC589-1643-4B75-A5A9-0ACC9C5FE6E5@oracle.com>
Message-ID: <49f06120-8c70-ff35-5726-8874a0d0a74e@oracle.com>

This whole fontconfig lookup logic is in a doPrivileged.
And the code is already opening the directory  in the findImpl method
called just below the new exists() call.

-phil.

On 12/15/2016 05:16 AM, Sergey Bylokhov wrote:
> Hi, Phil.
>
>> The fix has been updated.
>> http://cr.openjdk.java.net/~prr/8039273.1/
>> 2nd reviewer anyone ?
> Looks fine. I assume that SecurityException from File.exists() is expected, or the code is executed under doPriviliged() block.
>
>> -phil.
>>
>>
>> On 12/09/2016 09:44 AM, Naoto Sato wrote:
>>> Hi Phil,
>>>
>>> In FontConfiguration.java, line 193-195 can be inserted just after line 191, as fontConfigFile is guaranteed to be non-null if userConfigFile is non null. Otherwise it looks good to me.
>>>
>>> Naoto
>>>
>>> On 12/8/16 12:01 PM, Phil Race wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039273
>>>> Webrev : http://cr.openjdk.java.net/~prr/8039273/
>>>>
>>>> A CCC request and documentation are being prepared.
>>>>
>>>> -phil


From naoto.sato at oracle.com  Mon Dec 19 16:28:13 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 19 Dec 2016 08:28:13 -0800
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
	ResourceBundleControlProvider for removal
Message-ID: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8171189/webrev.00/

The said SPI utilizes the Java extension mechanism which is now removed 
from JDK9. To our knowledge, no implementation has been made, including 
the original requester, so it's best to deprecate this in JDK9 and 
eventually remove in the future release.

Naoto

From naoto.sato at oracle.com  Mon Dec 19 17:08:22 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 19 Dec 2016 09:08:22 -0800
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
 ResourceBundleControlProvider for removal
In-Reply-To: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
Message-ID: <899d362a-1a43-1e9c-3e99-4445dff0b055@oracle.com>

Small modification to the proposed fix:

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

Modified test/ProblemList.txt to remove the line for the said SPI test. 
No other changes from 00.

Naoto

On 12/19/16 8:28 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8171189
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8171189/webrev.00/
>
> The said SPI utilizes the Java extension mechanism which is now removed
> from JDK9. To our knowledge, no implementation has been made, including
> the original requester, so it's best to deprecate this in JDK9 and
> eventually remove in the future release.
>
> Naoto

From mandy.chung at oracle.com  Mon Dec 19 17:23:55 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 19 Dec 2016 09:23:55 -0800
Subject: <i18n dev> [9] RFR: 8171189: Deprecate
	ResourceBundleControlProvider for removal
In-Reply-To: <899d362a-1a43-1e9c-3e99-4445dff0b055@oracle.com>
References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com>
	<899d362a-1a43-1e9c-3e99-4445dff0b055@oracle.com>
Message-ID: <3DC257CD-49D7-47D4-B1AA-EA418FB4BC0C@oracle.com>

Looks fine.

To our knowledge, this ResourceBundleControlProvider SPI is rarely used, if any. The extension mechanism was removed in jdk-9+41 and there isn?t any issue filed related to this SPI.  I agree to deprecate ResourceBundleControlProvider for removal.

Mandy

> On Dec 19, 2016, at 9:08 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Small modification to the proposed fix:
> 
> http://cr.openjdk.java.net/~naoto/8171189/webrev.01/
> 
> Modified test/ProblemList.txt to remove the line for the said SPI test. No other changes from 00.
> 
> Naoto
> 
> On 12/19/16 8:28 AM, Naoto Sato wrote:
>> Hello,
>> 
>> Please review the fix to the following issue:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8171189
>> 
>> The proposed fix is located at:
>> 
>> http://cr.openjdk.java.net/~naoto/8171189/webrev.00/
>> 
>> The said SPI utilizes the Java extension mechanism which is now removed
>> from JDK9. To our knowledge, no implementation has been made, including
>> the original requester, so it's best to deprecate this in JDK9 and
>> eventually remove in the future release.
>> 
>> Naoto


From rachna.goel at oracle.com  Wed Dec 21 13:10:43 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Wed, 21 Dec 2016 18:40:43 +0530
Subject: <i18n dev> RFR: JDK-8167143:CLDR timezone parsing does not work for
	all locales
Message-ID: <f3ff399f-4388-f0c4-c64b-f895866ff9b6@oracle.com>

Hi,

Please review fix for JDK-8167143.

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

patch : http://cr.openjdk.java.net/~rgoel/JDK-8167143/webrev.03/index.html

Fix : Timezone Parsing failures reasons are different for different locales.
a) For Chinese Locales, At run time, as these locales are not declared 
to be supported from CLDR, so COMPAT Locales precede them during 
resourcebundle search path at run time.
So, for [ zh-Hans-CN zh-Hant-HK zh-Hant-MO zh-Hant-TW zh-Hans-SG]  these 
likely subtags are  added for CLDR Provider.

b) For Thai locales, in DateFormatSymbols class, if SimpleDateForamt 
instance for th_TH_TH locale, happens to be created first, then current 
code is unconditionally
caching JRE's th_TH bundle which is wrong behaviour.

c) For zh__Hant and zh__Hans locales, retrieved list of candidate 
locales is not appropriate. zh_TW_Hant and zh_CN_Hans should not be 
first candidate locale to be looked up for those cases respectively.

d) locales nb-NO and nn-NO which are equivalent of no-NO-NY should be 
declared as implicit locales for COMPAT for all providers.

Thanks,
Rachna

From naoto.sato at oracle.com  Wed Dec 21 23:38:36 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 21 Dec 2016 15:38:36 -0800
Subject: <i18n dev> RFR: JDK-8167143:CLDR timezone parsing does not work
 for all locales
In-Reply-To: <f3ff399f-4388-f0c4-c64b-f895866ff9b6@oracle.com>
References: <f3ff399f-4388-f0c4-c64b-f895866ff9b6@oracle.com>
Message-ID: <8a811a47-f7ae-72b3-e04a-26808c9726d7@oracle.com>

Looks good to me.

Naoto

On 12/21/16 5:10 AM, Rachna Goel wrote:
> Hi,
>
> Please review fix for JDK-8167143.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8167143
>
> patch : http://cr.openjdk.java.net/~rgoel/JDK-8167143/webrev.03/index.html
>
> Fix : Timezone Parsing failures reasons are different for different
> locales.
> a) For Chinese Locales, At run time, as these locales are not declared
> to be supported from CLDR, so COMPAT Locales precede them during
> resourcebundle search path at run time.
> So, for [ zh-Hans-CN zh-Hant-HK zh-Hant-MO zh-Hant-TW zh-Hans-SG]  these
> likely subtags are  added for CLDR Provider.
>
> b) For Thai locales, in DateFormatSymbols class, if SimpleDateForamt
> instance for th_TH_TH locale, happens to be created first, then current
> code is unconditionally
> caching JRE's th_TH bundle which is wrong behaviour.
>
> c) For zh__Hant and zh__Hans locales, retrieved list of candidate
> locales is not appropriate. zh_TW_Hant and zh_CN_Hans should not be
> first candidate locale to be looked up for those cases respectively.
>
> d) locales nb-NO and nn-NO which are equivalent of no-NO-NY should be
> declared as implicit locales for COMPAT for all providers.
>
> Thanks,
> Rachna