From nishit.jain at oracle.com  Tue Jul  4 07:11:17 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 4 Jul 2017 12:41:17 +0530
Subject: <i18n dev> [10] RFR JDK-8032842 and JDK-8175539:
 Locale.filterTags()/lookupTag() methods...,
 Duplicate matching tags returned...
Message-ID: <5ca261dc-d83e-746b-6bb8-8c47901d7846@oracle.com>

Hi,

Please review the fix for JDK-8032842 and 8175539

Bug: https://bugs.openjdk.java.net/browse/JDK-8032842, 
https://bugs.openjdk.java.net/browse/JDK-8175539
Webrev: http://cr.openjdk.java.net/~nishjain/8032842_8175539/webrev.05/
CSR: https://bugs.openjdk.java.net/browse/JDK-8181073

Issue: Locale.filterTags()/lookupTag() methods were converting the case 
of input language tags and returning the lowercased language tags.
        Since the special range "*" matches every tag, all the input 
tags were directly returned without any additional processing, which 
might also contain duplicates.

Fix: Though matching process is done ignoring the case considerations, 
but the matched tag is returned by preserving its case as in the given 
input language tag(s).
      For language range "*", additional processing is added to remove 
the duplicate matching tags from the list of output tags.


Regards,
Nishit Jain

From naoto.sato at oracle.com  Wed Jul  5 18:21:26 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 5 Jul 2017 11:21:26 -0700
Subject: <i18n dev> [10] RFR JDK-8032842 and JDK-8175539:
 Locale.filterTags()/lookupTag() methods...,
 Duplicate matching tags returned...
In-Reply-To: <5ca261dc-d83e-746b-6bb8-8c47901d7846@oracle.com>
References: <5ca261dc-d83e-746b-6bb8-8c47901d7846@oracle.com>
Message-ID: <2eb820a4-78a3-bbbe-04d4-78cabcbebbaa@oracle.com>

Looks good to me.

Naoto

On 7/4/17 12:11 AM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8032842 and 8175539
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8032842, 
> https://bugs.openjdk.java.net/browse/JDK-8175539
> Webrev: http://cr.openjdk.java.net/~nishjain/8032842_8175539/webrev.05/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8181073
> 
> Issue: Locale.filterTags()/lookupTag() methods were converting the case 
> of input language tags and returning the lowercased language tags.
>         Since the special range "*" matches every tag, all the input 
> tags were directly returned without any additional processing, which 
> might also contain duplicates.
> 
> Fix: Though matching process is done ignoring the case considerations, 
> but the matched tag is returned by preserving its case as in the given 
> input language tag(s).
>       For language range "*", additional processing is added to remove 
> the duplicate matching tags from the list of output tags.
> 
> 
> Regards,
> Nishit Jain

From naoto.sato at oracle.com  Tue Jul 18 22:23:01 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Jul 2017 15:23:01 -0700
Subject: <i18n dev> [10] RFR (XS) 8183902: Remove unnecessary definitions in
 locale_str.h for macOS
Message-ID: <0d81fa82-7d5c-3e56-ff02-084223a45da3@oracle.com>

Hello,

Please review this small fix to the following issue:

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

The proposed fix is located at:

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

This is a leftover fix to 8160199. With the fix to 8160199, there is no 
need to supplement the language aliases for macOS, as they are all 
accompanied with designated country code.

Naoto

From brent.christian at oracle.com  Wed Jul 19 19:06:34 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 19 Jul 2017 12:06:34 -0700
Subject: <i18n dev> [10] RFR (XS) 8183902: Remove unnecessary
 definitions in locale_str.h for macOS
In-Reply-To: <0d81fa82-7d5c-3e56-ff02-084223a45da3@oracle.com>
References: <0d81fa82-7d5c-3e56-ff02-084223a45da3@oracle.com>
Message-ID: <817bcb83-e99d-530b-3e18-f1b7d6d5a15f@oracle.com>

The fix looks good, Naoto.

Thanks,
-Brent

On 7/18/17 3:23 PM, Naoto Sato wrote:
> Hello,
> 
> Please review this small fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8183902
> 
> The proposed fix is located at:
> 
> http://cr.openjdk.java.net/~naoto/8183902/webrev.00/
> 
> This is a leftover fix to 8160199. With the fix to 8160199, there is no 
> need to supplement the language aliases for macOS, as they are all 
> accompanied with designated country code.
> 
> Naoto

From nishit.jain at oracle.com  Thu Jul 20 05:33:24 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 20 Jul 2017 11:03:24 +0530
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
Message-ID: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>

Hi,

Please review the fix for JDK-8177472

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

Issue:The existing process of updating the LSR data requires manual 
execution of EquivMapsGenerator.java for generation of the updated maps.
Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
included in the JDK build process. After this change updation of LSR 
data will mostly require replacement of old language-subtag-registry.txt 
file with the new one and changing the copyright year in 
EquivMapsGenerator.java (if required) for the generated maps file.

Regards,
Nishit Jain

From naoto.sato at oracle.com  Thu Jul 20 18:06:07 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 20 Jul 2017 11:06:07 -0700
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
Message-ID: <ce41d465-b014-e5c3-09fd-0e3216dd8ae6@oracle.com>

Looks good to me.

Naoto

On 7/19/17 10:33 PM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8177472
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
> 
> Issue:The existing process of updating the LSR data requires manual 
> execution of EquivMapsGenerator.java for generation of the updated maps.
> Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
> included in the JDK build process. After this change updation of LSR 
> data will mostly require replacement of old language-subtag-registry.txt 
> file with the new one and changing the copyright year in 
> EquivMapsGenerator.java (if required) for the generated maps file.
> 
> Regards,
> Nishit Jain

From nishit.jain at oracle.com  Tue Jul 25 08:59:38 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 25 Jul 2017 14:29:38 +0530
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <ce41d465-b014-e5c3-09fd-0e3216dd8ae6@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <ce41d465-b014-e5c3-09fd-0e3216dd8ae6@oracle.com>
Message-ID: <0731abb3-a165-c1c2-3c71-dca72f89c72a@oracle.com>

A gentle reminder! Requesting for a build review

Regards,
Nishit Jain
On 20-07-2017 23:36, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 7/19/17 10:33 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8177472
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>
>> Issue:The existing process of updating the LSR data requires manual 
>> execution of EquivMapsGenerator.java for generation of the updated maps.
>> Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
>> included in the JDK build process. After this change updation of LSR 
>> data will mostly require replacement of old 
>> language-subtag-registry.txt file with the new one and changing the 
>> copyright year in EquivMapsGenerator.java (if required) for the 
>> generated maps file.
>>
>> Regards,
>> Nishit Jain


From Roger.Riggs at Oracle.com  Tue Jul 25 15:58:30 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 25 Jul 2017 11:58:30 -0400
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
Message-ID: <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>

Hi Nishit,

Can the hardcoded copyright be made more automatic?

I see the make/src/classes/build/tools/cldrconverter has functions to 
create/convert copyrights.
Can that be leveraged to generate the needed copyright and reduce some 
potential maintenance
of the copyright date and or contents?

Can the latest copyright date be taken from the File-Date field of the 
subtag-registry?

Thanks, Roger

On 7/20/2017 1:33 AM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8177472
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>
> Issue:The existing process of updating the LSR data requires manual 
> execution of EquivMapsGenerator.java for generation of the updated maps.
> Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
> included in the JDK build process. After this change updation of LSR 
> data will mostly require replacement of old 
> language-subtag-registry.txt file with the new one and changing the 
> copyright year in EquivMapsGenerator.java (if required) for the 
> generated maps file.
>
> Regards,
> Nishit Jain


From nishit.jain at oracle.com  Tue Jul 25 17:16:43 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 25 Jul 2017 22:46:43 +0530
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
Message-ID: <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>

Hi Roger,

CLDR converter generate the copyright year by the current date in which 
it is getting executed. I think the copyright year in 
LocaleEquivalentMaps.java should be the year in which the lsr data is 
last updated in jdk i.e. the year in which LocaleEquivalentMaps.java is 
last modified. This makes it difficult to compute the year automatically 
unless someone specifies it while updating the data.

 > Can the latest copyright date be taken from the File-Date field of 
the subtag-registry?
This may not be necessarily same as the year in which lsr data is 
updated in jdk.

Regards,
Nishit Jain
On 25-07-2017 21:28, Roger Riggs wrote:
> Hi Nishit,
>
> Can the hardcoded copyright be made more automatic?
>
> I see the make/src/classes/build/tools/cldrconverter has functions to 
> create/convert copyrights.
> Can that be leveraged to generate the needed copyright and reduce some 
> potential maintenance
> of the copyright date and or contents?
>
> Can the latest copyright date be taken from the File-Date field of the 
> subtag-registry?
>
> Thanks, Roger
>
> On 7/20/2017 1:33 AM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8177472
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>
>> Issue:The existing process of updating the LSR data requires manual 
>> execution of EquivMapsGenerator.java for generation of the updated maps.
>> Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
>> included in the JDK build process. After this change updation of LSR 
>> data will mostly require replacement of old 
>> language-subtag-registry.txt file with the new one and changing the 
>> copyright year in EquivMapsGenerator.java (if required) for the 
>> generated maps file.
>>
>> Regards,
>> Nishit Jain
>


From Roger.Riggs at Oracle.com  Tue Jul 25 17:25:07 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 25 Jul 2017 13:25:07 -0400
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
 <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>
Message-ID: <ba72cfd8-88c5-75b4-bdd8-cece297f6ca6@Oracle.com>

Hi,

I was focused mostly on *not *hardcoding the copyright text in yet 
another place
and if possible avoiding a manual update of the year.

And yet since the source is being generated and is transient (not 
retained after the build), the current year
is correct. (Same as cldr)

Roger


On 7/25/2017 1:16 PM, Nishit Jain wrote:
> Hi Roger,
>
> CLDR converter generate the copyright year by the current date in 
> which it is getting executed. I think the copyright year in 
> LocaleEquivalentMaps.java should be the year in which the lsr data is 
> last updated in jdk i.e. the year in which LocaleEquivalentMaps.java 
> is last modified. This makes it difficult to compute the year 
> automatically unless someone specifies it while updating the data.
>
> > Can the latest copyright date be taken from the File-Date field of 
> the subtag-registry?
> This may not be necessarily same as the year in which lsr data is 
> updated in jdk.
>
> Regards,
> Nishit Jain
> On 25-07-2017 21:28, Roger Riggs wrote:
>> Hi Nishit,
>>
>> Can the hardcoded copyright be made more automatic?
>>
>> I see the make/src/classes/build/tools/cldrconverter has functions to 
>> create/convert copyrights.
>> Can that be leveraged to generate the needed copyright and reduce 
>> some potential maintenance
>> of the copyright date and or contents?
>>
>> Can the latest copyright date be taken from the File-Date field of 
>> the subtag-registry?
>>
>> Thanks, Roger
>>
>> On 7/20/2017 1:33 AM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8177472
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>>
>>> Issue:The existing process of updating the LSR data requires manual 
>>> execution of EquivMapsGenerator.java for generation of the updated 
>>> maps.
>>> Fix:The execution of EquivMapsGenerator.javafor generation of maps 
>>> is included in the JDK build process. After this change updation of 
>>> LSR data will mostly require replacement of old 
>>> language-subtag-registry.txt file with the new one and changing the 
>>> copyright year in EquivMapsGenerator.java (if required) for the 
>>> generated maps file.
>>>
>>> Regards,
>>> Nishit Jain
>>
>


From tim.bell at oracle.com  Wed Jul 26 04:24:05 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 25 Jul 2017 21:24:05 -0700
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <0731abb3-a165-c1c2-3c71-dca72f89c72a@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <ce41d465-b014-e5c3-09fd-0e3216dd8ae6@oracle.com>
 <0731abb3-a165-c1c2-3c71-dca72f89c72a@oracle.com>
Message-ID: <59781965.7080503@oracle.com>

Hello Nishit:

> A gentle reminder! Requesting for a build review
>
> Regards,
> Nishit Jain

The build changes look fine.

Tim


> On 20-07-2017 23:36, Naoto Sato wrote:
>> Looks good to me.
>>
>> Naoto
>>
>> On 7/19/17 10:33 PM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8177472
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>>
>>> Issue:The existing process of updating the LSR data requires manual
>>> execution of EquivMapsGenerator.java for generation of the updated maps.
>>> Fix:The execution of EquivMapsGenerator.javafor generation of maps is
>>> included in the JDK build process. After this change updation of LSR
>>> data will mostly require replacement of old
>>> language-subtag-registry.txt file with the new one and changing the
>>> copyright year in EquivMapsGenerator.java (if required) for the
>>> generated maps file.
>>>
>>> Regards,
>>> Nishit Jain
>


From nishit.jain at oracle.com  Wed Jul 26 06:34:47 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Wed, 26 Jul 2017 12:04:47 +0530
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <ba72cfd8-88c5-75b4-bdd8-cece297f6ca6@Oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
 <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>
 <ba72cfd8-88c5-75b4-bdd8-cece297f6ca6@Oracle.com>
Message-ID: <c9d50ad6-d611-a700-058e-3174e6dbb781@oracle.com>

Thanks Roger,

Made the suggested changes related to hardcoded copyright year. Please 
check the updated webrev
http://cr.openjdk.java.net/~nishjain/8177472/webrev.06/

Regards,
Nishit Jain
On 25-07-2017 22:55, Roger Riggs wrote:
> Hi,
>
> I was focused mostly on *not *hardcoding the copyright text in yet 
> another place
> and if possible avoiding a manual update of the year.
>
> And yet since the source is being generated and is transient (not 
> retained after the build), the current year
> is correct. (Same as cldr)
>
> Roger
>
>
> On 7/25/2017 1:16 PM, Nishit Jain wrote:
>> Hi Roger,
>>
>> CLDR converter generate the copyright year by the current date in 
>> which it is getting executed. I think the copyright year in 
>> LocaleEquivalentMaps.java should be the year in which the lsr data is 
>> last updated in jdk i.e. the year in which LocaleEquivalentMaps.java 
>> is last modified. This makes it difficult to compute the year 
>> automatically unless someone specifies it while updating the data.
>>
>> > Can the latest copyright date be taken from the File-Date field of 
>> the subtag-registry?
>> This may not be necessarily same as the year in which lsr data is 
>> updated in jdk.
>>
>> Regards,
>> Nishit Jain
>> On 25-07-2017 21:28, Roger Riggs wrote:
>>> Hi Nishit,
>>>
>>> Can the hardcoded copyright be made more automatic?
>>>
>>> I see the make/src/classes/build/tools/cldrconverter has functions 
>>> to create/convert copyrights.
>>> Can that be leveraged to generate the needed copyright and reduce 
>>> some potential maintenance
>>> of the copyright date and or contents?
>>>
>>> Can the latest copyright date be taken from the File-Date field of 
>>> the subtag-registry?
>>>
>>> Thanks, Roger
>>>
>>> On 7/20/2017 1:33 AM, Nishit Jain wrote:
>>>> Hi,
>>>>
>>>> Please review the fix for JDK-8177472
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>>>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>>>
>>>> Issue:The existing process of updating the LSR data requires manual 
>>>> execution of EquivMapsGenerator.java for generation of the updated 
>>>> maps.
>>>> Fix:The execution of EquivMapsGenerator.javafor generation of maps 
>>>> is included in the JDK build process. After this change updation of 
>>>> LSR data will mostly require replacement of old 
>>>> language-subtag-registry.txt file with the new one and changing the 
>>>> copyright year in EquivMapsGenerator.java (if required) for the 
>>>> generated maps file.
>>>>
>>>> Regards,
>>>> Nishit Jain
>>>
>>
>


From Roger.Riggs at Oracle.com  Wed Jul 26 13:10:11 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 26 Jul 2017 09:10:11 -0400
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <c9d50ad6-d611-a700-058e-3174e6dbb781@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
 <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>
 <ba72cfd8-88c5-75b4-bdd8-cece297f6ca6@Oracle.com>
 <c9d50ad6-d611-a700-058e-3174e6dbb781@oracle.com>
Message-ID: <79b952ca-c088-6b37-0bb3-155eab55860a@Oracle.com>

good enough.

Roger


On 7/26/2017 2:34 AM, Nishit Jain wrote:
> Thanks Roger,
>
> Made the suggested changes related to hardcoded copyright year. Please 
> check the updated webrev
> http://cr.openjdk.java.net/~nishjain/8177472/webrev.06/
>
> Regards,
> Nishit Jain
> On 25-07-2017 22:55, Roger Riggs wrote:
>> Hi,
>>
>> I was focused mostly on *not *hardcoding the copyright text in yet 
>> another place
>> and if possible avoiding a manual update of the year.
>>
>> And yet since the source is being generated and is transient (not 
>> retained after the build), the current year
>> is correct. (Same as cldr)
>>
>> Roger
>>
>>
>> On 7/25/2017 1:16 PM, Nishit Jain wrote:
>>> Hi Roger,
>>>
>>> CLDR converter generate the copyright year by the current date in 
>>> which it is getting executed. I think the copyright year in 
>>> LocaleEquivalentMaps.java should be the year in which the lsr data 
>>> is last updated in jdk i.e. the year in which 
>>> LocaleEquivalentMaps.java is last modified. This makes it difficult 
>>> to compute the year automatically unless someone specifies it while 
>>> updating the data.
>>>
>>> > Can the latest copyright date be taken from the File-Date field of 
>>> the subtag-registry?
>>> This may not be necessarily same as the year in which lsr data is 
>>> updated in jdk.
>>>
>>> Regards,
>>> Nishit Jain
>>> On 25-07-2017 21:28, Roger Riggs wrote:
>>>> Hi Nishit,
>>>>
>>>> Can the hardcoded copyright be made more automatic?
>>>>
>>>> I see the make/src/classes/build/tools/cldrconverter has functions 
>>>> to create/convert copyrights.
>>>> Can that be leveraged to generate the needed copyright and reduce 
>>>> some potential maintenance
>>>> of the copyright date and or contents?
>>>>
>>>> Can the latest copyright date be taken from the File-Date field of 
>>>> the subtag-registry?
>>>>
>>>> Thanks, Roger
>>>>
>>>> On 7/20/2017 1:33 AM, Nishit Jain wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the fix for JDK-8177472
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>>>>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>>>>
>>>>> Issue:The existing process of updating the LSR data requires 
>>>>> manual execution of EquivMapsGenerator.java for generation of the 
>>>>> updated maps.
>>>>> Fix:The execution of EquivMapsGenerator.javafor generation of maps 
>>>>> is included in the JDK build process. After this change updation 
>>>>> of LSR data will mostly require replacement of old 
>>>>> language-subtag-registry.txt file with the new one and changing 
>>>>> the copyright year in EquivMapsGenerator.java (if required) for 
>>>>> the generated maps file.
>>>>>
>>>>> Regards,
>>>>> Nishit Jain
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Mon Jul 31 22:51:27 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 31 Jul 2017 15:51:27 -0700
Subject: <i18n dev> [10] RFR (XS): 8185251:
 java/util/ResourceBundle/modules/layer/run.sh failed on Japanese locale.
Message-ID: <0e3d1d11-c410-eca5-6ed7-50447bd3df32@oracle.com>

Hi Mandy,

Would you please review the fix to the following issue?

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

The proposed fix is located at:

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

The test assumed the resources in the root bundle is used for English 
locale in m1 module, which is not the case if there's other resource 
bundles available for the default locale (in the test case, Japanese). 
To fix this, provide an empty English resource bundle for m1 test module.

Naoto