From masayoshi.okutsu at oracle.com  Fri Oct 10 04:40:01 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 10 Oct 2014 13:40:01 +0900
Subject: <i18n dev> [9] RFR: 8060006: No Russian time zones mapping for
	Windows
Message-ID: <54376321.6000708@oracle.com>

Hello,

Please review the fix for 8060006, adding new Windows time zone mappings 
from KB2794119 and KB2998527.

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

Fix:
diff --git a/src/java.base/windows/conf/tzmappings b/src/java.base/windows/conf/tzmappings
--- a/src/java.base/windows/conf/tzmappings
+++ b/src/java.base/windows/conf/tzmappings
@@ -193,5 +193,10 @@
  Turkey Standard Time:926,926::Asia/Istanbul:
  Bahia Standard Time:927,927::America/Bahia:
  Libya Standard Time:928,928:LY:Africa/Tripoli:
-Western Brazilian Standard Time:929,929:BR:America/Rio_Branco:
-Armenian Standard Time:930,930:AM:Asia/Yerevan:
+Belarus Standard Time:929,929:BY:Europe/Minsk:
+Line Islands Standard Time:930,930::Pacific/Kiritimati:
+Russia Time Zone 10:931,931::Asia/Srednekolymsk:
+Russia Time Zone 11:932,932::Asia/Anadyr:
+Russia Time Zone 3:933,933::Europe/Samara:
+Western Brazilian Standard Time:934,934:BR:America/Rio_Branco:
+Armenian Standard Time:935,935:AM:Asia/Yerevan:

Thanks,
Masayoshi


From yuka.kamiya at oracle.com  Tue Oct 14 02:30:31 2014
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Tue, 14 Oct 2014 11:30:31 +0900
Subject: <i18n dev> [9] RFR: 8060006: No Russian time zones mapping for
 Windows
In-Reply-To: <54376321.6000708@oracle.com>
References: <54376321.6000708@oracle.com>
Message-ID: <543C8AC7.7090908@oracle.com>

Hi,

The fix looks good to me.

Thanks,
--
Yuka



On 2014/10/10 13:40, Masayoshi Okutsu wrote:
> Hello,
>
> Please review the fix for 8060006, adding new Windows time zone 
> mappings from KB2794119 and KB2998527.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8060006
>
> Fix:
> diff --git a/src/java.base/windows/conf/tzmappings 
> b/src/java.base/windows/conf/tzmappings
> --- a/src/java.base/windows/conf/tzmappings
> +++ b/src/java.base/windows/conf/tzmappings
> @@ -193,5 +193,10 @@
>  Turkey Standard Time:926,926::Asia/Istanbul:
>  Bahia Standard Time:927,927::America/Bahia:
>  Libya Standard Time:928,928:LY:Africa/Tripoli:
> -Western Brazilian Standard Time:929,929:BR:America/Rio_Branco:
> -Armenian Standard Time:930,930:AM:Asia/Yerevan:
> +Belarus Standard Time:929,929:BY:Europe/Minsk:
> +Line Islands Standard Time:930,930::Pacific/Kiritimati:
> +Russia Time Zone 10:931,931::Asia/Srednekolymsk:
> +Russia Time Zone 11:932,932::Asia/Anadyr:
> +Russia Time Zone 3:933,933::Europe/Samara:
> +Western Brazilian Standard Time:934,934:BR:America/Rio_Branco:
> +Armenian Standard Time:935,935:AM:Asia/Yerevan:
>
> Thanks,
> Masayoshi
>


From aleksej.efimov at oracle.com  Tue Oct 14 07:19:58 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 14 Oct 2014 11:19:58 +0400
Subject: <i18n dev> [9] RFR: 8060006: No Russian time zones mapping for
	Windows
In-Reply-To: <54376321.6000708@oracle.com>
References: <54376321.6000708@oracle.com>
Message-ID: <543CCE9E.1000201@oracle.com>

Hi Masayoshi,

The fix looks good to me (not a reviewer).

Thank you,
Aleksej

On 10.10.2014 8:40, Masayoshi Okutsu wrote:
> Hello,
>
> Please review the fix for 8060006, adding new Windows time zone 
> mappings from KB2794119 and KB2998527.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8060006
>
> Fix:
> diff --git a/src/java.base/windows/conf/tzmappings 
> b/src/java.base/windows/conf/tzmappings
> --- a/src/java.base/windows/conf/tzmappings
> +++ b/src/java.base/windows/conf/tzmappings
> @@ -193,5 +193,10 @@
>  Turkey Standard Time:926,926::Asia/Istanbul:
>  Bahia Standard Time:927,927::America/Bahia:
>  Libya Standard Time:928,928:LY:Africa/Tripoli:
> -Western Brazilian Standard Time:929,929:BR:America/Rio_Branco:
> -Armenian Standard Time:930,930:AM:Asia/Yerevan:
> +Belarus Standard Time:929,929:BY:Europe/Minsk:
> +Line Islands Standard Time:930,930::Pacific/Kiritimati:
> +Russia Time Zone 10:931,931::Asia/Srednekolymsk:
> +Russia Time Zone 11:932,932::Asia/Anadyr:
> +Russia Time Zone 3:933,933::Europe/Samara:
> +Western Brazilian Standard Time:934,934:BR:America/Rio_Branco:
> +Armenian Standard Time:935,935:AM:Asia/Yerevan:
>
> Thanks,
> Masayoshi
>


From y.umaoka at gmail.com  Fri Oct 17 20:43:29 2014
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Fri, 17 Oct 2014 16:43:29 -0400
Subject: <i18n dev> Java should handle user defined TimeZone subclass
 instances supporting historic rule changes properly
Message-ID: <54417F71.8010408@gmail.com>

Dear Java i18n team,

I was looking at recent Russian time zone changes and noticed a design 
issue in JDK. I think I knew this issue, but I forgot about this until 
recently. The problem is - Java does not support user defined custom 
TimeZone implementation properly.

java.util.TimeZone is quite old, and the original design assumed 'raw 
offset' and 'daylight saving amount' will never changed. To implement a 
subclass of TimeZone, you have to override an awkward abstract method - 
abstract int getOffset(int era, int year, int month, int day, int 
dayOfWeek, int milliseconds). This method signature itself does not 
limit a custom TimeZone implementation to support historic raw/dst 
offset changes. However, if you do so, you will see some problems in 
other places.

I filed a bug below:

====
Java should handle user defined TimeZone subclass instances supporting 
historic rule changes properly.

You can create a custom time zone implementation class by extending 
java.util.TimeZone. By the contract, the subclass must implement a few 
methods:

abstract int getOffset(int,int,int,int,int,int);
abstract int getRawOffset();
abstract boolean inDaylightTime(Date);
abstract void setRawOffset(int);
abstract boolean useDaylightTime();

Although, the interface above do not assume UTC offset or daylight 
saving amount is not changing time to time, a user can provide an 
implementation supporting historic UTC offset changes by int 
getOffset(int,int,int,int,int,int). However, there are two Java 
implementation problems.

1. The default implementation of TimeZone#getOffset(long date) does not 
use the abstract method - int getOffset(int,int,int,int,int,int). 
Therefore, when a different 'raw' offset was used in the past, or will 
be used in future, getOffset(long) always returns a result calculated 
from getRawOffset() and getDSTSavings(). Although a subclass 
implementation can provide TimeZone#getOffset(long date), the default 
implementation should use getOffset(int,int,int,int,int,int).

2. java.util.GregorianCalendar checks if a TimeZone instance is 
sun.util.calendar.TimZone or not, and if not, the offset field is 
calculated based on getRawOffset() / getDSTSavings(). Therefore, even a 
custom TimeZone implementation support different 'raw' offsets in the 
past or future, current 'raw' offset (getRawOffset()) value is used.


Use case:

A user may want to create a custom TimeZone instance from iCalendar 
VTIMEZONE component. iCalendr VTIMEZONE can support historic time zone 
rule changes.

Suggestions:

1) Add API TimeZone#getRawOffset(long) with the default implementation - 
return getRawOffset().
2) Add API TimeZone#getDSTSavings(long) with the default implementation 
- return getDSTSavings().
2) Update the default implementation of TimeZone#getOffset(long) to use 
#getRawOffset(long) #getDSTSavings(long) above along is existing 
#inDaylightTime(Date).
3) Gregorian calendar to use #getRawOffset(long) and 
#getDSTSavings(long), if not ZoneInfo.
====

There is an IETF working draft for timezone service protocol. In future, 
someone may want to create a custom time zone, interacting with a 
timezone service server to get the latest time zone rule data, instead 
of applying tzdata update utility. In this case, such limitation becomes 
a blocker. There are several ways to resolve the issue - I just 
suggested one way in the bug report. Are there anyone willing to look 
into this?

Thanks,
Yoshito


From naoto.sato at oracle.com  Fri Oct 17 22:31:08 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 17 Oct 2014 15:31:08 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
Message-ID: <544198AC.8050806@oracle.com>

Hello,

Please review the proposed changes to the following bug:

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

The webrev is available at:

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

This is mainly build changes to separate CLDR locale data into a new 
module. All those CLDR source changes (for .xml files) are merely the 
location changes in the repository, no changes are made to their file 
contents.

Naoto

From masayoshi.okutsu at oracle.com  Mon Oct 20 00:03:50 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 20 Oct 2014 09:03:50 +0900
Subject: <i18n dev> Java should handle user defined TimeZone subclass
 instances supporting historic rule changes properly
In-Reply-To: <54417F71.8010408@gmail.com>
References: <54417F71.8010408@gmail.com>
Message-ID: <54445166.30500@oracle.com>

Hi Umaoka-san,

Thanks for your bug report which I've closed as a duplicate of 
JDK-6380023. Yes, it's an API design flaw of java.util.TimeZone.

Since we now have the java.time API, I guess JDK-6380023 doesn't have 
any high priority (unless it gets escalated by someone).

Regards,
Masayoshi

On 10/18/2014 5:43 AM, Yoshito Umaoka wrote:
> Dear Java i18n team,
>
> I was looking at recent Russian time zone changes and noticed a design 
> issue in JDK. I think I knew this issue, but I forgot about this until 
> recently. The problem is - Java does not support user defined custom 
> TimeZone implementation properly.
>
> java.util.TimeZone is quite old, and the original design assumed 'raw 
> offset' and 'daylight saving amount' will never changed. To implement 
> a subclass of TimeZone, you have to override an awkward abstract 
> method - abstract int getOffset(int era, int year, int month, int day, 
> int dayOfWeek, int milliseconds). This method signature itself does 
> not limit a custom TimeZone implementation to support historic raw/dst 
> offset changes. However, if you do so, you will see some problems in 
> other places.
>
> I filed a bug below:
>
> ====
> Java should handle user defined TimeZone subclass instances supporting 
> historic rule changes properly.
>
> You can create a custom time zone implementation class by extending 
> java.util.TimeZone. By the contract, the subclass must implement a few 
> methods:
>
> abstract int getOffset(int,int,int,int,int,int);
> abstract int getRawOffset();
> abstract boolean inDaylightTime(Date);
> abstract void setRawOffset(int);
> abstract boolean useDaylightTime();
>
> Although, the interface above do not assume UTC offset or daylight 
> saving amount is not changing time to time, a user can provide an 
> implementation supporting historic UTC offset changes by int 
> getOffset(int,int,int,int,int,int). However, there are two Java 
> implementation problems.
>
> 1. The default implementation of TimeZone#getOffset(long date) does 
> not use the abstract method - int getOffset(int,int,int,int,int,int). 
> Therefore, when a different 'raw' offset was used in the past, or will 
> be used in future, getOffset(long) always returns a result calculated 
> from getRawOffset() and getDSTSavings(). Although a subclass 
> implementation can provide TimeZone#getOffset(long date), the default 
> implementation should use getOffset(int,int,int,int,int,int).
>
> 2. java.util.GregorianCalendar checks if a TimeZone instance is 
> sun.util.calendar.TimZone or not, and if not, the offset field is 
> calculated based on getRawOffset() / getDSTSavings(). Therefore, even 
> a custom TimeZone implementation support different 'raw' offsets in 
> the past or future, current 'raw' offset (getRawOffset()) value is used.
>
>
> Use case:
>
> A user may want to create a custom TimeZone instance from iCalendar 
> VTIMEZONE component. iCalendr VTIMEZONE can support historic time zone 
> rule changes.
>
> Suggestions:
>
> 1) Add API TimeZone#getRawOffset(long) with the default implementation 
> - return getRawOffset().
> 2) Add API TimeZone#getDSTSavings(long) with the default 
> implementation - return getDSTSavings().
> 2) Update the default implementation of TimeZone#getOffset(long) to 
> use #getRawOffset(long) #getDSTSavings(long) above along is existing 
> #inDaylightTime(Date).
> 3) Gregorian calendar to use #getRawOffset(long) and 
> #getDSTSavings(long), if not ZoneInfo.
> ====
>
> There is an IETF working draft for timezone service protocol. In 
> future, someone may want to create a custom time zone, interacting 
> with a timezone service server to get the latest time zone rule data, 
> instead of applying tzdata update utility. In this case, such 
> limitation becomes a blocker. There are several ways to resolve the 
> issue - I just suggested one way in the bug report. Are there anyone 
> willing to look into this?
>
> Thanks,
> Yoshito
>


From Alan.Bateman at oracle.com  Mon Oct 20 07:49:28 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Oct 2014 08:49:28 +0100
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <544198AC.8050806@oracle.com>
References: <544198AC.8050806@oracle.com>
Message-ID: <5444BE88.3010305@oracle.com>

On 17/10/2014 23:31, Naoto Sato wrote:
> Hello,
>
> Please review the proposed changes to the following bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8061382
>
> The webrev is available at:
>
> http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
>
> This is mainly build changes to separate CLDR locale data into a new 
> module. All those CLDR source changes (for .xml files) are merely the 
> location changes in the repository, no changes are made to their file 
> contents.

Will it eventually be possible to create a runtime that has the CLDR 
locale data but does not have the legacy JRE locale data? I'm assuming 
the CLDR does not have any dependences on the classes in the JRE locale 
data.

My motive for the question is the naming because the changes mean we 
have jdk.localedata and jdk.localedata.cldr, an arrangement that 
suggests that the CLDR locale data augments the jdk.localedata module. 
It may be that we need to choose more suitable names for these two 
modules and this will impact the source layout.

-Alan

From erik.joelsson at oracle.com  Mon Oct 20 07:54:40 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 20 Oct 2014 09:54:40 +0200
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <544198AC.8050806@oracle.com>
References: <544198AC.8050806@oracle.com>
Message-ID: <5444BFC0.7060908@oracle.com>

Hello Naoto,

With this split, I would rather see GensrcCLDR.gmk be renamed 
Gensrc-jdk.localedata.cldr.gmk and have the "all" targets etc added to 
it. Then Gensrc-jdk.localedata.gmk should no longer include it. Ideally 
GensrcLocaleData.gmk would be inlined into Gensrc-jdk.localedata.gmk.

Note that the targets declared in these files that are named after the 
modules (e.g. jdk.localedata) aren't really used. The files are just 
called with default target. Also, when jigsaw M2 hits, I have done away 
with the targets completely in these files, as they were just 
boilerplate, and have a wrapper that adds them automatically instead.

/Erik

On 2014-10-18 00:31, Naoto Sato wrote:
> Hello,
>
> Please review the proposed changes to the following bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8061382
>
> The webrev is available at:
>
> http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
>
> This is mainly build changes to separate CLDR locale data into a new 
> module. All those CLDR source changes (for .xml files) are merely the 
> location changes in the repository, no changes are made to their file 
> contents.
>
> Naoto


From y.umaoka at gmail.com  Mon Oct 20 15:22:27 2014
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Mon, 20 Oct 2014 11:22:27 -0400
Subject: <i18n dev> Java should handle user defined TimeZone subclass
 instances supporting historic rule changes properly
In-Reply-To: <54445166.30500@oracle.com>
References: <54417F71.8010408@gmail.com> <54445166.30500@oracle.com>
Message-ID: <544528B3.90902@gmail.com>

Okutsu-san,

Thanks for your quick reply. I looked at the JDK-6380023. I think my 
point was slightly different - what I want to do is to create my own 
time zone and use it as default JRE's time zone. But, I agree that the 
things discussed in the bug are necessary to achieve my goal with 
java.util.TimeZone.

With JSR-310 changes, can we do this through ZoneRulesProvider SPI? 
Assume my goal is to support 'latest' rules from tz database, without 
waiting/updating time zone data update patch from Oracle (or others) - 
and use them in both traditional date/time APIs (Calendar/DateFormat) as 
well as java.time APIs. In this case, can I achieve the goal with -

1) Implement my own ZoneRulesProvider with a new unique zone id - e.g. 
"Boston-MA"
2) TimeZone.setDefault(TimeZone.getTimeZone("Boston-MA"))

With this approach, can I override the default time zone of the JRE, 
with all historic/future rule changes implemented by my custom zone 
"Boston-MA"?

-Yoshito

On 10/19/2014 8:03 PM, Masayoshi Okutsu wrote:
> Hi Umaoka-san,
>
> Thanks for your bug report which I've closed as a duplicate of 
> JDK-6380023. Yes, it's an API design flaw of java.util.TimeZone.
>
> Since we now have the java.time API, I guess JDK-6380023 doesn't have 
> any high priority (unless it gets escalated by someone).
>
> Regards,
> Masayoshi
>
> On 10/18/2014 5:43 AM, Yoshito Umaoka wrote:
>> Dear Java i18n team,
>>
>> I was looking at recent Russian time zone changes and noticed a 
>> design issue in JDK. I think I knew this issue, but I forgot about 
>> this until recently. The problem is - Java does not support user 
>> defined custom TimeZone implementation properly.
>>
>> java.util.TimeZone is quite old, and the original design assumed 'raw 
>> offset' and 'daylight saving amount' will never changed. To implement 
>> a subclass of TimeZone, you have to override an awkward abstract 
>> method - abstract int getOffset(int era, int year, int month, int 
>> day, int dayOfWeek, int milliseconds). This method signature itself 
>> does not limit a custom TimeZone implementation to support historic 
>> raw/dst offset changes. However, if you do so, you will see some 
>> problems in other places.
>>
>> I filed a bug below:
>>
>> ====
>> Java should handle user defined TimeZone subclass instances 
>> supporting historic rule changes properly.
>>
>> You can create a custom time zone implementation class by extending 
>> java.util.TimeZone. By the contract, the subclass must implement a 
>> few methods:
>>
>> abstract int getOffset(int,int,int,int,int,int);
>> abstract int getRawOffset();
>> abstract boolean inDaylightTime(Date);
>> abstract void setRawOffset(int);
>> abstract boolean useDaylightTime();
>>
>> Although, the interface above do not assume UTC offset or daylight 
>> saving amount is not changing time to time, a user can provide an 
>> implementation supporting historic UTC offset changes by int 
>> getOffset(int,int,int,int,int,int). However, there are two Java 
>> implementation problems.
>>
>> 1. The default implementation of TimeZone#getOffset(long date) does 
>> not use the abstract method - int getOffset(int,int,int,int,int,int). 
>> Therefore, when a different 'raw' offset was used in the past, or 
>> will be used in future, getOffset(long) always returns a result 
>> calculated from getRawOffset() and getDSTSavings(). Although a 
>> subclass implementation can provide TimeZone#getOffset(long date), 
>> the default implementation should use 
>> getOffset(int,int,int,int,int,int).
>>
>> 2. java.util.GregorianCalendar checks if a TimeZone instance is 
>> sun.util.calendar.TimZone or not, and if not, the offset field is 
>> calculated based on getRawOffset() / getDSTSavings(). Therefore, even 
>> a custom TimeZone implementation support different 'raw' offsets in 
>> the past or future, current 'raw' offset (getRawOffset()) value is used.
>>
>>
>> Use case:
>>
>> A user may want to create a custom TimeZone instance from iCalendar 
>> VTIMEZONE component. iCalendr VTIMEZONE can support historic time 
>> zone rule changes.
>>
>> Suggestions:
>>
>> 1) Add API TimeZone#getRawOffset(long) with the default 
>> implementation - return getRawOffset().
>> 2) Add API TimeZone#getDSTSavings(long) with the default 
>> implementation - return getDSTSavings().
>> 2) Update the default implementation of TimeZone#getOffset(long) to 
>> use #getRawOffset(long) #getDSTSavings(long) above along is existing 
>> #inDaylightTime(Date).
>> 3) Gregorian calendar to use #getRawOffset(long) and 
>> #getDSTSavings(long), if not ZoneInfo.
>> ====
>>
>> There is an IETF working draft for timezone service protocol. In 
>> future, someone may want to create a custom time zone, interacting 
>> with a timezone service server to get the latest time zone rule data, 
>> instead of applying tzdata update utility. In this case, such 
>> limitation becomes a blocker. There are several ways to resolve the 
>> issue - I just suggested one way in the bug report. Are there anyone 
>> willing to look into this?
>>
>> Thanks,
>> Yoshito
>>
>


From naoto.sato at oracle.com  Tue Oct 21 00:16:18 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 20 Oct 2014 17:16:18 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <5444BFC0.7060908@oracle.com>
References: <544198AC.8050806@oracle.com> <5444BFC0.7060908@oracle.com>
Message-ID: <5445A5D2.6020605@oracle.com>

Thank you, Erik. Will incorporate your suggestions in the next webrev. 
As to inlining GensrcLocaleData.gmk, it is used not only in 
jdk.localedata, but also in java.base where English locale data is 
included. So it cannot be inlined into Gensrc-jdk.localedata.gmk.

Naoto

On 10/20/14, 12:54 AM, Erik Joelsson wrote:
> Hello Naoto,
>
> With this split, I would rather see GensrcCLDR.gmk be renamed
> Gensrc-jdk.localedata.cldr.gmk and have the "all" targets etc added to
> it. Then Gensrc-jdk.localedata.gmk should no longer include it. Ideally
> GensrcLocaleData.gmk would be inlined into Gensrc-jdk.localedata.gmk.
>
> Note that the targets declared in these files that are named after the
> modules (e.g. jdk.localedata) aren't really used. The files are just
> called with default target. Also, when jigsaw M2 hits, I have done away
> with the targets completely in these files, as they were just
> boilerplate, and have a wrapper that adds them automatically instead.
>
> /Erik
>
> On 2014-10-18 00:31, Naoto Sato wrote:
>> Hello,
>>
>> Please review the proposed changes to the following bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8061382
>>
>> The webrev is available at:
>>
>> http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
>>
>> This is mainly build changes to separate CLDR locale data into a new
>> module. All those CLDR source changes (for .xml files) are merely the
>> location changes in the repository, no changes are made to their file
>> contents.
>>
>> Naoto
>

From naoto.sato at oracle.com  Tue Oct 21 00:25:19 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 20 Oct 2014 17:25:19 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <5444BE88.3010305@oracle.com>
References: <544198AC.8050806@oracle.com> <5444BE88.3010305@oracle.com>
Message-ID: <5445A7EF.1010606@oracle.com>

On 10/20/14, 12:49 AM, Alan Bateman wrote:
> Will it eventually be possible to create a runtime that has the CLDR
> locale data but does not have the legacy JRE locale data? I'm assuming
> the CLDR does not have any dependences on the classes in the JRE locale
> data.

Yes, that should be possible in the future. In fact, that's the whole 
purpose of separating CLDR into a single module.

>
> My motive for the question is the naming because the changes mean we
> have jdk.localedata and jdk.localedata.cldr, an arrangement that
> suggests that the CLDR locale data augments the jdk.localedata module.
> It may be that we need to choose more suitable names for these two
> modules and this will impact the source layout.

I think we can rename the original jdk.localedata to jdk.localedata.jre 
solely for the legacy JRE locale data, and create the new 
jdk.localedata.cldr. Or re-purpose jdk.localedata to represent the 
legacy JRE locale data, and newly create jdk.cldrlocaledata for the CLDR 
data. Either way they won't suggest the augmentation you refer.

Naoto

From erik.joelsson at oracle.com  Tue Oct 21 06:46:20 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 21 Oct 2014 08:46:20 +0200
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <5445A5D2.6020605@oracle.com>
References: <544198AC.8050806@oracle.com> <5444BFC0.7060908@oracle.com>
	<5445A5D2.6020605@oracle.com>
Message-ID: <5446013C.7020503@oracle.com>

Thanks, forgot about GensrcLocaleData.gmk being used by more than one 
module.

/Erik

On 2014-10-21 02:16, Naoto Sato wrote:
> Thank you, Erik. Will incorporate your suggestions in the next webrev. 
> As to inlining GensrcLocaleData.gmk, it is used not only in 
> jdk.localedata, but also in java.base where English locale data is 
> included. So it cannot be inlined into Gensrc-jdk.localedata.gmk.
>
> Naoto
>
> On 10/20/14, 12:54 AM, Erik Joelsson wrote:
>> Hello Naoto,
>>
>> With this split, I would rather see GensrcCLDR.gmk be renamed
>> Gensrc-jdk.localedata.cldr.gmk and have the "all" targets etc added to
>> it. Then Gensrc-jdk.localedata.gmk should no longer include it. Ideally
>> GensrcLocaleData.gmk would be inlined into Gensrc-jdk.localedata.gmk.
>>
>> Note that the targets declared in these files that are named after the
>> modules (e.g. jdk.localedata) aren't really used. The files are just
>> called with default target. Also, when jigsaw M2 hits, I have done away
>> with the targets completely in these files, as they were just
>> boilerplate, and have a wrapper that adds them automatically instead.
>>
>> /Erik
>>
>> On 2014-10-18 00:31, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the proposed changes to the following bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8061382
>>>
>>> The webrev is available at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
>>>
>>> This is mainly build changes to separate CLDR locale data into a new
>>> module. All those CLDR source changes (for .xml files) are merely the
>>> location changes in the repository, no changes are made to their file
>>> contents.
>>>
>>> Naoto
>>


From Alan.Bateman at oracle.com  Tue Oct 21 07:08:39 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Oct 2014 08:08:39 +0100
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <5445A7EF.1010606@oracle.com>
References: <544198AC.8050806@oracle.com> <5444BE88.3010305@oracle.com>
	<5445A7EF.1010606@oracle.com>
Message-ID: <54460677.1060709@oracle.com>

On 21/10/2014 01:25, Naoto Sato wrote:
>
> I think we can rename the original jdk.localedata to 
> jdk.localedata.jre solely for the legacy JRE locale data, and create 
> the new jdk.localedata.cldr. Or re-purpose jdk.localedata to represent 
> the legacy JRE locale data, and newly create jdk.cldrlocaledata for 
> the CLDR data. Either way they won't suggest the augmentation you refer.
>
Do you mind putting this change on hold to allow for a discussion on the 
module naming?

-Alan

From mandy.chung at oracle.com  Wed Oct 22 18:29:13 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 22 Oct 2014 11:29:13 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <5445A7EF.1010606@oracle.com>
References: <544198AC.8050806@oracle.com> <5444BE88.3010305@oracle.com>
	<5445A7EF.1010606@oracle.com>
Message-ID: <5447F779.5040200@oracle.com>


On 10/20/2014 5:25 PM, Naoto Sato wrote:
>
>>
>> My motive for the question is the naming because the changes mean we
>> have jdk.localedata and jdk.localedata.cldr, an arrangement that
>> suggests that the CLDR locale data augments the jdk.localedata module.
>> It may be that we need to choose more suitable names for these two
>> modules and this will impact the source layout.
>
> I think we can rename the original jdk.localedata to 
> jdk.localedata.jre solely for the legacy JRE locale data, and create 
> the new jdk.localedata.cldr. Or re-purpose jdk.localedata to represent 
> the legacy JRE locale data, and newly create jdk.cldrlocaledata for 
> the CLDR data. Either way they won't suggest the augmentation you refer.

I think either CLDR or the legacy locale data is used but not both. As I 
understand, it's specified via the "java.locale.providers" system 
property and CLDR is not used by default.   CLDR is common locale data 
repository and "localedata" is implied.

One alternative is:
    jdk.cldrdata
    jdk.localedata

I understand from you that the plan is to enable CLDR by default in a 
future JDK release.   The other option of the module names could be:
     jdk.locale.legacy
     jdk.locale.cldr

They are providers to the locale SPI and so "jdk.locale" might do.

Mandy


From naoto.sato at oracle.com  Wed Oct 22 19:52:36 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 22 Oct 2014 12:52:36 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <5447F779.5040200@oracle.com>
References: <544198AC.8050806@oracle.com> <5444BE88.3010305@oracle.com>
	<5445A7EF.1010606@oracle.com> <5447F779.5040200@oracle.com>
Message-ID: <54480B04.3090009@oracle.com>

Hi Mandy,

As I wrote in a separate email, my preference is the following module names:

jdk.localedata.jre
jdk.localedata.cldr

This way, they both come under "localedata" (btw, they don't provide 
Locale, but the data for locale sensitive services such as DateFormat, 
so I prefer to keep "localedata" here), and jre/cldr are provider names 
which correspond to names in the system property.

Naoto

On 10/22/14, 11:29 AM, Mandy Chung wrote:
>
> On 10/20/2014 5:25 PM, Naoto Sato wrote:
>>
>>>
>>> My motive for the question is the naming because the changes mean we
>>> have jdk.localedata and jdk.localedata.cldr, an arrangement that
>>> suggests that the CLDR locale data augments the jdk.localedata module.
>>> It may be that we need to choose more suitable names for these two
>>> modules and this will impact the source layout.
>>
>> I think we can rename the original jdk.localedata to
>> jdk.localedata.jre solely for the legacy JRE locale data, and create
>> the new jdk.localedata.cldr. Or re-purpose jdk.localedata to represent
>> the legacy JRE locale data, and newly create jdk.cldrlocaledata for
>> the CLDR data. Either way they won't suggest the augmentation you refer.
>
> I think either CLDR or the legacy locale data is used but not both. As I
> understand, it's specified via the "java.locale.providers" system
> property and CLDR is not used by default.   CLDR is common locale data
> repository and "localedata" is implied.
>
> One alternative is:
>     jdk.cldrdata
>     jdk.localedata
>
> I understand from you that the plan is to enable CLDR by default in a
> future JDK release.   The other option of the module names could be:
>      jdk.locale.legacy
>      jdk.locale.cldr
>
> They are providers to the locale SPI and so "jdk.locale" might do.
>
> Mandy
>

From masayoshi.okutsu at oracle.com  Thu Oct 23 00:54:26 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 23 Oct 2014 09:54:26 +0900
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <54480B04.3090009@oracle.com>
References: <544198AC.8050806@oracle.com>
	<5444BE88.3010305@oracle.com>	<5445A7EF.1010606@oracle.com>
	<5447F779.5040200@oracle.com> <54480B04.3090009@oracle.com>
Message-ID: <544851C2.70503@oracle.com>

+1

On 10/23/2014 4:52 AM, Naoto Sato wrote:
> Hi Mandy,
>
> As I wrote in a separate email, my preference is the following module 
> names:
>
> jdk.localedata.jre
> jdk.localedata.cldr
>
> This way, they both come under "localedata" (btw, they don't provide 
> Locale, but the data for locale sensitive services such as DateFormat, 
> so I prefer to keep "localedata" here), and jre/cldr are provider 
> names which correspond to names in the system property.
>
> Naoto
>
> On 10/22/14, 11:29 AM, Mandy Chung wrote:
>>
>> On 10/20/2014 5:25 PM, Naoto Sato wrote:
>>>
>>>>
>>>> My motive for the question is the naming because the changes mean we
>>>> have jdk.localedata and jdk.localedata.cldr, an arrangement that
>>>> suggests that the CLDR locale data augments the jdk.localedata module.
>>>> It may be that we need to choose more suitable names for these two
>>>> modules and this will impact the source layout.
>>>
>>> I think we can rename the original jdk.localedata to
>>> jdk.localedata.jre solely for the legacy JRE locale data, and create
>>> the new jdk.localedata.cldr. Or re-purpose jdk.localedata to represent
>>> the legacy JRE locale data, and newly create jdk.cldrlocaledata for
>>> the CLDR data. Either way they won't suggest the augmentation you 
>>> refer.
>>
>> I think either CLDR or the legacy locale data is used but not both. As I
>> understand, it's specified via the "java.locale.providers" system
>> property and CLDR is not used by default.   CLDR is common locale data
>> repository and "localedata" is implied.
>>
>> One alternative is:
>>     jdk.cldrdata
>>     jdk.localedata
>>
>> I understand from you that the plan is to enable CLDR by default in a
>> future JDK release.   The other option of the module names could be:
>>      jdk.locale.legacy
>>      jdk.locale.cldr
>>
>> They are providers to the locale SPI and so "jdk.locale" might do.
>>
>> Mandy
>>


From Alan.Bateman at oracle.com  Thu Oct 23 07:58:35 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Oct 2014 08:58:35 +0100
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <54480B04.3090009@oracle.com>
References: <544198AC.8050806@oracle.com> <5444BE88.3010305@oracle.com>
	<5445A7EF.1010606@oracle.com> <5447F779.5040200@oracle.com>
	<54480B04.3090009@oracle.com>
Message-ID: <5448B52B.8060503@oracle.com>

On 22/10/2014 20:52, Naoto Sato wrote:
> Hi Mandy,
>
> As I wrote in a separate email, my preference is the following module 
> names:
>
> jdk.localedata.jre
> jdk.localedata.cldr
>
> This way, they both come under "localedata" (btw, they don't provide 
> Locale, but the data for locale sensitive services such as DateFormat, 
> so I prefer to keep "localedata" here), and jre/cldr are provider 
> names which correspond to names in the system property.
jdk.localedata.XXX looks right. I wonder if we can find something better 
than "jre" for the suffix of the first one. I ask because linking that 
into a runtime that isn't the what we know today as the JRE might be 
confusing.

-Alan.

From masayoshi.okutsu at oracle.com  Thu Oct 23 08:17:57 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 23 Oct 2014 17:17:57 +0900
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <5448B52B.8060503@oracle.com>
References: <544198AC.8050806@oracle.com>
	<5444BE88.3010305@oracle.com>	<5445A7EF.1010606@oracle.com>
	<5447F779.5040200@oracle.com>	<54480B04.3090009@oracle.com>
	<5448B52B.8060503@oracle.com>
Message-ID: <5448B9B5.2090609@oracle.com>

On 10/23/2014 4:58 PM, Alan Bateman wrote:
> jdk.localedata.XXX looks right. I wonder if we can find something 
> better than "jre" for the suffix of the first one. I ask because 
> linking that into a runtime that isn't the what we know today as the 
> JRE might be confusing.

Actually Naoto and I discussed that issue, but we couldn't come up with 
any better one. Any suggestions?

Masayoshi


From Alan.Bateman at oracle.com  Thu Oct 23 13:55:16 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Oct 2014 14:55:16 +0100
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <5448B9B5.2090609@oracle.com>
References: <544198AC.8050806@oracle.com>
	<5444BE88.3010305@oracle.com>	<5445A7EF.1010606@oracle.com>
	<5447F779.5040200@oracle.com>	<54480B04.3090009@oracle.com>
	<5448B52B.8060503@oracle.com> <5448B9B5.2090609@oracle.com>
Message-ID: <544908C4.8000003@oracle.com>

On 23/10/2014 09:17, Masayoshi Okutsu wrote:
> On 10/23/2014 4:58 PM, Alan Bateman wrote:
>> jdk.localedata.XXX looks right. I wonder if we can find something 
>> better than "jre" for the suffix of the first one. I ask because 
>> linking that into a runtime that isn't the what we know today as the 
>> JRE might be confusing.
>
> Actually Naoto and I discussed that issue, but we couldn't come up 
> with any better one. Any suggestions?
I agree that finding a good name is hard. As we talking about service 
provider modules then the naming is slightly less important than for 
modules that export APIs but still important to find a good name. I 
don't know if you have considered jdk.localedata.classic and 
jdk.localedata.cldr.

-Alan

From naoto.sato at oracle.com  Thu Oct 23 16:07:40 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 23 Oct 2014 09:07:40 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
 locale data
In-Reply-To: <544908C4.8000003@oracle.com>
References: <544198AC.8050806@oracle.com>
	<5444BE88.3010305@oracle.com>	<5445A7EF.1010606@oracle.com>
	<5447F779.5040200@oracle.com>	<54480B04.3090009@oracle.com>
	<5448B52B.8060503@oracle.com> <5448B9B5.2090609@oracle.com>
	<544908C4.8000003@oracle.com>
Message-ID: <544927CC.2090200@oracle.com>

Thanks for the naming suggestion, Alan. I will use "classic" then.

I also think we should introduce "CLASSIC" as a property name for the 
java.locale.providers system property which should be an alias to "JRE", 
this requires a CCC though.

Naoto

On 10/23/14, 6:55 AM, Alan Bateman wrote:
> On 23/10/2014 09:17, Masayoshi Okutsu wrote:
>> On 10/23/2014 4:58 PM, Alan Bateman wrote:
>>> jdk.localedata.XXX looks right. I wonder if we can find something
>>> better than "jre" for the suffix of the first one. I ask because
>>> linking that into a runtime that isn't the what we know today as the
>>> JRE might be confusing.
>>
>> Actually Naoto and I discussed that issue, but we couldn't come up
>> with any better one. Any suggestions?
> I agree that finding a good name is hard. As we talking about service
> provider modules then the naming is slightly less important than for
> modules that export APIs but still important to find a good name. I
> don't know if you have considered jdk.localedata.classic and
> jdk.localedata.cldr.
>
> -Alan

From naoto.sato at oracle.com  Thu Oct 23 20:05:00 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 23 Oct 2014 13:05:00 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <544198AC.8050806@oracle.com>
References: <544198AC.8050806@oracle.com>
Message-ID: <54495F6C.5020204@oracle.com>

I revised the fix according to the suggestions I got. The main change is 
to rename the name of the locale data modules. Now we have two as follows:

- jdk.localedata.classic: Legacy locale data
- jdk.localedata.cldr: CLDR locale data

Revised webrev is located at:

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

Naoto

On 10/17/14, 3:31 PM, Naoto Sato wrote:
> Hello,
>
> Please review the proposed changes to the following bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8061382
>
> The webrev is available at:
>
> http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
>
> This is mainly build changes to separate CLDR locale data into a new
> module. All those CLDR source changes (for .xml files) are merely the
> location changes in the repository, no changes are made to their file
> contents.
>
> Naoto

From erik.joelsson at oracle.com  Fri Oct 24 07:28:40 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 24 Oct 2014 09:28:40 +0200
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <54495F6C.5020204@oracle.com>
References: <544198AC.8050806@oracle.com> <54495F6C.5020204@oracle.com>
Message-ID: <5449FFA8.9080001@oracle.com>

Hello Naoto,

Just one thing, in Gensrc-java.base.gmk, shouldn't we still just run the 
targets in GENSRC_JAVA_BASE and let Gensrc-jdk.localedata.classic.gmk 
deal with GENSRC_JDK_LOCALEDATA_CLASSIC?

/Erik

On 2014-10-23 22:05, Naoto Sato wrote:
> I revised the fix according to the suggestions I got. The main change 
> is to rename the name of the locale data modules. Now we have two as 
> follows:
>
> - jdk.localedata.classic: Legacy locale data
> - jdk.localedata.cldr: CLDR locale data
>
> Revised webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/8061382/webrev.01/
>
> Naoto
>
> On 10/17/14, 3:31 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the proposed changes to the following bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8061382
>>
>> The webrev is available at:
>>
>> http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
>>
>> This is mainly build changes to separate CLDR locale data into a new
>> module. All those CLDR source changes (for .xml files) are merely the
>> location changes in the repository, no changes are made to their file
>> contents.
>>
>> Naoto


From naoto.sato at oracle.com  Fri Oct 24 22:17:12 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 24 Oct 2014 15:17:12 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <5449FFA8.9080001@oracle.com>
References: <544198AC.8050806@oracle.com> <54495F6C.5020204@oracle.com>
	<5449FFA8.9080001@oracle.com>
Message-ID: <544ACFE8.6080307@oracle.com>

Hi Erik,

Yep, that is not needed so I will remove it. Thank you for catching it.

Naoto

On 10/24/14, 12:28 AM, Erik Joelsson wrote:
> Hello Naoto,
>
> Just one thing, in Gensrc-java.base.gmk, shouldn't we still just run the
> targets in GENSRC_JAVA_BASE and let Gensrc-jdk.localedata.classic.gmk
> deal with GENSRC_JDK_LOCALEDATA_CLASSIC?
>
> /Erik
>
> On 2014-10-23 22:05, Naoto Sato wrote:
>> I revised the fix according to the suggestions I got. The main change
>> is to rename the name of the locale data modules. Now we have two as
>> follows:
>>
>> - jdk.localedata.classic: Legacy locale data
>> - jdk.localedata.cldr: CLDR locale data
>>
>> Revised webrev is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8061382/webrev.01/
>>
>> Naoto
>>
>> On 10/17/14, 3:31 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the proposed changes to the following bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8061382
>>>
>>> The webrev is available at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
>>>
>>> This is mainly build changes to separate CLDR locale data into a new
>>> module. All those CLDR source changes (for .xml files) are merely the
>>> location changes in the repository, no changes are made to their file
>>> contents.
>>>
>>> Naoto
>

From aleksej.efimov at oracle.com  Tue Oct 28 11:57:05 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 28 Oct 2014 14:57:05 +0300
Subject: <i18n dev> RFR: 8059206: (tz) Support tzdata2014i
Message-ID: <544F8491.2090304@oracle.com>

Hi,

Can I ask for review of new tzdata - 2014i integration fix to JDK9. One 
change in this release is that new time zone was added - 
"Pacific/Bougainville". The localized names still needs to be translated 
- the appropriate comment was added to JDK-8057004.

Testing results:
JPRT tests: jdk_other jdk_util jdk_text jdk_time - no failures
JTREG tests: test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time test/java/util/Formatter 
test/closed/java/util/Calendar test/closed/java/util/TimeZone 
test/closed/java/text/Format/DateFormat - no failures

Thank you,
Aleksej

[1] Bug: https://bugs.openjdk.java.net/browse/JDK-8059206
[2] Webrev: http://cr.openjdk.java.net/~aefimov/8059206/9/webrev.00

From masayoshi.okutsu at oracle.com  Tue Oct 28 13:46:12 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 28 Oct 2014 22:46:12 +0900
Subject: <i18n dev> RFR: 8059206: (tz) Support tzdata2014i
In-Reply-To: <544F8491.2090304@oracle.com>
References: <544F8491.2090304@oracle.com>
Message-ID: <544F9E24.2080109@oracle.com>

Hi Aleksej,

src/java.base/share/classes/sun/util/resources/TimeZoneNames*.java:

+            {"Pacific/Bougainville", new String[] {"Bougainville Standard Time", "BST",
+                                                   "Bougainville Summer Time", "BST",
+                                                   "Bougainville Time", "BT"}},


I'd use "Daylight Time" instead of "Summer Time" because of the recent 
move from Summer to Daylight. No daylight saving time is observed in 
Bougainville, though.

Otherwise, all the changes look good to me.

Thanks,
Masayoshi

On 10/28/2014 8:57 PM, Aleksej Efimov wrote:
> Hi,
>
> Can I ask for review of new tzdata - 2014i integration fix to JDK9. 
> One change in this release is that new time zone was added - 
> "Pacific/Bougainville". The localized names still needs to be 
> translated - the appropriate comment was added to JDK-8057004.
>
> Testing results:
> JPRT tests: jdk_other jdk_util jdk_text jdk_time - no failures
> JTREG tests: test/sun/util/calendar test/java/util/Calendar 
> test/sun/util/resources/TimeZone test/sun/util/calendar 
> test/java/util/TimeZone test/java/time test/java/util/Formatter 
> test/closed/java/util/Calendar test/closed/java/util/TimeZone 
> test/closed/java/text/Format/DateFormat - no failures
>
> Thank you,
> Aleksej
>
> [1] Bug: https://bugs.openjdk.java.net/browse/JDK-8059206
> [2] Webrev: http://cr.openjdk.java.net/~aefimov/8059206/9/webrev.00


From aleksej.efimov at oracle.com  Tue Oct 28 14:08:09 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 28 Oct 2014 17:08:09 +0300
Subject: <i18n dev> RFR: 8059206: (tz) Support tzdata2014i
In-Reply-To: <544F9E24.2080109@oracle.com>
References: <544F8491.2090304@oracle.com> <544F9E24.2080109@oracle.com>
Message-ID: <544FA349.4060003@oracle.com>

Hi Masayoshi,
Thank you for the review.
Ok, I will change the "Summer Time" to "Daylight Time" before the push.

Best Regards,
Aleksej

On 10/28/2014 04:46 PM, Masayoshi Okutsu wrote:
> Hi Aleksej,
>
> src/java.base/share/classes/sun/util/resources/TimeZoneNames*.java:
> +            {"Pacific/Bougainville", new String[] {"Bougainville Standard Time", "BST",
> +                                                   "Bougainville Summer Time", "BST",
> +                                                   "Bougainville Time", "BT"}},
>
> I'd use "Daylight Time" instead of "Summer Time" because of the recent 
> move from Summer to Daylight. No daylight saving time is observed in 
> Bougainville, though.
>
> Otherwise, all the changes look good to me.
>
> Thanks,
> Masayoshi
>
> On 10/28/2014 8:57 PM, Aleksej Efimov wrote:
>> Hi,
>>
>> Can I ask for review of new tzdata - 2014i integration fix to JDK9. 
>> One change in this release is that new time zone was added - 
>> "Pacific/Bougainville". The localized names still needs to be 
>> translated - the appropriate comment was added to JDK-8057004.
>>
>> Testing results:
>> JPRT tests: jdk_other jdk_util jdk_text jdk_time - no failures
>> JTREG tests: test/sun/util/calendar test/java/util/Calendar 
>> test/sun/util/resources/TimeZone test/sun/util/calendar 
>> test/java/util/TimeZone test/java/time test/java/util/Formatter 
>> test/closed/java/util/Calendar test/closed/java/util/TimeZone 
>> test/closed/java/text/Format/DateFormat - no failures
>>
>> Thank you,
>> Aleksej
>>
>> [1] Bug: https://bugs.openjdk.java.net/browse/JDK-8059206
>> [2] Webrev: http://cr.openjdk.java.net/~aefimov/8059206/9/webrev.00
>


From naoto.sato at oracle.com  Thu Oct 30 16:54:11 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 30 Oct 2014 09:54:11 -0700
Subject: <i18n dev> Modular locale data
Message-ID: <54526D33.2060704@oracle.com>

Hello,

In the upcoming JDK9, we are planning to modularize the locale data 
available in the JDK for the JEP 200: The Modular JDK [1]. One of the 
open issues of the JEP is this:

"The jdk.localedata module may eventually be split into multiple, 
region-specific modules for added flexibility in configuration."

In JDK8, we include English locales into rt.jar, and the rest into 
localedata.jar in the extension directory. This is OK but does not give 
much flexibility on smaller environments, such as SE Embedded, where 
they just use rt.jar and English locales are only available ones.

So here we are soliciting ideas on how to divide the locale data into 
smaller entities, as the modular JDK would make it possible. Here are 
some possible choices with pros/cons:

- Per language: Most straightforward choice, but it would create too 
many modules.
- Per geological area: Smaller number of modules. Mapping geos into 
locales may be complicated.
- Latin vs. other scripts.
- English vs. the rest: current implementation. Not flexible, but 
practical/performant for the JDK full profile.

[1]: http://openjdk.java.net/jeps/200

Naoto

From magnus.ihse.bursie at oracle.com  Fri Oct 31 13:21:52 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 31 Oct 2014 14:21:52 +0100
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <54495F6C.5020204@oracle.com>
References: <544198AC.8050806@oracle.com> <54495F6C.5020204@oracle.com>
Message-ID: <54538CF0.3080701@oracle.com>

On 2014-10-23 22:05, Naoto Sato wrote:
> I revised the fix according to the suggestions I got. The main change 
> is to rename the name of the locale data modules. Now we have two as 
> follows:
>
> - jdk.localedata.classic: Legacy locale data
> - jdk.localedata.cldr: CLDR locale data
>
> Revised webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/8061382/webrev.01/

I have looked at the makefile changes only, and they look good.

However, when doing so I noticed some parts that could do with further 
cleaning up. This is not something I'm suggesting you do in this fix, 
but I'm hijacking this thread to hear if you have some input on these 
issues. :-)

1) I do not like how gensrc/Gensrc-jdk.localedata.cldr.gmk is included 
in CreateJars.gmk -- it should not be there. The reason is to get the 
CLDRVERSION which is defined in that file. I'd like to address that, 
either by extracting the CLDRVERSION out into a separate file that can 
be included more sanely into both the Gensrc file and CreateJars, or by 
some other solution. It seems that the actual version string is only 
used in CreateJars.gmk, in Gensrc-jdk.localedata.cldr.gmk it is only 
used to create the path to the cldr files. However, there is currently 
only a single directory that could possibly be used as the src 
directory. As long as that is the case, the CLDRVERSION is not strictly 
needed in the Gensrc file. Is this code some remnant of an old system 
that was supposed to support multiple versions? If so, do you think it 
is likely to come back, or can we safely assume that the code base only 
has a single version of cldr checked in at a time?

2) The comment at the EXCLUDE_FILE says:
  # Exclude BreakIterator classes that are just used in compile process 
to generate
  # data files and shouldn't go in the product
Normally, java code that is only used during build, is not stored in the 
src tree, but in make/src instead. Do you think it is possible to move 
the BreakIteratorRules_th.java there, so we can skip the explicit exclude?

/Magnus

From erik.joelsson at oracle.com  Fri Oct 31 13:32:26 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 31 Oct 2014 14:32:26 +0100
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <54538CF0.3080701@oracle.com>
References: <544198AC.8050806@oracle.com> <54495F6C.5020204@oracle.com>
	<54538CF0.3080701@oracle.com>
Message-ID: <54538F6A.9090902@oracle.com>


On 2014-10-31 14:21, Magnus Ihse Bursie wrote:
>
> 1) I do not like how gensrc/Gensrc-jdk.localedata.cldr.gmk is included 
> in CreateJars.gmk -- it should not be there. The reason is to get the 
> CLDRVERSION which is defined in that file. I'd like to address that, 
> either by extracting the CLDRVERSION out into a separate file that can 
> be included more sanely into both the Gensrc file and CreateJars, or 
> by some other solution. It seems that the actual version string is 
> only used in CreateJars.gmk, in Gensrc-jdk.localedata.cldr.gmk it is 
> only used to create the path to the cldr files. However, there is 
> currently only a single directory that could possibly be used as the 
> src directory. As long as that is the case, the CLDRVERSION is not 
> strictly needed in the Gensrc file. Is this code some remnant of an 
> old system that was supposed to support multiple versions? If so, do 
> you think it is likely to come back, or can we safely assume that the 
> code base only has a single version of cldr checked in at a time?
>
CreateJars.gmk is soon going away completely (in Jigsaw M2) and the 
replacement has no need for knowing CLDRVERSION, so this will soon be fixed.
> 2) The comment at the EXCLUDE_FILE says:
>  # Exclude BreakIterator classes that are just used in compile process 
> to generate
>  # data files and shouldn't go in the product
> Normally, java code that is only used during build, is not stored in 
> the src tree, but in make/src instead. Do you think it is possible to 
> move the BreakIteratorRules_th.java there, so we can skip the explicit 
> exclude?
>
This is a cleanup I would like to get done.

/Erik


From naoto.sato at oracle.com  Fri Oct 31 17:22:48 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 31 Oct 2014 10:22:48 -0700
Subject: <i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE
	locale data
In-Reply-To: <54538F6A.9090902@oracle.com>
References: <544198AC.8050806@oracle.com> <54495F6C.5020204@oracle.com>
	<54538CF0.3080701@oracle.com> <54538F6A.9090902@oracle.com>
Message-ID: <5453C568.5070706@oracle.com>

Thank you, Magnus, Erik for the comments. My comments inline below:

On 10/31/14, 6:32 AM, Erik Joelsson wrote:
>
> On 2014-10-31 14:21, Magnus Ihse Bursie wrote:
>>
>> 1) I do not like how gensrc/Gensrc-jdk.localedata.cldr.gmk is included
>> in CreateJars.gmk -- it should not be there. The reason is to get the
>> CLDRVERSION which is defined in that file. I'd like to address that,
>> either by extracting the CLDRVERSION out into a separate file that can
>> be included more sanely into both the Gensrc file and CreateJars, or
>> by some other solution. It seems that the actual version string is
>> only used in CreateJars.gmk, in Gensrc-jdk.localedata.cldr.gmk it is
>> only used to create the path to the cldr files. However, there is
>> currently only a single directory that could possibly be used as the
>> src directory. As long as that is the case, the CLDRVERSION is not
>> strictly needed in the Gensrc file. Is this code some remnant of an
>> old system that was supposed to support multiple versions? If so, do
>> you think it is likely to come back, or can we safely assume that the
>> code base only has a single version of cldr checked in at a time?
>>
> CreateJars.gmk is soon going away completely (in Jigsaw M2) and the
> replacement has no need for knowing CLDRVERSION, so this will soon be
> fixed.

As to the CLDRVERSION, my intention was to embed the CLDR version number 
in the source path for easier lookup of the CLDR version number (CLDR 
data are merely a set of .xml files where no version is associated by 
itself).

As to the multiple CLDR releases support, I don't think of that in the 
near future.

>> 2) The comment at the EXCLUDE_FILE says:
>>  # Exclude BreakIterator classes that are just used in compile process
>> to generate
>>  # data files and shouldn't go in the product
>> Normally, java code that is only used during build, is not stored in
>> the src tree, but in make/src instead. Do you think it is possible to
>> move the BreakIteratorRules_th.java there, so we can skip the explicit
>> exclude?
>>
> This is a cleanup I would like to get done.

Ditto.

Naoto