From yong.huang at oracle.com  Sun Aug  4 19:46:58 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Mon, 05 Aug 2013 10:46:58 +0800
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number 156
Message-ID: <51FF1222.1020803@oracle.com>

Hello,

This is the review request for 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121

Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/

thanks,
Yong

From naoto.sato at oracle.com  Mon Aug  5 11:32:43 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 05 Aug 2013 11:32:43 -0700
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <51FF1222.1020803@oracle.com>
References: <51FF1222.1020803@oracle.com>
Message-ID: <51FFEFCB.90105@oracle.com>

At the moment, they still use LVL for their currency, so I think the 
transition logic needs to be placed.

Naoto

On 8/4/13 7:46 PM, Yong Huang wrote:
> Hello,
>
> This is the review request for
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>
> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>
> thanks,
> Yong


From yong.huang at oracle.com  Mon Aug  5 19:44:47 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Tue, 06 Aug 2013 10:44:47 +0800
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <51FFEFCB.90105@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
Message-ID: <5200631F.2030903@oracle.com>

Hi Naoto,

To place the transition logic, do you mean I need to add comments in 
source file or do I just need to explain it in this email thread?

The currency change will take place in January 2014 and Java 8 is still 
not released at that time. So when Java 8 is released, the currency of 
LV will already be changed. If I fix the bug after Jan 2014, it will be 
near the release date of Java 8 and maybe only stopper bug is allowed to 
fixed at that time.

thanks,
Yong

On 2013/8/6 2:32, Naoto Sato wrote:
> At the moment, they still use LVL for their currency, so I think the 
> transition logic needs to be placed.
>
> Naoto
>
> On 8/4/13 7:46 PM, Yong Huang wrote:
>> Hello,
>>
>> This is the review request for
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>
>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>
>> thanks,
>> Yong
>


From masayoshi.okutsu at oracle.com  Tue Aug  6 02:09:15 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 06 Aug 2013 18:09:15 +0900
Subject: <i18n dev> [8] Request for review: 8015986 : Incorrect Localization
	of HijrahChronology
Message-ID: <5200BD3B.8080506@oracle.com>

Hi,

Please review the following fix:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015986

This fix is a workaround until JDK incorporates the chronology name and 
its translations from CLDR. The English and Arabic names for the JRE 
resources are preferred names given by Oracle globalization experts.

Webrev:
http://cr.openjdk.java.net/~okutsu/8/8015986/webrev.00/

Thanks,
Masayoshi


From masayoshi.okutsu at oracle.com  Tue Aug  6 02:13:00 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 06 Aug 2013 18:13:00 +0900
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <5200631F.2030903@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com>
Message-ID: <5200BE1C.7060509@oracle.com>

Hi Yong,

I think it's OK to use EUR without specifying the transition date-time 
for JDK 8.

Thanks,
Masayoshi

On 8/6/2013 11:44 AM, Yong Huang wrote:
> Hi Naoto,
>
> To place the transition logic, do you mean I need to add comments in 
> source file or do I just need to explain it in this email thread?
>
> The currency change will take place in January 2014 and Java 8 is 
> still not released at that time. So when Java 8 is released, the 
> currency of LV will already be changed. If I fix the bug after Jan 
> 2014, it will be near the release date of Java 8 and maybe only 
> stopper bug is allowed to fixed at that time.
>
> thanks,
> Yong
>
> On 2013/8/6 2:32, Naoto Sato wrote:
>> At the moment, they still use LVL for their currency, so I think the 
>> transition logic needs to be placed.
>>
>> Naoto
>>
>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>> Hello,
>>>
>>> This is the review request for
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>
>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>
>>> thanks,
>>> Yong
>>
>


From naoto.sato at oracle.com  Tue Aug  6 09:45:20 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 06 Aug 2013 09:45:20 -0700
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <5200BE1C.7060509@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com> <5200BE1C.7060509@oracle.com>
Message-ID: <52012820.4070307@oracle.com>

Yong,

There already is a logic in Currency class to deal with such a future 
transition nicely. That's what I meant.

Masayoshi,

Then it will be a regression till 1/1/2014. I don't see any problem 
using the transition logic here, IMO.

Naoto

On 8/6/13 2:13 AM, Masayoshi Okutsu wrote:
> Hi Yong,
>
> I think it's OK to use EUR without specifying the transition date-time
> for JDK 8.
>
> Thanks,
> Masayoshi
>
> On 8/6/2013 11:44 AM, Yong Huang wrote:
>> Hi Naoto,
>>
>> To place the transition logic, do you mean I need to add comments in
>> source file or do I just need to explain it in this email thread?
>>
>> The currency change will take place in January 2014 and Java 8 is
>> still not released at that time. So when Java 8 is released, the
>> currency of LV will already be changed. If I fix the bug after Jan
>> 2014, it will be near the release date of Java 8 and maybe only
>> stopper bug is allowed to fixed at that time.
>>
>> thanks,
>> Yong
>>
>> On 2013/8/6 2:32, Naoto Sato wrote:
>>> At the moment, they still use LVL for their currency, so I think the
>>> transition logic needs to be placed.
>>>
>>> Naoto
>>>
>>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>>> Hello,
>>>>
>>>> This is the review request for
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>>
>>>> thanks,
>>>> Yong
>>>
>>
>


From naoto.sato at oracle.com  Tue Aug  6 13:17:47 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 06 Aug 2013 13:17:47 -0700
Subject: <i18n dev> [8] Request for review: 8015986 : Incorrect
 Localization of HijrahChronology
In-Reply-To: <5200BD3B.8080506@oracle.com>
References: <5200BD3B.8080506@oracle.com>
Message-ID: <520159EB.1060300@oracle.com>

Looks good to me.

Naoto

On 8/6/13 2:09 AM, Masayoshi Okutsu wrote:
> Hi,
>
> Please review the following fix:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015986
>
> This fix is a workaround until JDK incorporates the chronology name and
> its translations from CLDR. The English and Arabic names for the JRE
> resources are preferred names given by Oracle globalization experts.
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/8/8015986/webrev.00/
>
> Thanks,
> Masayoshi
>


From yong.huang at oracle.com  Tue Aug  6 20:16:43 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Wed, 07 Aug 2013 11:16:43 +0800
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <52012820.4070307@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com> <5200BE1C.7060509@oracle.com>
	<52012820.4070307@oracle.com>
Message-ID: <5201BC1B.8060903@oracle.com>

Thanks for all the comments.

I will change LV=LVL to LV=LVL;2013-12-31-22-00-00;EUR in 
CurrencyData.properties and also modify the corresponding regression test.

thanks,
Yong


On 2013/8/7 0:45, Naoto Sato wrote:
> Yong,
>
> There already is a logic in Currency class to deal with such a future 
> transition nicely. That's what I meant.
>
> Masayoshi,
>
> Then it will be a regression till 1/1/2014. I don't see any problem 
> using the transition logic here, IMO.
>
> Naoto
>
> On 8/6/13 2:13 AM, Masayoshi Okutsu wrote:
>> Hi Yong,
>>
>> I think it's OK to use EUR without specifying the transition date-time
>> for JDK 8.
>>
>> Thanks,
>> Masayoshi
>>
>> On 8/6/2013 11:44 AM, Yong Huang wrote:
>>> Hi Naoto,
>>>
>>> To place the transition logic, do you mean I need to add comments in
>>> source file or do I just need to explain it in this email thread?
>>>
>>> The currency change will take place in January 2014 and Java 8 is
>>> still not released at that time. So when Java 8 is released, the
>>> currency of LV will already be changed. If I fix the bug after Jan
>>> 2014, it will be near the release date of Java 8 and maybe only
>>> stopper bug is allowed to fixed at that time.
>>>
>>> thanks,
>>> Yong
>>>
>>> On 2013/8/6 2:32, Naoto Sato wrote:
>>>> At the moment, they still use LVL for their currency, so I think the
>>>> transition logic needs to be placed.
>>>>
>>>> Naoto
>>>>
>>>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>>>> Hello,
>>>>>
>>>>> This is the review request for
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>>>
>>>>> thanks,
>>>>> Yong
>>>>
>>>
>>
>


From xueming.shen at oracle.com  Thu Aug  8 22:54:56 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 08 Aug 2013 22:54:56 -0700
Subject: <i18n dev> RFR  JDK-8020054: (tz) Support tzdata2013d
In-Reply-To: <518ACFB3.5030000@oracle.com>
References: <518ACFB3.5030000@oracle.com>
Message-ID: <52048430.3050300@oracle.com>

Hi,

Please help review the proposed change to update the tz data
in JDK8 from 2013c to 2013d.

http://cr.openjdk.java.net/~sherman/8020054/webrev
http://cr.openjdk.java.net/~sherman/8020054/closed

Tests list below have been run and passed
(except java/time/tck/java/time/chrono/TCKChronology.java with error
expected [Hijrah-umalqura] but found [Islamic Umm al-Qura Calendar], which
I would assume has nothing to do with tz change)

java/util/TimeZone
java/util/Calendar
java/util/Formatter
java/time
closed/java/util/TimeZone
closed/java/util/Calendar

Thanks!
-Sherman

From yuka.kamiya at oracle.com  Fri Aug  9 00:20:51 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 09 Aug 2013 16:20:51 +0900
Subject: <i18n dev> RFR  JDK-8020054: (tz) Support tzdata2013d
In-Reply-To: <52048430.3050300@oracle.com>
References: <518ACFB3.5030000@oracle.com> <52048430.3050300@oracle.com>
Message-ID: <52049853.3050903@oracle.com>

Hi Sherman,

The fix looks good to me.

Thanks,
--
Yuka


(2013/08/09 14:54), Xueming Shen wrote:
> Hi,
>
> Please help review the proposed change to update the tz data
> in JDK8 from 2013c to 2013d.
>
> http://cr.openjdk.java.net/~sherman/8020054/webrev
> http://cr.openjdk.java.net/~sherman/8020054/closed
>
> Tests list below have been run and passed
> (except java/time/tck/java/time/chrono/TCKChronology.java with error
> expected [Hijrah-umalqura] but found [Islamic Umm al-Qura Calendar], which
> I would assume has nothing to do with tz change)
>
> java/util/TimeZone
> java/util/Calendar
> java/util/Formatter
> java/time
> closed/java/util/TimeZone
> closed/java/util/Calendar
>
> Thanks!
> -Sherman


From sean.coffey at oracle.com  Fri Aug  9 01:36:40 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Fri, 09 Aug 2013 09:36:40 +0100
Subject: <i18n dev> RFR  JDK-8020054: (tz) Support tzdata2013d
In-Reply-To: <52049853.3050903@oracle.com>
References: <518ACFB3.5030000@oracle.com> <52048430.3050300@oracle.com>
	<52049853.3050903@oracle.com>
Message-ID: <5204AA18.1010008@oracle.com>

Looks fine to me also Sherman. On a side note, we should look at 
migrating some closed TZ tests to open repo. I'm not sure why that 
wasn't done from first day.

regards,
Sean.

On 09/08/2013 08:20, Yuka Kamiya wrote:
> Hi Sherman,
>
> The fix looks good to me.
>
> Thanks,
> -- 
> Yuka
>
>
> (2013/08/09 14:54), Xueming Shen wrote:
>> Hi,
>>
>> Please help review the proposed change to update the tz data
>> in JDK8 from 2013c to 2013d.
>>
>> http://cr.openjdk.java.net/~sherman/8020054/webrev
>> http://cr.openjdk.java.net/~sherman/8020054/closed
>>
>> Tests list below have been run and passed
>> (except java/time/tck/java/time/chrono/TCKChronology.java with error
>> expected [Hijrah-umalqura] but found [Islamic Umm al-Qura Calendar], 
>> which
>> I would assume has nothing to do with tz change)
>>
>> java/util/TimeZone
>> java/util/Calendar
>> java/util/Formatter
>> java/time
>> closed/java/util/TimeZone
>> closed/java/util/Calendar
>>
>> Thanks!
>> -Sherman
>


From yong.huang at oracle.com  Mon Aug 12 01:49:16 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Mon, 12 Aug 2013 16:49:16 +0800
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <52012820.4070307@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com> <5200BE1C.7060509@oracle.com>
	<52012820.4070307@oracle.com>
Message-ID: <5208A18C.7050400@oracle.com>

Hello All,

The updated webrev is at 
http://cr.openjdk.java.net/~yhuang/8021121/webrev.01/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121

The transition logic of currency of lv_LV is placed in source file and 
regression test.

thanks,
Yong


On 2013/8/7 0:45, Naoto Sato wrote:
> Yong,
>
> There already is a logic in Currency class to deal with such a future 
> transition nicely. That's what I meant.
>
> Masayoshi,
>
> Then it will be a regression till 1/1/2014. I don't see any problem 
> using the transition logic here, IMO.
>
> Naoto
>
> On 8/6/13 2:13 AM, Masayoshi Okutsu wrote:
>> Hi Yong,
>>
>> I think it's OK to use EUR without specifying the transition date-time
>> for JDK 8.
>>
>> Thanks,
>> Masayoshi
>>
>> On 8/6/2013 11:44 AM, Yong Huang wrote:
>>> Hi Naoto,
>>>
>>> To place the transition logic, do you mean I need to add comments in
>>> source file or do I just need to explain it in this email thread?
>>>
>>> The currency change will take place in January 2014 and Java 8 is
>>> still not released at that time. So when Java 8 is released, the
>>> currency of LV will already be changed. If I fix the bug after Jan
>>> 2014, it will be near the release date of Java 8 and maybe only
>>> stopper bug is allowed to fixed at that time.
>>>
>>> thanks,
>>> Yong
>>>
>>> On 2013/8/6 2:32, Naoto Sato wrote:
>>>> At the moment, they still use LVL for their currency, so I think the
>>>> transition logic needs to be placed.
>>>>
>>>> Naoto
>>>>
>>>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>>>> Hello,
>>>>>
>>>>> This is the review request for
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>>>
>>>>> thanks,
>>>>> Yong
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Mon Aug 12 15:03:05 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 12 Aug 2013 15:03:05 -0700
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <5208A18C.7050400@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com> <5200BE1C.7060509@oracle.com>
	<52012820.4070307@oracle.com> <5208A18C.7050400@oracle.com>
Message-ID: <52095B99.1020804@oracle.com>

Hi Yong,

Does test/sun/text/resources/LocaleDataTest work before/after the 
transition date? I know test/java/util/Currency tests work with the 
transition, but don't think the LocaleDataTest test works.

Naoto

On 8/12/13 1:49 AM, Yong Huang wrote:
> Hello All,
>
> The updated webrev is at
> http://cr.openjdk.java.net/~yhuang/8021121/webrev.01/
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>
> The transition logic of currency of lv_LV is placed in source file and
> regression test.
>
> thanks,
> Yong
>
>
> On 2013/8/7 0:45, Naoto Sato wrote:
>> Yong,
>>
>> There already is a logic in Currency class to deal with such a future
>> transition nicely. That's what I meant.
>>
>> Masayoshi,
>>
>> Then it will be a regression till 1/1/2014. I don't see any problem
>> using the transition logic here, IMO.
>>
>> Naoto
>>
>> On 8/6/13 2:13 AM, Masayoshi Okutsu wrote:
>>> Hi Yong,
>>>
>>> I think it's OK to use EUR without specifying the transition date-time
>>> for JDK 8.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 8/6/2013 11:44 AM, Yong Huang wrote:
>>>> Hi Naoto,
>>>>
>>>> To place the transition logic, do you mean I need to add comments in
>>>> source file or do I just need to explain it in this email thread?
>>>>
>>>> The currency change will take place in January 2014 and Java 8 is
>>>> still not released at that time. So when Java 8 is released, the
>>>> currency of LV will already be changed. If I fix the bug after Jan
>>>> 2014, it will be near the release date of Java 8 and maybe only
>>>> stopper bug is allowed to fixed at that time.
>>>>
>>>> thanks,
>>>> Yong
>>>>
>>>> On 2013/8/6 2:32, Naoto Sato wrote:
>>>>> At the moment, they still use LVL for their currency, so I think the
>>>>> transition logic needs to be placed.
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>>>>> Hello,
>>>>>>
>>>>>> This is the review request for
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>>>>
>>>>>> thanks,
>>>>>> Yong
>>>>>
>>>>
>>>
>>
>


From yong.huang at oracle.com  Mon Aug 12 19:40:16 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Tue, 13 Aug 2013 10:40:16 +0800
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <52095B99.1020804@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com> <5200BE1C.7060509@oracle.com>
	<52012820.4070307@oracle.com> <5208A18C.7050400@oracle.com>
	<52095B99.1020804@oracle.com>
Message-ID: <52099C90.1080003@oracle.com>

Hi Naoto,

It's to add the EUR symbol in CurrencyNames_lv_LV.properties, but the 
old symbol LVL=Ls is not removed. LocaleDataTest is to check that EUR 
symbol is in CurrencyNames_lv_LV.properties. It works with the 
transition because the EUR symbol is in lv_LV before the transition and 
will not be removed after the transition.

LVL=Ls will remain in the file CurrencyNames_lv_LV.properties after the 
transition but will not bring any regression.

thanks,
Yong


On 2013/8/13 6:03, Naoto Sato wrote:
> Hi Yong,
>
> Does test/sun/text/resources/LocaleDataTest work before/after the 
> transition date? I know test/java/util/Currency tests work with the 
> transition, but don't think the LocaleDataTest test works.
>
> Naoto
>
> On 8/12/13 1:49 AM, Yong Huang wrote:
>> Hello All,
>>
>> The updated webrev is at
>> http://cr.openjdk.java.net/~yhuang/8021121/webrev.01/
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>
>> The transition logic of currency of lv_LV is placed in source file and
>> regression test.
>>
>> thanks,
>> Yong
>>
>>
>> On 2013/8/7 0:45, Naoto Sato wrote:
>>> Yong,
>>>
>>> There already is a logic in Currency class to deal with such a future
>>> transition nicely. That's what I meant.
>>>
>>> Masayoshi,
>>>
>>> Then it will be a regression till 1/1/2014. I don't see any problem
>>> using the transition logic here, IMO.
>>>
>>> Naoto
>>>
>>> On 8/6/13 2:13 AM, Masayoshi Okutsu wrote:
>>>> Hi Yong,
>>>>
>>>> I think it's OK to use EUR without specifying the transition date-time
>>>> for JDK 8.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 8/6/2013 11:44 AM, Yong Huang wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> To place the transition logic, do you mean I need to add comments in
>>>>> source file or do I just need to explain it in this email thread?
>>>>>
>>>>> The currency change will take place in January 2014 and Java 8 is
>>>>> still not released at that time. So when Java 8 is released, the
>>>>> currency of LV will already be changed. If I fix the bug after Jan
>>>>> 2014, it will be near the release date of Java 8 and maybe only
>>>>> stopper bug is allowed to fixed at that time.
>>>>>
>>>>> thanks,
>>>>> Yong
>>>>>
>>>>> On 2013/8/6 2:32, Naoto Sato wrote:
>>>>>> At the moment, they still use LVL for their currency, so I think the
>>>>>> transition logic needs to be placed.
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> This is the review request for
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>>>>>
>>>>>>> thanks,
>>>>>>> Yong
>>>>>>
>>>>>
>>>>
>>>
>>
>


From yong.huang at oracle.com  Mon Aug 12 19:47:27 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Tue, 13 Aug 2013 10:47:27 +0800
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <52099C90.1080003@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com> <5200BE1C.7060509@oracle.com>
	<52012820.4070307@oracle.com> <5208A18C.7050400@oracle.com>
	<52095B99.1020804@oracle.com> <52099C90.1080003@oracle.com>
Message-ID: <52099E3F.20005@oracle.com>


On 2013/8/13 10:40, Yong Huang wrote:
> Hi Naoto,
>
> It's to add the EUR symbol in CurrencyNames_lv_LV.properties, but the 
> old symbol LVL=Ls is not removed. LocaleDataTest is to check that EUR 
> symbol is in CurrencyNames_lv_LV.properties. It works with the 
> transition because the EUR symbol is in lv_LV before the transition 
> and will not be removed after the transition.
>
> LVL=Ls will remain in the file CurrencyNames_lv_LV.properties after 
> the transition but will not bring any regression.

There is no check of CurrencyNames/lv_LV/LVL=Ls in current 
LocaleDataTest. So after the transition, there will not be any regression.

thanks,
Yong
>
> thanks,
> Yong
>
>
> On 2013/8/13 6:03, Naoto Sato wrote:
>> Hi Yong,
>>
>> Does test/sun/text/resources/LocaleDataTest work before/after the 
>> transition date? I know test/java/util/Currency tests work with the 
>> transition, but don't think the LocaleDataTest test works.
>>
>> Naoto
>>
>> On 8/12/13 1:49 AM, Yong Huang wrote:
>>> Hello All,
>>>
>>> The updated webrev is at
>>> http://cr.openjdk.java.net/~yhuang/8021121/webrev.01/
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>
>>> The transition logic of currency of lv_LV is placed in source file and
>>> regression test.
>>>
>>> thanks,
>>> Yong
>>>
>>>
>>> On 2013/8/7 0:45, Naoto Sato wrote:
>>>> Yong,
>>>>
>>>> There already is a logic in Currency class to deal with such a future
>>>> transition nicely. That's what I meant.
>>>>
>>>> Masayoshi,
>>>>
>>>> Then it will be a regression till 1/1/2014. I don't see any problem
>>>> using the transition logic here, IMO.
>>>>
>>>> Naoto
>>>>
>>>> On 8/6/13 2:13 AM, Masayoshi Okutsu wrote:
>>>>> Hi Yong,
>>>>>
>>>>> I think it's OK to use EUR without specifying the transition 
>>>>> date-time
>>>>> for JDK 8.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 8/6/2013 11:44 AM, Yong Huang wrote:
>>>>>> Hi Naoto,
>>>>>>
>>>>>> To place the transition logic, do you mean I need to add comments in
>>>>>> source file or do I just need to explain it in this email thread?
>>>>>>
>>>>>> The currency change will take place in January 2014 and Java 8 is
>>>>>> still not released at that time. So when Java 8 is released, the
>>>>>> currency of LV will already be changed. If I fix the bug after Jan
>>>>>> 2014, it will be near the release date of Java 8 and maybe only
>>>>>> stopper bug is allowed to fixed at that time.
>>>>>>
>>>>>> thanks,
>>>>>> Yong
>>>>>>
>>>>>> On 2013/8/6 2:32, Naoto Sato wrote:
>>>>>>> At the moment, they still use LVL for their currency, so I think 
>>>>>>> the
>>>>>>> transition logic needs to be placed.
>>>>>>>
>>>>>>> Naoto
>>>>>>>
>>>>>>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> This is the review request for
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>>>>>
>>>>>>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Yong
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Tue Aug 13 09:24:33 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 13 Aug 2013 09:24:33 -0700
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <52099C90.1080003@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com> <5200BE1C.7060509@oracle.com>
	<52012820.4070307@oracle.com> <5208A18C.7050400@oracle.com>
	<52095B99.1020804@oracle.com> <52099C90.1080003@oracle.com>
Message-ID: <520A5DC1.10207@oracle.com>

On 8/12/13 7:40 PM, Yong Huang wrote:
> Hi Naoto,
>
> It's to add the EUR symbol in CurrencyNames_lv_LV.properties, but the
> old symbol LVL=Ls is not removed. LocaleDataTest is to check that EUR
> symbol is in CurrencyNames_lv_LV.properties. It works with the
> transition because the EUR symbol is in lv_LV before the transition and
> will not be removed after the transition.

You meant "Ls" here, right?

>
> LVL=Ls will remain in the file CurrencyNames_lv_LV.properties after the
> transition but will not bring any regression.

OK, looks good to me.

Naoto

>
> thanks,
> Yong
>
>
> On 2013/8/13 6:03, Naoto Sato wrote:
>> Hi Yong,
>>
>> Does test/sun/text/resources/LocaleDataTest work before/after the
>> transition date? I know test/java/util/Currency tests work with the
>> transition, but don't think the LocaleDataTest test works.
>>
>> Naoto
>>
>> On 8/12/13 1:49 AM, Yong Huang wrote:
>>> Hello All,
>>>
>>> The updated webrev is at
>>> http://cr.openjdk.java.net/~yhuang/8021121/webrev.01/
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>
>>> The transition logic of currency of lv_LV is placed in source file and
>>> regression test.
>>>
>>> thanks,
>>> Yong
>>>
>>>
>>> On 2013/8/7 0:45, Naoto Sato wrote:
>>>> Yong,
>>>>
>>>> There already is a logic in Currency class to deal with such a future
>>>> transition nicely. That's what I meant.
>>>>
>>>> Masayoshi,
>>>>
>>>> Then it will be a regression till 1/1/2014. I don't see any problem
>>>> using the transition logic here, IMO.
>>>>
>>>> Naoto
>>>>
>>>> On 8/6/13 2:13 AM, Masayoshi Okutsu wrote:
>>>>> Hi Yong,
>>>>>
>>>>> I think it's OK to use EUR without specifying the transition date-time
>>>>> for JDK 8.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 8/6/2013 11:44 AM, Yong Huang wrote:
>>>>>> Hi Naoto,
>>>>>>
>>>>>> To place the transition logic, do you mean I need to add comments in
>>>>>> source file or do I just need to explain it in this email thread?
>>>>>>
>>>>>> The currency change will take place in January 2014 and Java 8 is
>>>>>> still not released at that time. So when Java 8 is released, the
>>>>>> currency of LV will already be changed. If I fix the bug after Jan
>>>>>> 2014, it will be near the release date of Java 8 and maybe only
>>>>>> stopper bug is allowed to fixed at that time.
>>>>>>
>>>>>> thanks,
>>>>>> Yong
>>>>>>
>>>>>> On 2013/8/6 2:32, Naoto Sato wrote:
>>>>>>> At the moment, they still use LVL for their currency, so I think the
>>>>>>> transition logic needs to be placed.
>>>>>>>
>>>>>>> Naoto
>>>>>>>
>>>>>>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> This is the review request for
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>>>>>
>>>>>>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Yong
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From yong.huang at oracle.com  Tue Aug 13 19:13:00 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Wed, 14 Aug 2013 10:13:00 +0800
Subject: <i18n dev> Review Request - 8021121: ISO 4217 Amendment Number
 156
In-Reply-To: <520A5DC1.10207@oracle.com>
References: <51FF1222.1020803@oracle.com> <51FFEFCB.90105@oracle.com>
	<5200631F.2030903@oracle.com> <5200BE1C.7060509@oracle.com>
	<52012820.4070307@oracle.com> <5208A18C.7050400@oracle.com>
	<52095B99.1020804@oracle.com> <52099C90.1080003@oracle.com>
	<520A5DC1.10207@oracle.com>
Message-ID: <520AE7AC.30800@oracle.com>


On 2013/8/14 0:24, Naoto Sato wrote:
> On 8/12/13 7:40 PM, Yong Huang wrote:
>> Hi Naoto,
>>
>> It's to add the EUR symbol in CurrencyNames_lv_LV.properties, but the
>> old symbol LVL=Ls is not removed. LocaleDataTest is to check that EUR
>> symbol is in CurrencyNames_lv_LV.properties. It works with the
>> transition because the EUR symbol is in lv_LV before the transition and
>> will not be removed after the transition.
>
> You meant "Ls" here, right?

Yes, both EUR symbol and "Ls" will remain in the resource file after the 
transition.

thanks for the review,
Yong
>
>>
>> LVL=Ls will remain in the file CurrencyNames_lv_LV.properties after the
>> transition but will not bring any regression.
>
> OK, looks good to me.
>
> Naoto
>
>>
>> thanks,
>> Yong
>>
>>
>> On 2013/8/13 6:03, Naoto Sato wrote:
>>> Hi Yong,
>>>
>>> Does test/sun/text/resources/LocaleDataTest work before/after the
>>> transition date? I know test/java/util/Currency tests work with the
>>> transition, but don't think the LocaleDataTest test works.
>>>
>>> Naoto
>>>
>>> On 8/12/13 1:49 AM, Yong Huang wrote:
>>>> Hello All,
>>>>
>>>> The updated webrev is at
>>>> http://cr.openjdk.java.net/~yhuang/8021121/webrev.01/
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>
>>>> The transition logic of currency of lv_LV is placed in source file and
>>>> regression test.
>>>>
>>>> thanks,
>>>> Yong
>>>>
>>>>
>>>> On 2013/8/7 0:45, Naoto Sato wrote:
>>>>> Yong,
>>>>>
>>>>> There already is a logic in Currency class to deal with such a future
>>>>> transition nicely. That's what I meant.
>>>>>
>>>>> Masayoshi,
>>>>>
>>>>> Then it will be a regression till 1/1/2014. I don't see any problem
>>>>> using the transition logic here, IMO.
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 8/6/13 2:13 AM, Masayoshi Okutsu wrote:
>>>>>> Hi Yong,
>>>>>>
>>>>>> I think it's OK to use EUR without specifying the transition 
>>>>>> date-time
>>>>>> for JDK 8.
>>>>>>
>>>>>> Thanks,
>>>>>> Masayoshi
>>>>>>
>>>>>> On 8/6/2013 11:44 AM, Yong Huang wrote:
>>>>>>> Hi Naoto,
>>>>>>>
>>>>>>> To place the transition logic, do you mean I need to add 
>>>>>>> comments in
>>>>>>> source file or do I just need to explain it in this email thread?
>>>>>>>
>>>>>>> The currency change will take place in January 2014 and Java 8 is
>>>>>>> still not released at that time. So when Java 8 is released, the
>>>>>>> currency of LV will already be changed. If I fix the bug after Jan
>>>>>>> 2014, it will be near the release date of Java 8 and maybe only
>>>>>>> stopper bug is allowed to fixed at that time.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Yong
>>>>>>>
>>>>>>> On 2013/8/6 2:32, Naoto Sato wrote:
>>>>>>>> At the moment, they still use LVL for their currency, so I 
>>>>>>>> think the
>>>>>>>> transition logic needs to be placed.
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>>
>>>>>>>> On 8/4/13 7:46 PM, Yong Huang wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> This is the review request for
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021121
>>>>>>>>>
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~yhuang/8021121/webrev.00/
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Yong
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From Alan.Bateman at oracle.com  Mon Aug 26 01:40:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 26 Aug 2013 09:40:34 +0100
Subject: <i18n dev> Additional source to guess the local timezone ID on
	linux
In-Reply-To: <5217CF92.9030307@redhat.com>
References: <5217CF92.9030307@redhat.com>
Message-ID: <521B1482.104@oracle.com>


Including i18n-dev on this discussion because that is where this code is 
maintained.


On 23/08/2013 22:09, Omair Majid wrote:
> Hi,
>
> The algorithm that OpenJDK uses to guess the local timezone ID on Linux
> goes like this:
>
> 1. If TZ environment variable is set, use that
> 2. If /etc/timezone is readable, read the time zone from there
> 3. If /etc/localtime is a symlink, resolve that, and use the name to
> guess the time zone.
> 4. Scan /usr/share/zoneinfo for a file whose contents match the contents
> of /etc/localtime.
>
> Step 4 (if it is ever reached) is probably going to lead to incorrect
> results since there are a number of timezones that have the same
> zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
> sensible to me to try and use additional sources to guess the timezone
> ID before resorting to file content comparisons.
>
> The webrev adds a step between 2 and 3 that reads and parses
> /etc/sysconfig/clock to extract the timezone:
>
> http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/
>
> This file exists on some Red Hat Enterprise Linux (and derivative)
> distributions and contains contents that look this:
>
>> # The time zone of the system is defined by the contents of /etc/localtime.
>> # This file is only for evaluation by system-config-date, do not rely on its
>> # contents elsewhere.
>> ZONE="Europe/Zurich"
> With this, we should be able to identify the exact timezone ID.
>
> Thanks,
> Omair


From masayoshi.okutsu at oracle.com  Tue Aug 27 00:00:42 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 27 Aug 2013 16:00:42 +0900
Subject: <i18n dev> Additional source to guess the local timezone ID on
 linux
In-Reply-To: <521B1482.104@oracle.com>
References: <5217CF92.9030307@redhat.com> <521B1482.104@oracle.com>
Message-ID: <521C4E9A.3050902@oracle.com>

Hi Omair,

/etc/sysconfig/clock used to be supported, but it was removed in JDK 7. 
The problem is discussed in bug #6456628.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628

Have you tested your fix on all Red Hat-like distros, including some 
older releases, with all the time zone IDs?

Thanks,
Masayoshi

On 8/26/2013 5:40 PM, Alan Bateman wrote:
>
> Including i18n-dev on this discussion because that is where this code 
> is maintained.
>
>
> On 23/08/2013 22:09, Omair Majid wrote:
>> Hi,
>>
>> The algorithm that OpenJDK uses to guess the local timezone ID on Linux
>> goes like this:
>>
>> 1. If TZ environment variable is set, use that
>> 2. If /etc/timezone is readable, read the time zone from there
>> 3. If /etc/localtime is a symlink, resolve that, and use the name to
>> guess the time zone.
>> 4. Scan /usr/share/zoneinfo for a file whose contents match the contents
>> of /etc/localtime.
>>
>> Step 4 (if it is ever reached) is probably going to lead to incorrect
>> results since there are a number of timezones that have the same
>> zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
>> sensible to me to try and use additional sources to guess the timezone
>> ID before resorting to file content comparisons.
>>
>> The webrev adds a step between 2 and 3 that reads and parses
>> /etc/sysconfig/clock to extract the timezone:
>>
>> http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/ 
>>
>>
>> This file exists on some Red Hat Enterprise Linux (and derivative)
>> distributions and contains contents that look this:
>>
>>> # The time zone of the system is defined by the contents of 
>>> /etc/localtime.
>>> # This file is only for evaluation by system-config-date, do not 
>>> rely on its
>>> # contents elsewhere.
>>> ZONE="Europe/Zurich"
>> With this, we should be able to identify the exact timezone ID.
>>
>> Thanks,
>> Omair
>


From omajid at redhat.com  Tue Aug 27 06:59:56 2013
From: omajid at redhat.com (Omair Majid)
Date: Tue, 27 Aug 2013 09:59:56 -0400
Subject: <i18n dev> Additional source to guess the local timezone ID on
 linux
In-Reply-To: <521C4E9A.3050902@oracle.com>
References: <5217CF92.9030307@redhat.com> <521B1482.104@oracle.com>
	<521C4E9A.3050902@oracle.com>
Message-ID: <521CB0DC.7000701@redhat.com>

On 08/27/2013 03:00 AM, Masayoshi Okutsu wrote:
> /etc/sysconfig/clock used to be supported, but it was removed in JDK 7.
> The problem is discussed in bug #6456628.
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628

Thanks for that link. I did not know that this support was present in
JDK7 but then removed. I did not expect various distributions and
versions to have significant differences in that file either.

> Have you tested your fix on all Red Hat-like distros, including some
> older releases, with all the time zone IDs?

No, I tested this with Red Hat Enterprise Linux 6. I did not try it on
older versions. I know newer versions of Fedora don't ship with this
file any more.

Given that this support was removed because there were significant
differences in that file making maintenance harder in OpenJDK, I am
going to withdraw this patch.

Thanks to everyone who reviewed and commented on it.

Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681

From christian.beikov at gmail.com  Wed Aug 28 02:31:24 2013
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 28 Aug 2013 11:31:24 +0200
Subject: <i18n dev> java.util.Locale changes
In-Reply-To: <521DC21F.1090309@gmail.com>
References: <521DC21F.1090309@gmail.com>
Message-ID: <521DC36C.2050703@gmail.com>

Hello there,

I have just seen the changes you want to apply to java.util.Locale in 
JDK 8 and was wondering why you are forcing the use of a java.util.List 
in the lookup and filter methods. The related methods of 
java.util.Locale are

public static Locale lookup(List<Locale.LanguageRange> priorityList, 
Collection<Locale> locales)
public static String lookupTag(List<Locale.LanguageRange> priorityList, 
Collection<String> tags)
public static List<String> filterTags(List<Locale.LanguageRange> 
priorityList, Collection<String> tags)
public static List<String> filterTags(List<Locale.LanguageRange> 
priorityList, Collection<String> tags, Locale.FilteringMode mode)
public static List<Locale> filter(List<Locale.LanguageRange> 
priorityList, Collection<Locale> locales)
public static List<Locale> filter(List<Locale.LanguageRange> 
priorityList, Collection<Locale> locales, Locale.FilteringMode mode)

which could be changed to

public static Locale lookup(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<Locale> locales)
public static String lookupTag(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<String> tags)
public static List<String> filterTags(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<String> tags)
public static List<String> filterTags(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<String> tags, Locale.FilteringMode mode)
public static List<Locale> filter(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<Locale> locales)
public static List<Locale> filter(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<Locale> locales, Locale.FilteringMode mode)

The use of java.util.Collection would also be ok.
One could also use a java.util.Set or something similar to represent the 
language ranges. I just wanted to provide that feedback if anyone cares. 
I am also ok with java.util.List but since you are only relying on the 
iteration order of the priorityList I was curious about the reason.

-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*



From masayoshi.okutsu at oracle.com  Wed Aug 28 06:25:43 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 28 Aug 2013 22:25:43 +0900
Subject: <i18n dev> java.util.Locale changes
In-Reply-To: <521DC36C.2050703@gmail.com>
References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com>
Message-ID: <521DFA57.2060502@oracle.com>

(adding core-libs-dev)

Hi Christian,

RFC 4647 defines The Language Priority List [1]. The use of 
java.util.List would be a natural fit, which is the reason why List is 
used. But use of Iterable does work (as API design). The parameter name 
`priorityIterable' sounds a bit odd, though.

Does use of Iterable add much value to the API? (Please note that List 
is also used in Locale.LanguageRange.)

Thanks,
Masayoshi

[1] http://tools.ietf.org/html/rfc4647#section-2.3

On 2013/08/28 18:31, Christian Beikov wrote:
> Hello there,
>
> I have just seen the changes you want to apply to java.util.Locale in 
> JDK 8 and was wondering why you are forcing the use of a 
> java.util.List in the lookup and filter methods. The related methods 
> of java.util.Locale are
>
> public static Locale lookup(List<Locale.LanguageRange> priorityList, 
> Collection<Locale> locales)
> public static String lookupTag(List<Locale.LanguageRange> 
> priorityList, Collection<String> tags)
> public static List<String> filterTags(List<Locale.LanguageRange> 
> priorityList, Collection<String> tags)
> public static List<String> filterTags(List<Locale.LanguageRange> 
> priorityList, Collection<String> tags, Locale.FilteringMode mode)
> public static List<Locale> filter(List<Locale.LanguageRange> 
> priorityList, Collection<Locale> locales)
> public static List<Locale> filter(List<Locale.LanguageRange> 
> priorityList, Collection<Locale> locales, Locale.FilteringMode mode)
>
> which could be changed to
>
> public static Locale lookup(Iterable<Locale.LanguageRange> 
> priorityIterable, Collection<Locale> locales)
> public static String lookupTag(Iterable<Locale.LanguageRange> 
> priorityIterable, Collection<String> tags)
> public static List<String> filterTags(Iterable<Locale.LanguageRange> 
> priorityIterable, Collection<String> tags)
> public static List<String> filterTags(Iterable<Locale.LanguageRange> 
> priorityIterable, Collection<String> tags, Locale.FilteringMode mode)
> public static List<Locale> filter(Iterable<Locale.LanguageRange> 
> priorityIterable, Collection<Locale> locales)
> public static List<Locale> filter(Iterable<Locale.LanguageRange> 
> priorityIterable, Collection<Locale> locales, Locale.FilteringMode mode)
>
> The use of java.util.Collection would also be ok.
> One could also use a java.util.Set or something similar to represent 
> the language ranges. I just wanted to provide that feedback if anyone 
> cares. I am also ok with java.util.List but since you are only relying 
> on the iteration order of the priorityList I was curious about the 
> reason.
>


From gnu.andrew at redhat.com  Wed Aug 28 06:26:07 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 28 Aug 2013 09:26:07 -0400 (EDT)
Subject: <i18n dev> Additional source to guess the local timezone ID on
 linux
In-Reply-To: <521CB0DC.7000701@redhat.com>
References: <5217CF92.9030307@redhat.com> <521B1482.104@oracle.com>
	<521C4E9A.3050902@oracle.com> <521CB0DC.7000701@redhat.com>
Message-ID: <1683825431.2780469.1377696367771.JavaMail.root@redhat.com>

----- Original Message -----
> On 08/27/2013 03:00 AM, Masayoshi Okutsu wrote:
> > /etc/sysconfig/clock used to be supported, but it was removed in JDK 7.
> > The problem is discussed in bug #6456628.
> > 
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628
> 
> Thanks for that link. I did not know that this support was present in
> JDK7 but then removed. I did not expect various distributions and
> versions to have significant differences in that file either.
> 

To bring things full circle:

https://bugzilla.redhat.com/show_bug.cgi?id=489586

"BTW: I'll change the warning boilerplate to this to make it more clear:

# The time zone of the system is defined by the contents of /etc/localtime.
# This file is only for evaluation by system-config-date, do not rely on its
# contents elsewhere."

https://bugzilla.redhat.com/show_bug.cgi?id=489586#c2

> > Have you tested your fix on all Red Hat-like distros, including some
> > older releases, with all the time zone IDs?
> 
> No, I tested this with Red Hat Enterprise Linux 6. I did not try it on
> older versions. I know newer versions of Fedora don't ship with this
> file any more.
> 
> Given that this support was removed because there were significant
> differences in that file making maintenance harder in OpenJDK, I am
> going to withdraw this patch.
> 
> Thanks to everyone who reviewed and commented on it.
> 
> Omair
> 
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From christian.beikov at gmail.com  Wed Aug 28 06:34:57 2013
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 28 Aug 2013 15:34:57 +0200
Subject: <i18n dev> java.util.Locale changes
In-Reply-To: <521DFA57.2060502@oracle.com>
References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com>
	<521DFA57.2060502@oracle.com>
Message-ID: <521DFC81.3080106@gmail.com>

Hey,

I haven't digged so deep where java.util.List is used but thanks for the 
pointer.
I have no problem with the usage of java.util.List as stated before. I 
am just thinking that, if someone for example uses a java.util.Set to 
represent the priorities, it would be necessary to construct a List to 
wrap the elements. The additional value is that in both cases, when 
passing a List or a Set to the methods, no additional overhead is necessary.

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 28.08.2013 15:25, schrieb Masayoshi Okutsu:
> (adding core-libs-dev)
>
> Hi Christian,
>
> RFC 4647 defines The Language Priority List [1]. The use of 
> java.util.List would be a natural fit, which is the reason why List is 
> used. But use of Iterable does work (as API design). The parameter 
> name `priorityIterable' sounds a bit odd, though.
>
> Does use of Iterable add much value to the API? (Please note that List 
> is also used in Locale.LanguageRange.)
>
> Thanks,
> Masayoshi
>
> [1] http://tools.ietf.org/html/rfc4647#section-2.3
>
> On 2013/08/28 18:31, Christian Beikov wrote:
>> Hello there,
>>
>> I have just seen the changes you want to apply to java.util.Locale in 
>> JDK 8 and was wondering why you are forcing the use of a 
>> java.util.List in the lookup and filter methods. The related methods 
>> of java.util.Locale are
>>
>> public static Locale lookup(List<Locale.LanguageRange> priorityList, 
>> Collection<Locale> locales)
>> public static String lookupTag(List<Locale.LanguageRange> 
>> priorityList, Collection<String> tags)
>> public static List<String> filterTags(List<Locale.LanguageRange> 
>> priorityList, Collection<String> tags)
>> public static List<String> filterTags(List<Locale.LanguageRange> 
>> priorityList, Collection<String> tags, Locale.FilteringMode mode)
>> public static List<Locale> filter(List<Locale.LanguageRange> 
>> priorityList, Collection<Locale> locales)
>> public static List<Locale> filter(List<Locale.LanguageRange> 
>> priorityList, Collection<Locale> locales, Locale.FilteringMode mode)
>>
>> which could be changed to
>>
>> public static Locale lookup(Iterable<Locale.LanguageRange> 
>> priorityIterable, Collection<Locale> locales)
>> public static String lookupTag(Iterable<Locale.LanguageRange> 
>> priorityIterable, Collection<String> tags)
>> public static List<String> filterTags(Iterable<Locale.LanguageRange> 
>> priorityIterable, Collection<String> tags)
>> public static List<String> filterTags(Iterable<Locale.LanguageRange> 
>> priorityIterable, Collection<String> tags, Locale.FilteringMode mode)
>> public static List<Locale> filter(Iterable<Locale.LanguageRange> 
>> priorityIterable, Collection<Locale> locales)
>> public static List<Locale> filter(Iterable<Locale.LanguageRange> 
>> priorityIterable, Collection<Locale> locales, Locale.FilteringMode mode)
>>
>> The use of java.util.Collection would also be ok.
>> One could also use a java.util.Set or something similar to represent 
>> the language ranges. I just wanted to provide that feedback if anyone 
>> cares. I am also ok with java.util.List but since you are only 
>> relying on the iteration order of the priorityList I was curious 
>> about the reason.
>>
>


From Alan.Bateman at oracle.com  Wed Aug 28 13:42:00 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Aug 2013 21:42:00 +0100
Subject: <i18n dev> java.util.Locale changes
In-Reply-To: <521DFA57.2060502@oracle.com>
References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com>
	<521DFA57.2060502@oracle.com>
Message-ID: <521E6098.9080801@oracle.com>

On 28/08/2013 14:25, Masayoshi Okutsu wrote:
> (adding core-libs-dev)
>
> Hi Christian,
>
> RFC 4647 defines The Language Priority List [1]. The use of 
> java.util.List would be a natural fit, which is the reason why List is 
> used. But use of Iterable does work (as API design). The parameter 
> name `priorityIterable' sounds a bit odd, though.
>
> Does use of Iterable add much value to the API? (Please note that List 
> is also used in Locale.LanguageRange.)
>
It depends on the usages but Iterable would be a bit more flexible. Does 
the locale matcher require to do anything except iterate over the 
elements? The return could be looked at it but it depends on the typical 
usage -- would the user of the API typically just iterate over the 
matched Locales?

-Alan.

From masayoshi.okutsu at oracle.com  Thu Aug 29 01:24:06 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 29 Aug 2013 17:24:06 +0900
Subject: <i18n dev> java.util.Locale changes
In-Reply-To: <521E6098.9080801@oracle.com>
References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com>
	<521DFA57.2060502@oracle.com> <521E6098.9080801@oracle.com>
Message-ID: <521F0526.7020904@oracle.com>

I took a look at the implementation. The matcher code just iterates the 
given priority list. isEmpty() is used, but it shouldn't be a problem. 
As far as an Iterable gives an Iterator which consistently iterates 
elements based on the priority or weight, the Iterable works.

Use of Iterable does give more flexibility, but I'm not sure how much it 
would add value to the API use. You can implement your own Iterable, but 
would many developers implement an Iterable to give a language priority 
list?

Masayoshi

On 2013/08/29 5:42, Alan Bateman wrote:
> On 28/08/2013 14:25, Masayoshi Okutsu wrote:
>> (adding core-libs-dev)
>>
>> Hi Christian,
>>
>> RFC 4647 defines The Language Priority List [1]. The use of 
>> java.util.List would be a natural fit, which is the reason why List 
>> is used. But use of Iterable does work (as API design). The parameter 
>> name `priorityIterable' sounds a bit odd, though.
>>
>> Does use of Iterable add much value to the API? (Please note that 
>> List is also used in Locale.LanguageRange.)
>>
> It depends on the usages but Iterable would be a bit more flexible. 
> Does the locale matcher require to do anything except iterate over the 
> elements? The return could be looked at it but it depends on the 
> typical usage -- would the user of the API typically just iterate over 
> the matched Locales?
>
> -Alan.


From christian.beikov at gmail.com  Sat Aug 31 10:06:49 2013
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 31 Aug 2013 19:06:49 +0200
Subject: <i18n dev> java.util.Locale changes
In-Reply-To: <521F0526.7020904@oracle.com>
References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com>
	<521DFA57.2060502@oracle.com> <521E6098.9080801@oracle.com>
	<521F0526.7020904@oracle.com>
Message-ID: <522222A9.5080805@gmail.com>

Well it at least adds the possibility to use a Set directly as source. 
As stated before, this is just a remark because I thought one could also 
want to use a different Collection than a List. Using the Collection 
interface would also be enough.

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 29.08.2013 10:24, schrieb Masayoshi Okutsu:
> I took a look at the implementation. The matcher code just iterates 
> the given priority list. isEmpty() is used, but it shouldn't be a 
> problem. As far as an Iterable gives an Iterator which consistently 
> iterates elements based on the priority or weight, the Iterable works.
>
> Use of Iterable does give more flexibility, but I'm not sure how much 
> it would add value to the API use. You can implement your own 
> Iterable, but would many developers implement an Iterable to give a 
> language priority list?
>
> Masayoshi
>
> On 2013/08/29 5:42, Alan Bateman wrote:
>> On 28/08/2013 14:25, Masayoshi Okutsu wrote:
>>> (adding core-libs-dev)
>>>
>>> Hi Christian,
>>>
>>> RFC 4647 defines The Language Priority List [1]. The use of 
>>> java.util.List would be a natural fit, which is the reason why List 
>>> is used. But use of Iterable does work (as API design). The 
>>> parameter name `priorityIterable' sounds a bit odd, though.
>>>
>>> Does use of Iterable add much value to the API? (Please note that 
>>> List is also used in Locale.LanguageRange.)
>>>
>> It depends on the usages but Iterable would be a bit more flexible. 
>> Does the locale matcher require to do anything except iterate over 
>> the elements? The return could be looked at it but it depends on the 
>> typical usage -- would the user of the API typically just iterate 
>> over the matched Locales?
>>
>> -Alan.
>


From stark9000 at gmail.com  Tue Aug 20 18:52:01 2013
From: stark9000 at gmail.com (stark9000)
Date: Wed, 21 Aug 2013 01:52:01 -0000
Subject: <i18n dev> java sinhalese...
Message-ID: <1377049923825-149658.post@n7.nabble.com>

Please let me know how to fix this :

<http://openjdk.5641.n7.nabble.com/file/n149658/1.jpg> 

Unicode font used : http://www.kaputa.com/slword/kaputaunicode.zip





--
View this message in context: http://openjdk.5641.n7.nabble.com/java-sinhalese-tp149658.html
Sent from the OpenJDK Internationalization Libraries mailing list archive at Nabble.com.

From christian.beikov at gmail.com  Wed Aug 28 02:25:56 2013
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 28 Aug 2013 09:25:56 -0000
Subject: <i18n dev> java.util.Locale changes
Message-ID: <521DC21F.1090309@gmail.com>

Hello there,

I have just seen the changes you want to apply to java.util.Locale in 
JDK 8 and was wondering why you are forcing the use of a java.util.List 
in the lookup and filter methods. The related methods of 
java.util.Locale are

public static Locale lookup(List<Locale.LanguageRange> priorityList, 
Collection<Locale> locales)
public static String lookupTag(List<Locale.LanguageRange> priorityList, 
Collection<String> tags)
public static List<String> filterTags(List<Locale.LanguageRange> 
priorityList, Collection<String> tags)
public static List<String> filterTags(List<Locale.LanguageRange> 
priorityList, Collection<String> tags, Locale.FilteringMode mode)
public static List<Locale> filter(List<Locale.LanguageRange> 
priorityList, Collection<Locale> locales)
public static List<Locale> filter(List<Locale.LanguageRange> 
priorityList, Collection<Locale> locales, Locale.FilteringMode mode)

which could be changed to

public static Locale lookup(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<Locale> locales)
public static String lookupTag(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<String> tags)
public static List<String> filterTags(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<String> tags)
public static List<String> filterTags(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<String> tags, Locale.FilteringMode mode)
public static List<Locale> filter(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<Locale> locales)
public static List<Locale> filter(Iterable<Locale.LanguageRange> 
priorityIterable, Collection<Locale> locales, Locale.FilteringMode mode)

The use of java.util.Collection would also be ok.
One could also use a java.util.Set or something similar to represent the 
language ranges. I just wanted to provide that feedback if anyone cares. 
I am also ok with java.util.List but since you are only relying on the 
iteration order of the priorityList I was curious about the reason.

-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*