From masayoshi.okutsu at oracle.com  Wed May  1 01:19:44 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 01 May 2013 17:19:44 +0900
Subject: <i18n dev> [8] RFR: 8013086 : NPE thrown by SimpleDateFormat
 with TimeZoneNameProvider supplied
In-Reply-To: <517AC3DC.6010809@oracle.com>
References: <51799E74.1020607@oracle.com> <517A3EDD.6020200@oracle.com>
	<517AC3DC.6010809@oracle.com>
Message-ID: <5180D020.5020300@oracle.com>

What I meant is something like this.

for (int i = 1; i <= 4; i++) {
     String name = tznp.getDisplayName(id, i>=3, i%2, locale);
     if (name == null) {
         switch (i) {
         case 1:
             return null;
         case 2:
             name = names[1];
             break;
         ...
         OR
         if (i == 0) {
             ....

Otherwise, names[i] will be evaluated 4 times.

Thanks,
Masayoshi

On 4/27/2013 3:13 AM, Naoto Sato wrote:
> Thank you for the comment. Updated the fix (just moved the following 
> if in front of the for-loop).
>
> http://cr.openjdk.java.net/~naoto/8013086/webrev.01/
>
> Naoto
>
> On 4/26/13 1:46 AM, Masayoshi Okutsu wrote:
>> I'd suggest that the for loop and the following if-statement be combined
>> and optimized.
>>
>> Masayoshi
>>
>> On 4/26/2013 6:21 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the fix for the following bug:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013086
>>>
>>> The fix is to complement the missing display names with the provided
>>> ones for TimeZoneNameProvider implementations.
>>>
>>> http://cr.openjdk.java.net/~naoto/8013086/webrev.00/
>>>
>>> Naoto
>>
>


From Alan.Bateman at oracle.com  Wed May  1 04:05:35 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 01 May 2013 12:05:35 +0100
Subject: <i18n dev> RFR JDK-8013254: Constructor \w need update to add
 the support of \p{Join_Control}
In-Reply-To: <51803118.1020407@oracle.com>
References: <517FF8F8.3080208@oracle.com> <51803118.1020407@oracle.com>
Message-ID: <5180F6FF.6080500@oracle.com>

On 30/04/2013 22:01, Xueming Shen wrote:
> My apology, the webrev is at
>
> http://cr.openjdk.java.net/~sherman/8013254/webrev/
>
> -Sherman
>
> On 04/30/2013 10:01 AM, Xueming Shen wrote:
>> Hi,
>>
>> It appears we dropped the ball on u+200c and u+200d when we updated
>> the "simple word boundaries" back to jdk7
I went through the webrev and it looks good to me. I assume you have 
checked to make sure that we didn't miss anything else.

-Alan


From mandy.chung at oracle.com  Wed May  1 08:44:45 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 01 May 2013 08:44:45 -0700
Subject: <i18n dev> RFR JDK-8013254: Constructor \w need update to add
 the support of \p{Join_Control}
In-Reply-To: <51803118.1020407@oracle.com>
References: <517FF8F8.3080208@oracle.com> <51803118.1020407@oracle.com>
Message-ID: <5181386D.8050804@oracle.com>

On 4/30/2013 2:01 PM, Xueming Shen wrote:
>
> http://cr.openjdk.java.net/~sherman/8013254/webrev/
>

Looks good.

Mandy

> -Sherman
>
> On 04/30/2013 10:01 AM, Xueming Shen wrote:
>> Hi,
>>
>> It appears we dropped the ball on u+200c and u+200d when we updated
>> the "simple word boundaries" back to jdk7 [1]. You can find most of the
>> related discussion here [2]. These 2 code points are listed as one of 
>> the
>> issues we were trying to fix but obviously the final doc and 
>> implementation
>> don't address them. Mainly because the \p{Join_Control} was not 
>> explicitly
>> listed in TR#18 "compatibility" section back then (the earlier 
>> version) [3],
>> though these 2 code points are explicitly mentioned at section RL1.4 
>> Simple
>> Word Boundaries [4]. The \p{Join_Control} (u+200c and u+200d) has been
>> added/listed in the "compatibility" section in the latest version of 
>> TR#18 [5].
>>
>> The proposed change here is to
>> (1) add these two code points back to the collection of \w
>> (2) list them explicitly into the \w definition as \p{Join_Control}
>> (3) list Join_Control as one of the supported binary properties.
>>
>> http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000381.html
>>
>> The webrev for RegExTest.java above includes the change for 8013252
>> which is being reviewed as well, I'm not separating them out just for
>> convenience. The regression/unit tests may not that "direct", here is
>> a direct version to verify the fix.
>>
>>         Matcher wordU = Pattern.compile("\\w", 
>> Pattern.UNICODE_CHARACTER_CLASS).matcher("");
>>         System.out.println(wordU.reset("\u200c").find());
>>         System.out.println(wordU.reset("\u200d").find());
>>
>> thanks
>> -Sherman
>>
>> [1] http://ccc.us.oracle.com/7039066
>> [2] 
>> http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000381.html
>> [3] 
>> http://www.unicode.org/reports/tr18/tr18-13.html#Compatibility_Properties
>> [4] 
>> http://www.unicode.org/reports/tr18/tr18-13.html#Simple_Word_Boundaries
>> [5] http://www.unicode.org/reports/tr18/#Compatibility_Properties
>


From naoto.sato at oracle.com  Wed May  1 19:46:01 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 01 May 2013 19:46:01 -0700
Subject: <i18n dev> [8] RFR: 8013086 : NPE thrown by SimpleDateFormat
 with TimeZoneNameProvider supplied
In-Reply-To: <5180D020.5020300@oracle.com>
References: <51799E74.1020607@oracle.com> <517A3EDD.6020200@oracle.com>
	<517AC3DC.6010809@oracle.com> <5180D020.5020300@oracle.com>
Message-ID: <5181D369.4080308@oracle.com>

Webrev has been updated with your suggestion:

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

Naoto

On 5/1/13 1:19 AM, Masayoshi Okutsu wrote:
> What I meant is something like this.
>
> for (int i = 1; i <= 4; i++) {
>      String name = tznp.getDisplayName(id, i>=3, i%2, locale);
>      if (name == null) {
>          switch (i) {
>          case 1:
>              return null;
>          case 2:
>              name = names[1];
>              break;
>          ...
>          OR
>          if (i == 0) {
>              ....
>
> Otherwise, names[i] will be evaluated 4 times.
>
> Thanks,
> Masayoshi
>
> On 4/27/2013 3:13 AM, Naoto Sato wrote:
>> Thank you for the comment. Updated the fix (just moved the following
>> if in front of the for-loop).
>>
>> http://cr.openjdk.java.net/~naoto/8013086/webrev.01/
>>
>> Naoto
>>
>> On 4/26/13 1:46 AM, Masayoshi Okutsu wrote:
>>> I'd suggest that the for loop and the following if-statement be combined
>>> and optimized.
>>>
>>> Masayoshi
>>>
>>> On 4/26/2013 6:21 AM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix for the following bug:
>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013086
>>>>
>>>> The fix is to complement the missing display names with the provided
>>>> ones for TimeZoneNameProvider implementations.
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8013086/webrev.00/
>>>>
>>>> Naoto
>>>
>>
>


From yong.huang at oracle.com  Fri May  3 00:04:49 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Fri, 03 May 2013 15:04:49 +0800
Subject: <i18n dev> Review Request - 7105209 : Full date format in
 DateFormat does not include day of the week for SV/DA locale
Message-ID: <51836191.4070404@oracle.com>

Hello,

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

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

thanks,
Yong

From naoto.sato at oracle.com  Mon May  6 11:50:41 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 06 May 2013 11:50:41 -0700
Subject: <i18n dev> [8] RFR: 8013233,
	java/util/Locale/LocaleProviders.sh fails
Message-ID: <5187FB81.7080203@oracle.com>

Hello,

Please review the following changeset:

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

for the following bug:

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

The original test case assumed Windows ver 6.0 or upper always contain 
the localized display name for Macedonian, which wasn't the case in some 
installation. Removed the hard coded name and replaced them with the 
actual returned name from the host adapter.

Naoto

From masayoshi.okutsu at oracle.com  Mon May  6 19:05:39 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 07 May 2013 11:05:39 +0900
Subject: <i18n dev> [8] RFR: 8013086 : NPE thrown by SimpleDateFormat
 with TimeZoneNameProvider supplied
In-Reply-To: <5181D369.4080308@oracle.com>
References: <51799E74.1020607@oracle.com> <517A3EDD.6020200@oracle.com>
	<517AC3DC.6010809@oracle.com> <5180D020.5020300@oracle.com>
	<5181D369.4080308@oracle.com>
Message-ID: <51886173.3000400@oracle.com>

Looks OK. There's still some room for optimization, though.

Masayoshi

On 5/2/2013 11:46 AM, Naoto Sato wrote:
> Webrev has been updated with your suggestion:
>
> http://cr.openjdk.java.net/~naoto/8013086/webrev.02/
>
> Naoto
>
> On 5/1/13 1:19 AM, Masayoshi Okutsu wrote:
>> What I meant is something like this.
>>
>> for (int i = 1; i <= 4; i++) {
>>      String name = tznp.getDisplayName(id, i>=3, i%2, locale);
>>      if (name == null) {
>>          switch (i) {
>>          case 1:
>>              return null;
>>          case 2:
>>              name = names[1];
>>              break;
>>          ...
>>          OR
>>          if (i == 0) {
>>              ....
>>
>> Otherwise, names[i] will be evaluated 4 times.
>>
>> Thanks,
>> Masayoshi
>>
>> On 4/27/2013 3:13 AM, Naoto Sato wrote:
>>> Thank you for the comment. Updated the fix (just moved the following
>>> if in front of the for-loop).
>>>
>>> http://cr.openjdk.java.net/~naoto/8013086/webrev.01/
>>>
>>> Naoto
>>>
>>> On 4/26/13 1:46 AM, Masayoshi Okutsu wrote:
>>>> I'd suggest that the for loop and the following if-statement be 
>>>> combined
>>>> and optimized.
>>>>
>>>> Masayoshi
>>>>
>>>> On 4/26/2013 6:21 AM, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix for the following bug:
>>>>>
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013086
>>>>>
>>>>> The fix is to complement the missing display names with the provided
>>>>> ones for TimeZoneNameProvider implementations.
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8013086/webrev.00/
>>>>>
>>>>> Naoto
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Mon May  6 21:30:54 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 07 May 2013 13:30:54 +0900
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <5187FB81.7080203@oracle.com>
References: <5187FB81.7080203@oracle.com>
Message-ID: <5188837E.1060005@oracle.com>

Not sure how the test can detect bugs in the provider of the host 
adapter. BTW, some lines are very long requiring a wide screen monitor.

Masayoshi

On 5/7/2013 3:50 AM, Naoto Sato wrote:
> Hello,
>
> Please review the following changeset:
>
> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>
> for the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>
> The original test case assumed Windows ver 6.0 or upper always contain 
> the localized display name for Macedonian, which wasn't the case in 
> some installation. Removed the hard coded name and replaced them with 
> the actual returned name from the host adapter.
>
> Naoto


From naoto.sato at oracle.com  Tue May  7 15:10:46 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 07 May 2013 15:10:46 -0700
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <5188837E.1060005@oracle.com>
References: <5187FB81.7080203@oracle.com> <5188837E.1060005@oracle.com>
Message-ID: <51897BE6.40005@oracle.com>

On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
> Not sure how the test can detect bugs in the provider of the host
> adapter.

The test case only checks the Java side code paths, i.e., whether the 
returned display name from the HOST adapter is honored over JRE's one or 
not. In the case of "mk", that detects the failure.

> BTW, some lines are very long requiring a wide screen monitor.

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

Naoto

>
> Masayoshi
>
> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the following changeset:
>>
>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>
>> for the following bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>
>> The original test case assumed Windows ver 6.0 or upper always contain
>> the localized display name for Macedonian, which wasn't the case in
>> some installation. Removed the hard coded name and replaced them with
>> the actual returned name from the host adapter.
>>
>> Naoto
>


From xueming.shen at oracle.com  Wed May  8 15:20:35 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 08 May 2013 15:20:35 -0700
Subject: <i18n dev> RFR  JDK-8013386: (tz) Support tzdata2013c
Message-ID: <518ACFB3.5030000@oracle.com>

Hi,

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

Other than the tzdb data file update under make/sun/javazic/tzdata,
corresponding updates have also been made in TimeZoneNames***.java
for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
zone display names (from EET to CET) for Africa/Tripoli (and its alias Libya)

test/java/util/TimeZone/tools/share/Make has been run to generate the
new test data at TimeZoneData.

# I have to update the displaynames.txt "manually" to undo the change
for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt both
in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the
definition in TimeZoneNames.java (which has FKT as the standard name and
FKST as the summer name) does not match the tz data file (which suggests
that Stanley has moved to use only summer zone), but since this appears
to be an existing issue that not related to this update, I keep the test data for
Stanley untouched.

Tests list below have been run and passed.

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

webrev:

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

Thanks!
Sherman

From youdwei at linux.vnet.ibm.com  Wed May  8 23:18:59 2013
From: youdwei at linux.vnet.ibm.com (Deven You)
Date: Thu, 09 May 2013 14:18:59 +0800
Subject: <i18n dev> Slovenia Pre Euro currency problem
Message-ID: <518B3FD3.50905@linux.vnet.ibm.com>

Hi All,

There is a problem for display Slovenia Pre Euro currency, a test 
case[1] can reproduce this problem:

expected:

sl_SI Slovenian (Slovenia) currency example:
Expected o/p: EUR 1.234,56
Actual o/p  : EUR 1.234,56
sl_SI_EURO Slovenian (Slovenia,Euro) currency example:
Expected o/p: EUR 1.234,56
Actual o/p  : EUR 1.234,56
sl_SI_PREEURO Slovenian (Slovenia,PREEURO) currency example:
Expected o/p: tol 1.234,56
Actual o/p  : tol 1.234,56

Actual:

sl_SI Slovenian (Slovenia) currency example:
Expected o/p: EUR 1.234,56
Actual o/p  : EUR 1.234,56
sl_SI_EURO Slovenian (Slovenia,Euro) currency example:
Expected o/p: EUR 1.234,56
Actual o/p  : EUR 1.234,56
sl_SI_PREEURO Slovenian (Slovenia,PREEURO) currency example:
Expected o/p: tol 1.234,56
Actual o/p  : EUR 1.234,56
Exception in thread "main" java.lang.RuntimeException: The output doesn't match
	at TestCurr_Slovenia.assertEquals(TestCurr_Slovenia.java:35)
	at TestCurr_Slovenia.checkCurrency(TestCurr_Slovenia.java:27)
	at TestCurr_Slovenia.testCurr_Slovenia(TestCurr_Slovenia.java:16)
	at TestCurr_Slovenia.main(TestCurr_Slovenia.java:41)


I found there is already some discuss about Slovenia Pre Euro currency 
problem: 
http://mail.openjdk.java.net/pipermail/i18n-dev/2012-August/000751.html^.
And in that thread, Sean suggested there is already a patch posted to 
solve this problem.
I did a search for the whole mailing list, but not find any discuss 
about the patch mentioned in above link.

So I just put the patch[2] again and see if anyone can take a look?

[1] TestCurr_Slovenia.java 
<http://jira.hursley.ibm.com/java/secure/attachment/14483/TestCurr_Slovenia.java> 
in attachment
[2] http://cr.openjdk.java.net/~youdwei/ojdk-667/webrev/ 
<http://cr.openjdk.java.net/%7Eyoudwei/ojdk-667/webrev/>

Thanks a lot!



From youdwei at linux.vnet.ibm.com  Thu May  9 00:22:11 2013
From: youdwei at linux.vnet.ibm.com (Deven You)
Date: Thu, 09 May 2013 15:22:11 +0800
Subject: <i18n dev> Slovenia Pre Euro currency problem
In-Reply-To: <518B3FD3.50905@linux.vnet.ibm.com>
References: <518B3FD3.50905@linux.vnet.ibm.com>
Message-ID: <518B4EA3.1060202@linux.vnet.ibm.com>

Hi All,

I don't know why the mail signed out without my attached test case. I 
have copied it[3] into cr.openjdk.java.net.

[3] http://cr.openjdk.java.net/~youdwei/ojdk-667/TestCurr_Slovenia.java 
<http://cr.openjdk.java.net/%7Eyoudwei/ojdk-667/TestCurr_Slovenia.java>

Thanks a lot!
On 05/09/2013 02:18 PM, Deven You wrote:
> Hi All,
>
> There is a problem for display Slovenia Pre Euro currency, a test 
> case[1] can reproduce this problem:
>
> expected:
>
> sl_SI Slovenian (Slovenia) currency example:
> Expected o/p: EUR 1.234,56
> Actual o/p  : EUR 1.234,56
> sl_SI_EURO Slovenian (Slovenia,Euro) currency example:
> Expected o/p: EUR 1.234,56
> Actual o/p  : EUR 1.234,56
> sl_SI_PREEURO Slovenian (Slovenia,PREEURO) currency example:
> Expected o/p: tol 1.234,56
> Actual o/p  : tol 1.234,56
>
> Actual:
>
> sl_SI Slovenian (Slovenia) currency example:
> Expected o/p: EUR 1.234,56
> Actual o/p  : EUR 1.234,56
> sl_SI_EURO Slovenian (Slovenia,Euro) currency example:
> Expected o/p: EUR 1.234,56
> Actual o/p  : EUR 1.234,56
> sl_SI_PREEURO Slovenian (Slovenia,PREEURO) currency example:
> Expected o/p: tol 1.234,56
> Actual o/p  : EUR 1.234,56
> Exception in thread "main" java.lang.RuntimeException: The output 
> doesn't match
>     at TestCurr_Slovenia.assertEquals(TestCurr_Slovenia.java:35)
>     at TestCurr_Slovenia.checkCurrency(TestCurr_Slovenia.java:27)
>     at TestCurr_Slovenia.testCurr_Slovenia(TestCurr_Slovenia.java:16)
>     at TestCurr_Slovenia.main(TestCurr_Slovenia.java:41)
>
>
> I found there is already some discuss about Slovenia Pre Euro currency 
> problem: 
> http://mail.openjdk.java.net/pipermail/i18n-dev/2012-August/000751.html^.
> And in that thread, Sean suggested there is already a patch posted to 
> solve this problem.
> I did a search for the whole mailing list, but not find any discuss 
> about the patch mentioned in above link.
>
> So I just put the patch[2] again and see if anyone can take a look?
>
> [1] TestCurr_Slovenia.java 
> <http://jira.hursley.ibm.com/java/secure/attachment/14483/TestCurr_Slovenia.java> 
> in attachment
> [2] http://cr.openjdk.java.net/~youdwei/ojdk-667/webrev/ 
> <http://cr.openjdk.java.net/%7Eyoudwei/ojdk-667/webrev/>
>
> Thanks a lot!
>
>


From sean.coffey at oracle.com  Thu May  9 02:06:13 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 09 May 2013 10:06:13 +0100
Subject: <i18n dev> RFR  JDK-8013386: (tz) Support tzdata2013c
In-Reply-To: <518ACFB3.5030000@oracle.com>
References: <518ACFB3.5030000@oracle.com>
Message-ID: <518B6705.3050203@oracle.com>

Thanks for taking care of this Sherman. I was wondering what sort of 
impact JSR 310 would make on tzdata updates. The Atlantic/Stanley 
display name issue mentioned is a regular one, we should log a bug 
against the test file generation scripts.

I just had a quick grok of the jdk8 repo. The following files need 
updating also :

jdk/test/sun/util/calendar/zi/tzdata/*
jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java (line 85)
jdk/makefiles/GendataTimeZone.gmk (line 29)

It looks like jdk/makefiles/GendataTimeZone.gmk still has a dependency 
on reading files from jdk/make. That'll all have to change too once the 
old build system is removed from jdk8. I think the new tzdata sources 
should be moved into a directory under makefiles rather than keeping 
them in make.

The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in 
jdk/makefiles/GendataTimeZone.gmk  should be removed if we know that the 
version string can be read from the VERSION file stored with tzdata.

Above points are not necessarily related to 2013c update and should be 
cleaned up separately perhaps.

regards,
Sean.

On 08/05/2013 23:20, Xueming Shen wrote:
> Hi,
>
> Please help review the proposed change to update the tz data
> in JDK8 from 2012i to 2013c.
>
> Other than the tzdb data file update under make/sun/javazic/tzdata,
> corresponding updates have also been made in TimeZoneNames***.java
> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
> zone display names (from EET to CET) for Africa/Tripoli (and its alias 
> Libya)
>
> test/java/util/TimeZone/tools/share/Make has been run to generate the
> new test data at TimeZoneData.
>
> # I have to update the displaynames.txt "manually" to undo the change
> for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt 
> both
> in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the
> definition in TimeZoneNames.java (which has FKT as the standard name and
> FKST as the summer name) does not match the tz data file (which suggests
> that Stanley has moved to use only summer zone), but since this appears
> to be an existing issue that not related to this update, I keep the 
> test data for
> Stanley untouched.
>
> Tests list below have been run and passed.
>
> java/util/TimeZone
> java/util/Calendar
> java/util/Formatter
> java/time
> closed/java/util/TimeZone
> closed/java/util/Calendar
>
> webrev:
>
> http://cr.openjdk.java.net/~sherman/8013386/webrev/
> http://cr.openjdk.java.net/~sherman/8013386/test.closed/
>
> Thanks!
> Sherman


From naoto.sato at oracle.com  Thu May  9 11:51:31 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 09 May 2013 11:51:31 -0700
Subject: <i18n dev> Slovenia Pre Euro currency problem
In-Reply-To: <518B3FD3.50905@linux.vnet.ibm.com>
References: <518B3FD3.50905@linux.vnet.ibm.com>
Message-ID: <518BF033.5030908@oracle.com>

Hi Deven,

Are those "EURO"/"PREEURO" variants IBM proprietary locales? I don't 
think they are available in OpenJDK.

As to adding those variants, I am not sure that is the way to go, in 
terms of adding them as generic locales. Currency variants should be 
dealt with BCP 47's extension.

Naoto

On 5/8/13 11:18 PM, Deven You wrote:
> Hi All,
>
> There is a problem for display Slovenia Pre Euro currency, a test
> case[1] can reproduce this problem:
>
> expected:
>
> sl_SI Slovenian (Slovenia) currency example:
> Expected o/p: EUR 1.234,56
> Actual o/p  : EUR 1.234,56
> sl_SI_EURO Slovenian (Slovenia,Euro) currency example:
> Expected o/p: EUR 1.234,56
> Actual o/p  : EUR 1.234,56
> sl_SI_PREEURO Slovenian (Slovenia,PREEURO) currency example:
> Expected o/p: tol 1.234,56
> Actual o/p  : tol 1.234,56
>
> Actual:
>
> sl_SI Slovenian (Slovenia) currency example:
> Expected o/p: EUR 1.234,56
> Actual o/p  : EUR 1.234,56
> sl_SI_EURO Slovenian (Slovenia,Euro) currency example:
> Expected o/p: EUR 1.234,56
> Actual o/p  : EUR 1.234,56
> sl_SI_PREEURO Slovenian (Slovenia,PREEURO) currency example:
> Expected o/p: tol 1.234,56
> Actual o/p  : EUR 1.234,56
> Exception in thread "main" java.lang.RuntimeException: The output
> doesn't match
>      at TestCurr_Slovenia.assertEquals(TestCurr_Slovenia.java:35)
>      at TestCurr_Slovenia.checkCurrency(TestCurr_Slovenia.java:27)
>      at TestCurr_Slovenia.testCurr_Slovenia(TestCurr_Slovenia.java:16)
>      at TestCurr_Slovenia.main(TestCurr_Slovenia.java:41)
>
>
> I found there is already some discuss about Slovenia Pre Euro currency
> problem:
> http://mail.openjdk.java.net/pipermail/i18n-dev/2012-August/000751.html^.
> And in that thread, Sean suggested there is already a patch posted to
> solve this problem.
> I did a search for the whole mailing list, but not find any discuss
> about the patch mentioned in above link.
>
> So I just put the patch[2] again and see if anyone can take a look?
>
> [1] TestCurr_Slovenia.java
> <http://jira.hursley.ibm.com/java/secure/attachment/14483/TestCurr_Slovenia.java>
> in attachment
> [2] http://cr.openjdk.java.net/~youdwei/ojdk-667/webrev/
> <http://cr.openjdk.java.net/%7Eyoudwei/ojdk-667/webrev/>
>
> Thanks a lot!
>
>


From xueming.shen at oracle.com  Thu May  9 16:24:57 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 09 May 2013 16:24:57 -0700
Subject: <i18n dev> RFR  JDK-8013386: (tz) Support tzdata2013c
In-Reply-To: <518B6705.3050203@oracle.com>
References: <518ACFB3.5030000@oracle.com> <518B6705.3050203@oracle.com>
Message-ID: <518C3049.5050801@oracle.com>

Hi Sean,

Thanks for the review. It appears I missed jdk/test/sun/util/calendar/zi/tzdata,
webrev has been updated to include the test data update.

http://cr.openjdk.java.net/~sherman/8013386/webrev

I will update TCKZoneRulesProvider.java separately in JSR310 repo, this def is
actually is not being used by anyone anymore, just need to be removed.

jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be removed, I
will remove it separately later.


Masayoshi,

The update also included the two changes needed to fix/workaround the following 2
issues found during running the regression test

      jdk/test/sun/util/calendar/zi/TestZoneInfo310.java,

due to the changes for Rule Palestine and the corresponding Zone Asia/Gaza and
Asia/Hebron [1].

(1) Now the Rule Palestine has the def of "lastThu 24:00", similar to Asia/Amman, so
these two zones need to be handled specially in ZoneInfoFile as well [2]

(2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 transitions for 2011
when returned from Rule.getRules(int year). Unfortunately it appears the Comparator
for Arrays.sorting is incorrectly implemented when comparing two longs [3]. The directly
consequence of this decade-old bug is that the returned list has the wrong order for
2011/08/01/xxx and 2011/08/30/xxx

Please help review.

Thanks!
-Sherman

[1] http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html
[2] http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html
[3] http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html

On 05/09/2013 02:06 AM, Se?n Coffey wrote:
> Thanks for taking care of this Sherman. I was wondering what sort of impact JSR 310 would make on tzdata updates. The Atlantic/Stanley display name issue mentioned is a regular one, we should log a bug against the test file generation scripts.
>
> I just had a quick grok of the jdk8 repo. The following files need updating also :
>
> jdk/test/sun/util/calendar/zi/tzdata/*
> jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java (line 85)
> jdk/makefiles/GendataTimeZone.gmk (line 29)
>
> It looks like jdk/makefiles/GendataTimeZone.gmk still has a dependency on reading files from jdk/make. That'll all have to change too once the old build system is removed from jdk8. I think the new tzdata sources should be moved into a directory under makefiles rather than keeping them in make.
>
> The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in jdk/makefiles/GendataTimeZone.gmk  should be removed if we know that the version string can be read from the VERSION file stored with tzdata.
>
> Above points are not necessarily related to 2013c update and should be cleaned up separately perhaps.
>
> regards,
> Sean.
>
> On 08/05/2013 23:20, Xueming Shen wrote:
>> Hi,
>>
>> Please help review the proposed change to update the tz data
>> in JDK8 from 2012i to 2013c.
>>
>> Other than the tzdb data file update under make/sun/javazic/tzdata,
>> corresponding updates have also been made in TimeZoneNames***.java
>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
>> zone display names (from EET to CET) for Africa/Tripoli (and its alias Libya)
>>
>> test/java/util/TimeZone/tools/share/Make has been run to generate the
>> new test data at TimeZoneData.
>>
>> # I have to update the displaynames.txt "manually" to undo the change
>> for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt both
>> in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the
>> definition in TimeZoneNames.java (which has FKT as the standard name and
>> FKST as the summer name) does not match the tz data file (which suggests
>> that Stanley has moved to use only summer zone), but since this appears
>> to be an existing issue that not related to this update, I keep the test data for
>> Stanley untouched.
>>
>> Tests list below have been run and passed.
>>
>> java/util/TimeZone
>> java/util/Calendar
>> java/util/Formatter
>> java/time
>> closed/java/util/TimeZone
>> closed/java/util/Calendar
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~sherman/8013386/webrev/
>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/
>>
>> Thanks!
>> Sherman
>


From masayoshi.okutsu at oracle.com  Thu May  9 21:57:20 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 10 May 2013 13:57:20 +0900
Subject: <i18n dev> RFR  JDK-8013386: (tz) Support tzdata2013c
In-Reply-To: <518C3049.5050801@oracle.com>
References: <518ACFB3.5030000@oracle.com> <518B6705.3050203@oracle.com>
	<518C3049.5050801@oracle.com>
Message-ID: <518C7E30.8030302@oracle.com>

Do we still need to keep the old javazic code in JDK8? It's a 
maintenance burden to maintain both, isn't it?

I'm concerned about the 24:00 fix. Is there any way to produce the 
correct rules without hard coding time zone IDs?

Masayoshi

On 5/10/2013 8:24 AM, Xueming Shen wrote:
> Hi Sean,
>
> Thanks for the review. It appears I missed 
> jdk/test/sun/util/calendar/zi/tzdata,
> webrev has been updated to include the test data update.
>
> http://cr.openjdk.java.net/~sherman/8013386/webrev
>
> I will update TCKZoneRulesProvider.java separately in JSR310 repo, 
> this def is
> actually is not being used by anyone anymore, just need to be removed.
>
> jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be 
> removed, I
> will remove it separately later.
>
>
> Masayoshi,
>
> The update also included the two changes needed to fix/workaround the 
> following 2
> issues found during running the regression test
>
>      jdk/test/sun/util/calendar/zi/TestZoneInfo310.java,
>
> due to the changes for Rule Palestine and the corresponding Zone 
> Asia/Gaza and
> Asia/Hebron [1].
>
> (1) Now the Rule Palestine has the def of "lastThu 24:00", similar to 
> Asia/Amman, so
> these two zones need to be handled specially in ZoneInfoFile as well [2]
>
> (2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 
> transitions for 2011
> when returned from Rule.getRules(int year). Unfortunately it appears 
> the Comparator
> for Arrays.sorting is incorrectly implemented when comparing two longs 
> [3]. The directly
> consequence of this decade-old bug is that the returned list has the 
> wrong order for
> 2011/08/01/xxx and 2011/08/30/xxx
>
> Please help review.
>
> Thanks!
> -Sherman
>
> [1] 
> http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html
> [2] 
> http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html
> [3] 
> http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html
>
> On 05/09/2013 02:06 AM, Se?n Coffey wrote:
>> Thanks for taking care of this Sherman. I was wondering what sort of 
>> impact JSR 310 would make on tzdata updates. The Atlantic/Stanley 
>> display name issue mentioned is a regular one, we should log a bug 
>> against the test file generation scripts.
>>
>> I just had a quick grok of the jdk8 repo. The following files need 
>> updating also :
>>
>> jdk/test/sun/util/calendar/zi/tzdata/*
>> jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java (line 
>> 85)
>> jdk/makefiles/GendataTimeZone.gmk (line 29)
>>
>> It looks like jdk/makefiles/GendataTimeZone.gmk still has a 
>> dependency on reading files from jdk/make. That'll all have to change 
>> too once the old build system is removed from jdk8. I think the new 
>> tzdata sources should be moved into a directory under makefiles 
>> rather than keeping them in make.
>>
>> The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in 
>> jdk/makefiles/GendataTimeZone.gmk  should be removed if we know that 
>> the version string can be read from the VERSION file stored with tzdata.
>>
>> Above points are not necessarily related to 2013c update and should 
>> be cleaned up separately perhaps.
>>
>> regards,
>> Sean.
>>
>> On 08/05/2013 23:20, Xueming Shen wrote:
>>> Hi,
>>>
>>> Please help review the proposed change to update the tz data
>>> in JDK8 from 2012i to 2013c.
>>>
>>> Other than the tzdb data file update under make/sun/javazic/tzdata,
>>> corresponding updates have also been made in TimeZoneNames***.java
>>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
>>> zone display names (from EET to CET) for Africa/Tripoli (and its 
>>> alias Libya)
>>>
>>> test/java/util/TimeZone/tools/share/Make has been run to generate the
>>> new test data at TimeZoneData.
>>>
>>> # I have to update the displaynames.txt "manually" to undo the change
>>> for Atlantic/Stanley from "FKST" (which is defined in 
>>> southamerica.txt both
>>> in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
>>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the
>>> definition in TimeZoneNames.java (which has FKT as the standard name 
>>> and
>>> FKST as the summer name) does not match the tz data file (which 
>>> suggests
>>> that Stanley has moved to use only summer zone), but since this appears
>>> to be an existing issue that not related to this update, I keep the 
>>> test data for
>>> Stanley untouched.
>>>
>>> Tests list below have been run and passed.
>>>
>>> java/util/TimeZone
>>> java/util/Calendar
>>> java/util/Formatter
>>> java/time
>>> closed/java/util/TimeZone
>>> closed/java/util/Calendar
>>>
>>> webrev:
>>>
>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/
>>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/
>>>
>>> Thanks!
>>> Sherman
>>
>


From xueming.shen at oracle.com  Thu May  9 23:30:04 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 09 May 2013 23:30:04 -0700
Subject: <i18n dev> RFR  JDK-8013386: (tz) Support tzdata2013c
In-Reply-To: <518C7E30.8030302@oracle.com>
References: <518ACFB3.5030000@oracle.com> <518B6705.3050203@oracle.com>
	<518C3049.5050801@oracle.com> <518C7E30.8030302@oracle.com>
Message-ID: <518C93EC.9080209@oracle.com>

On 5/9/13 9:57 PM, Masayoshi Okutsu wrote:
> Do we still need to keep the old javazic code in JDK8? It's a 
> maintenance burden to maintain both, isn't it?
>

While it's a burden, but somehow it serves as a test case pretty well. 
The transitions are
being built the "old" jdk way and threeten way, if the transition does 
not match, something
might be wrong. This time, it's in the "old" code, maybe next time it's 
in the threeten. So
it might be still worth keeping a while, to remove in jdk9? Btw, the 
Rule.java fix might need
go into the tzdb update tool as well, I believe the transitions for 2011 
Palestine are wrong in
the updated tzdb updator.

> I'm concerned about the 24:00 fix. Is there any way to produce the 
> correct rules without hard coding time zone IDs?

I don't know how to do it, yet. I definitely can have a RFE for it and 
spend some time on
it later.

-Sherman

>
> Masayoshi
>
> On 5/10/2013 8:24 AM, Xueming Shen wrote:
>> Hi Sean,
>>
>> Thanks for the review. It appears I missed 
>> jdk/test/sun/util/calendar/zi/tzdata,
>> webrev has been updated to include the test data update.
>>
>> http://cr.openjdk.java.net/~sherman/8013386/webrev
>>
>> I will update TCKZoneRulesProvider.java separately in JSR310 repo, 
>> this def is
>> actually is not being used by anyone anymore, just need to be removed.
>>
>> jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be 
>> removed, I
>> will remove it separately later.
>>
>>
>> Masayoshi,
>>
>> The update also included the two changes needed to fix/workaround the 
>> following 2
>> issues found during running the regression test
>>
>>      jdk/test/sun/util/calendar/zi/TestZoneInfo310.java,
>>
>> due to the changes for Rule Palestine and the corresponding Zone 
>> Asia/Gaza and
>> Asia/Hebron [1].
>>
>> (1) Now the Rule Palestine has the def of "lastThu 24:00", similar to 
>> Asia/Amman, so
>> these two zones need to be handled specially in ZoneInfoFile as well [2]
>>
>> (2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 
>> transitions for 2011
>> when returned from Rule.getRules(int year). Unfortunately it appears 
>> the Comparator
>> for Arrays.sorting is incorrectly implemented when comparing two 
>> longs [3]. The directly
>> consequence of this decade-old bug is that the returned list has the 
>> wrong order for
>> 2011/08/01/xxx and 2011/08/30/xxx
>>
>> Please help review.
>>
>> Thanks!
>> -Sherman
>>
>> [1] 
>> http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html
>> [2] 
>> http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html
>> [3] 
>> http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html
>>
>> On 05/09/2013 02:06 AM, Se?n Coffey wrote:
>>> Thanks for taking care of this Sherman. I was wondering what sort of 
>>> impact JSR 310 would make on tzdata updates. The Atlantic/Stanley 
>>> display name issue mentioned is a regular one, we should log a bug 
>>> against the test file generation scripts.
>>>
>>> I just had a quick grok of the jdk8 repo. The following files need 
>>> updating also :
>>>
>>> jdk/test/sun/util/calendar/zi/tzdata/*
>>> jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java 
>>> (line 85)
>>> jdk/makefiles/GendataTimeZone.gmk (line 29)
>>>
>>> It looks like jdk/makefiles/GendataTimeZone.gmk still has a 
>>> dependency on reading files from jdk/make. That'll all have to 
>>> change too once the old build system is removed from jdk8. I think 
>>> the new tzdata sources should be moved into a directory under 
>>> makefiles rather than keeping them in make.
>>>
>>> The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in 
>>> jdk/makefiles/GendataTimeZone.gmk  should be removed if we know that 
>>> the version string can be read from the VERSION file stored with 
>>> tzdata.
>>>
>>> Above points are not necessarily related to 2013c update and should 
>>> be cleaned up separately perhaps.
>>>
>>> regards,
>>> Sean.
>>>
>>> On 08/05/2013 23:20, Xueming Shen wrote:
>>>> Hi,
>>>>
>>>> Please help review the proposed change to update the tz data
>>>> in JDK8 from 2012i to 2013c.
>>>>
>>>> Other than the tzdb data file update under make/sun/javazic/tzdata,
>>>> corresponding updates have also been made in TimeZoneNames***.java
>>>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
>>>> zone display names (from EET to CET) for Africa/Tripoli (and its 
>>>> alias Libya)
>>>>
>>>> test/java/util/TimeZone/tools/share/Make has been run to generate the
>>>> new test data at TimeZoneData.
>>>>
>>>> # I have to update the displaynames.txt "manually" to undo the change
>>>> for Atlantic/Stanley from "FKST" (which is defined in 
>>>> southamerica.txt both
>>>> in 2012i and 2013c, there is no change for Stanley from 2012i to 
>>>> 2013c)
>>>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why 
>>>> the
>>>> definition in TimeZoneNames.java (which has FKT as the standard 
>>>> name and
>>>> FKST as the summer name) does not match the tz data file (which 
>>>> suggests
>>>> that Stanley has moved to use only summer zone), but since this 
>>>> appears
>>>> to be an existing issue that not related to this update, I keep the 
>>>> test data for
>>>> Stanley untouched.
>>>>
>>>> Tests list below have been run and passed.
>>>>
>>>> java/util/TimeZone
>>>> java/util/Calendar
>>>> java/util/Formatter
>>>> java/time
>>>> closed/java/util/TimeZone
>>>> closed/java/util/Calendar
>>>>
>>>> webrev:
>>>>
>>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/
>>>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/
>>>>
>>>> Thanks!
>>>> Sherman
>>>
>>
>


From masayoshi.okutsu at oracle.com  Fri May 10 02:57:44 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 10 May 2013 18:57:44 +0900
Subject: <i18n dev> RFR  JDK-8013386: (tz) Support tzdata2013c
In-Reply-To: <518C93EC.9080209@oracle.com>
References: <518ACFB3.5030000@oracle.com> <518B6705.3050203@oracle.com>
	<518C3049.5050801@oracle.com> <518C7E30.8030302@oracle.com>
	<518C93EC.9080209@oracle.com>
Message-ID: <518CC498.2020000@oracle.com>

On 5/10/2013 3:30 PM, Xueming Shen wrote:
> On 5/9/13 9:57 PM, Masayoshi Okutsu wrote:
>> Do we still need to keep the old javazic code in JDK8? It's a 
>> maintenance burden to maintain both, isn't it?
>>
>
> While it's a burden, but somehow it serves as a test case pretty well. 
> The transitions are
> being built the "old" jdk way and threeten way, if the transition does 
> not match, something
> might be wrong. This time, it's in the "old" code, maybe next time 
> it's in the threeten. So
> it might be still worth keeping a while, to remove in jdk9? Btw, the 
> Rule.java fix might need
> go into the tzdb update tool as well, I believe the transitions for 
> 2011 Palestine are wrong in
> the updated tzdb updator.

Yes, the Rule.java fix needs to go to older JDKs and TZ updater (build 
system).

Masayoshi

>
>> I'm concerned about the 24:00 fix. Is there any way to produce the 
>> correct rules without hard coding time zone IDs?
>
> I don't know how to do it, yet. I definitely can have a RFE for it and 
> spend some time on
> it later.
>
> -Sherman
>
>>
>> Masayoshi
>>
>> On 5/10/2013 8:24 AM, Xueming Shen wrote:
>>> Hi Sean,
>>>
>>> Thanks for the review. It appears I missed 
>>> jdk/test/sun/util/calendar/zi/tzdata,
>>> webrev has been updated to include the test data update.
>>>
>>> http://cr.openjdk.java.net/~sherman/8013386/webrev
>>>
>>> I will update TCKZoneRulesProvider.java separately in JSR310 repo, 
>>> this def is
>>> actually is not being used by anyone anymore, just need to be removed.
>>>
>>> jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be 
>>> removed, I
>>> will remove it separately later.
>>>
>>>
>>> Masayoshi,
>>>
>>> The update also included the two changes needed to fix/workaround 
>>> the following 2
>>> issues found during running the regression test
>>>
>>>      jdk/test/sun/util/calendar/zi/TestZoneInfo310.java,
>>>
>>> due to the changes for Rule Palestine and the corresponding Zone 
>>> Asia/Gaza and
>>> Asia/Hebron [1].
>>>
>>> (1) Now the Rule Palestine has the def of "lastThu 24:00", similar 
>>> to Asia/Amman, so
>>> these two zones need to be handled specially in ZoneInfoFile as well 
>>> [2]
>>>
>>> (2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 
>>> transitions for 2011
>>> when returned from Rule.getRules(int year). Unfortunately it appears 
>>> the Comparator
>>> for Arrays.sorting is incorrectly implemented when comparing two 
>>> longs [3]. The directly
>>> consequence of this decade-old bug is that the returned list has the 
>>> wrong order for
>>> 2011/08/01/xxx and 2011/08/30/xxx
>>>
>>> Please help review.
>>>
>>> Thanks!
>>> -Sherman
>>>
>>> [1] 
>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html
>>> [2] 
>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html
>>> [3] 
>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html
>>>
>>> On 05/09/2013 02:06 AM, Se?n Coffey wrote:
>>>> Thanks for taking care of this Sherman. I was wondering what sort 
>>>> of impact JSR 310 would make on tzdata updates. The 
>>>> Atlantic/Stanley display name issue mentioned is a regular one, we 
>>>> should log a bug against the test file generation scripts.
>>>>
>>>> I just had a quick grok of the jdk8 repo. The following files need 
>>>> updating also :
>>>>
>>>> jdk/test/sun/util/calendar/zi/tzdata/*
>>>> jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java 
>>>> (line 85)
>>>> jdk/makefiles/GendataTimeZone.gmk (line 29)
>>>>
>>>> It looks like jdk/makefiles/GendataTimeZone.gmk still has a 
>>>> dependency on reading files from jdk/make. That'll all have to 
>>>> change too once the old build system is removed from jdk8. I think 
>>>> the new tzdata sources should be moved into a directory under 
>>>> makefiles rather than keeping them in make.
>>>>
>>>> The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in 
>>>> jdk/makefiles/GendataTimeZone.gmk  should be removed if we know 
>>>> that the version string can be read from the VERSION file stored 
>>>> with tzdata.
>>>>
>>>> Above points are not necessarily related to 2013c update and should 
>>>> be cleaned up separately perhaps.
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>> On 08/05/2013 23:20, Xueming Shen wrote:
>>>>> Hi,
>>>>>
>>>>> Please help review the proposed change to update the tz data
>>>>> in JDK8 from 2012i to 2013c.
>>>>>
>>>>> Other than the tzdb data file update under make/sun/javazic/tzdata,
>>>>> corresponding updates have also been made in TimeZoneNames***.java
>>>>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
>>>>> zone display names (from EET to CET) for Africa/Tripoli (and its 
>>>>> alias Libya)
>>>>>
>>>>> test/java/util/TimeZone/tools/share/Make has been run to generate the
>>>>> new test data at TimeZoneData.
>>>>>
>>>>> # I have to update the displaynames.txt "manually" to undo the change
>>>>> for Atlantic/Stanley from "FKST" (which is defined in 
>>>>> southamerica.txt both
>>>>> in 2012i and 2013c, there is no change for Stanley from 2012i to 
>>>>> 2013c)
>>>>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure 
>>>>> why the
>>>>> definition in TimeZoneNames.java (which has FKT as the standard 
>>>>> name and
>>>>> FKST as the summer name) does not match the tz data file (which 
>>>>> suggests
>>>>> that Stanley has moved to use only summer zone), but since this 
>>>>> appears
>>>>> to be an existing issue that not related to this update, I keep 
>>>>> the test data for
>>>>> Stanley untouched.
>>>>>
>>>>> Tests list below have been run and passed.
>>>>>
>>>>> java/util/TimeZone
>>>>> java/util/Calendar
>>>>> java/util/Formatter
>>>>> java/time
>>>>> closed/java/util/TimeZone
>>>>> closed/java/util/Calendar
>>>>>
>>>>> webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/
>>>>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/
>>>>>
>>>>> Thanks!
>>>>> Sherman
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Sun May 12 22:21:46 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 13 May 2013 14:21:46 +0900
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <51897BE6.40005@oracle.com>
References: <5187FB81.7080203@oracle.com> <5188837E.1060005@oracle.com>
	<51897BE6.40005@oracle.com>
Message-ID: <5190786A.8050007@oracle.com>

I think Objects.equals(Object, Object) should be used when comparing 
result and expected. Otherwise, the fix looks OK to me.

Masayoshi

On 5/8/2013 7:10 AM, Naoto Sato wrote:
> On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
>> Not sure how the test can detect bugs in the provider of the host
>> adapter.
>
> The test case only checks the Java side code paths, i.e., whether the 
> returned display name from the HOST adapter is honored over JRE's one 
> or not. In the case of "mk", that detects the failure.
>
>> BTW, some lines are very long requiring a wide screen monitor.
>
> Fixed: http://cr.openjdk.java.net/~naoto/8013233/webrev.01/
>
> Naoto
>
>>
>> Masayoshi
>>
>> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the following changeset:
>>>
>>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>>
>>> for the following bug:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>>
>>> The original test case assumed Windows ver 6.0 or upper always contain
>>> the localized display name for Macedonian, which wasn't the case in
>>> some installation. Removed the hard coded name and replaced them with
>>> the actual returned name from the host adapter.
>>>
>>> Naoto
>>
>


From xueming.shen at oracle.com  Mon May 13 10:22:03 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 13 May 2013 10:22:03 -0700
Subject: <i18n dev> [threeten-dev] RFR JDK-8013386: (tz) Support
	tzdata2013c
In-Reply-To: <518ACFB3.5030000@oracle.com>
References: <518ACFB3.5030000@oracle.com>
Message-ID: <5191213B.4070504@oracle.com>

It would be appreciated if you guys can help review before 5/15 us time here, so tz
update can get into M7, if it matters;-)

-Sherman

On 5/8/2013 3:20 PM, Xueming Shen wrote:
> Hi,
>
> Please help review the proposed change to update the tz data
> in JDK8 from 2012i to 2013c.
>
> Other than the tzdb data file update under make/sun/javazic/tzdata,
> corresponding updates have also been made in TimeZoneNames***.java
> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
> zone display names (from EET to CET) for Africa/Tripoli (and its alias Libya)
>
> test/java/util/TimeZone/tools/share/Make has been run to generate the
> new test data at TimeZoneData.
>
> # I have to update the displaynames.txt "manually" to undo the change
> for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt both
> in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the
> definition in TimeZoneNames.java (which has FKT as the standard name and
> FKST as the summer name) does not match the tz data file (which suggests
> that Stanley has moved to use only summer zone), but since this appears
> to be an existing issue that not related to this update, I keep the test data for
> Stanley untouched.
>
> Tests list below have been run and passed.
>
> java/util/TimeZone
> java/util/Calendar
> java/util/Formatter
> java/time
> closed/java/util/TimeZone
> closed/java/util/Calendar
>
> webrev:
>
> http://cr.openjdk.java.net/~sherman/8013386/webrev/
> http://cr.openjdk.java.net/~sherman/8013386/test.closed/
>
> Thanks!
> Sherman


From naoto.sato at oracle.com  Mon May 13 12:21:03 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 13 May 2013 12:21:03 -0700
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <5190786A.8050007@oracle.com>
References: <5187FB81.7080203@oracle.com> <5188837E.1060005@oracle.com>
	<51897BE6.40005@oracle.com> <5190786A.8050007@oracle.com>
Message-ID: <51913D1F.1090208@oracle.com>

Actually, the bug itself is the case that Objects.equals(result, 
expected) would fail. Since on that machine, result="mk" and 
expected=(null) where fallback kicks in. Maybe the variable name 
"expected" be replaced with something like "resultFromHOST", but the 
test itself cannot just use Objects.equals().

Naoto

On 5/12/13 10:21 PM, Masayoshi Okutsu wrote:
> I think Objects.equals(Object, Object) should be used when comparing
> result and expected. Otherwise, the fix looks OK to me.
>
> Masayoshi
>
> On 5/8/2013 7:10 AM, Naoto Sato wrote:
>> On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
>>> Not sure how the test can detect bugs in the provider of the host
>>> adapter.
>>
>> The test case only checks the Java side code paths, i.e., whether the
>> returned display name from the HOST adapter is honored over JRE's one
>> or not. In the case of "mk", that detects the failure.
>>
>>> BTW, some lines are very long requiring a wide screen monitor.
>>
>> Fixed: http://cr.openjdk.java.net/~naoto/8013233/webrev.01/
>>
>> Naoto
>>
>>>
>>> Masayoshi
>>>
>>> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the following changeset:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>>>
>>>> for the following bug:
>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>>>
>>>> The original test case assumed Windows ver 6.0 or upper always contain
>>>> the localized display name for Macedonian, which wasn't the case in
>>>> some installation. Removed the hard coded name and replaced them with
>>>> the actual returned name from the host adapter.
>>>>
>>>> Naoto
>>>
>>
>


From masayoshi.okutsu at oracle.com  Mon May 13 17:15:07 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 14 May 2013 09:15:07 +0900
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <51913D1F.1090208@oracle.com>
References: <5187FB81.7080203@oracle.com> <5188837E.1060005@oracle.com>
	<51897BE6.40005@oracle.com> <5190786A.8050007@oracle.com>
	<51913D1F.1090208@oracle.com>
Message-ID: <5191820B.1030600@oracle.com>

I see. The test case should get the expected value first, then. If 
expected == null, skip the test case (no need to get the result value)?

Masayoshi

On 5/14/2013 4:21 AM, Naoto Sato wrote:
> Actually, the bug itself is the case that Objects.equals(result, 
> expected) would fail. Since on that machine, result="mk" and 
> expected=(null) where fallback kicks in. Maybe the variable name 
> "expected" be replaced with something like "resultFromHOST", but the 
> test itself cannot just use Objects.equals().
>
> Naoto
>
> On 5/12/13 10:21 PM, Masayoshi Okutsu wrote:
>> I think Objects.equals(Object, Object) should be used when comparing
>> result and expected. Otherwise, the fix looks OK to me.
>>
>> Masayoshi
>>
>> On 5/8/2013 7:10 AM, Naoto Sato wrote:
>>> On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
>>>> Not sure how the test can detect bugs in the provider of the host
>>>> adapter.
>>>
>>> The test case only checks the Java side code paths, i.e., whether the
>>> returned display name from the HOST adapter is honored over JRE's one
>>> or not. In the case of "mk", that detects the failure.
>>>
>>>> BTW, some lines are very long requiring a wide screen monitor.
>>>
>>> Fixed: http://cr.openjdk.java.net/~naoto/8013233/webrev.01/
>>>
>>> Naoto
>>>
>>>>
>>>> Masayoshi
>>>>
>>>> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following changeset:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>>>>
>>>>> for the following bug:
>>>>>
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>>>>
>>>>> The original test case assumed Windows ver 6.0 or upper always 
>>>>> contain
>>>>> the localized display name for Macedonian, which wasn't the case in
>>>>> some installation. Removed the hard coded name and replaced them with
>>>>> the actual returned name from the host adapter.
>>>>>
>>>>> Naoto
>>>>
>>>
>>
>


From yuka.kamiya at oracle.com  Mon May 13 19:14:58 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Tue, 14 May 2013 11:14:58 +0900
Subject: <i18n dev> [threeten-dev] RFR JDK-8013386: (tz) Support
	tzdata2013c
In-Reply-To: <5191213B.4070504@oracle.com>
References: <518ACFB3.5030000@oracle.com> <5191213B.4070504@oracle.com>
Message-ID: <51919E22.2090209@oracle.com>

Hi Sherman,

Sorry for my late reply.

The fix looks ok to me.
But please remember to file an RFE about the hardcoded timezone IDs that Masayoshi mentioned. :-)

 >> I'm concerned about the 24:00 fix. Is there any way to produce the correct rules without hard coding time zone IDs?
 > I don't know how to do it, yet. I definitely can have a RFE for it and spend some time on it later.

Thanks,
--
Yuka

(2013/05/14 2:22), Xueming Shen wrote:
> It would be appreciated if you guys can help review before 5/15 us time here, so tz
> update can get into M7, if it matters;-)
>
> -Sherman
>
> On 5/8/2013 3:20 PM, Xueming Shen wrote:
>> Hi,
>>
>> Please help review the proposed change to update the tz data
>> in JDK8 from 2012i to 2013c.
>>
>> Other than the tzdb data file update under make/sun/javazic/tzdata,
>> corresponding updates have also been made in TimeZoneNames***.java
>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
>> zone display names (from EET to CET) for Africa/Tripoli (and its alias Libya)
>>
>> test/java/util/TimeZone/tools/share/Make has been run to generate the
>> new test data at TimeZoneData.
>>
>> # I have to update the displaynames.txt "manually" to undo the change
>> for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt both
>> in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the
>> definition in TimeZoneNames.java (which has FKT as the standard name and
>> FKST as the summer name) does not match the tz data file (which suggests
>> that Stanley has moved to use only summer zone), but since this appears
>> to be an existing issue that not related to this update, I keep the test data for
>> Stanley untouched.
>>
>> Tests list below have been run and passed.
>>
>> java/util/TimeZone
>> java/util/Calendar
>> java/util/Formatter
>> java/time
>> closed/java/util/TimeZone
>> closed/java/util/Calendar
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~sherman/8013386/webrev/
>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/
>>
>> Thanks!
>> Sherman
>


From xueming.shen at oracle.com  Mon May 13 20:44:20 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 13 May 2013 20:44:20 -0700
Subject: <i18n dev> [threeten-dev] RFR JDK-8013386: (tz) Support
	tzdata2013c
In-Reply-To: <51919E22.2090209@oracle.com>
References: <518ACFB3.5030000@oracle.com> <5191213B.4070504@oracle.com>
	<51919E22.2090209@oracle.com>
Message-ID: <5191B314.1060509@oracle.com>

Thanks Yuka! #8014468 has been filed for the "special workaround" issue.

-Sherman

On 05/13/2013 07:14 PM, Yuka Kamiya wrote:
> Hi Sherman,
>
> Sorry for my late reply.
>
> The fix looks ok to me.
> But please remember to file an RFE about the hardcoded timezone IDs that Masayoshi mentioned. :-)
>
> >> I'm concerned about the 24:00 fix. Is there any way to produce the correct rules without hard coding time zone IDs?
> > I don't know how to do it, yet. I definitely can have a RFE for it and spend some time on it later.
>
> Thanks,
> -- 
> Yuka
>
> (2013/05/14 2:22), Xueming Shen wrote:
>> It would be appreciated if you guys can help review before 5/15 us time here, so tz
>> update can get into M7, if it matters;-)
>>
>> -Sherman
>>
>> On 5/8/2013 3:20 PM, Xueming Shen wrote:
>>> Hi,
>>>
>>> Please help review the proposed change to update the tz data
>>> in JDK8 from 2012i to 2013c.
>>>
>>> Other than the tzdb data file update under make/sun/javazic/tzdata,
>>> corresponding updates have also been made in TimeZoneNames***.java
>>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated
>>> zone display names (from EET to CET) for Africa/Tripoli (and its alias Libya)
>>>
>>> test/java/util/TimeZone/tools/share/Make has been run to generate the
>>> new test data at TimeZoneData.
>>>
>>> # I have to update the displaynames.txt "manually" to undo the change
>>> for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt both
>>> in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c)
>>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the
>>> definition in TimeZoneNames.java (which has FKT as the standard name and
>>> FKST as the summer name) does not match the tz data file (which suggests
>>> that Stanley has moved to use only summer zone), but since this appears
>>> to be an existing issue that not related to this update, I keep the test data for
>>> Stanley untouched.
>>>
>>> Tests list below have been run and passed.
>>>
>>> java/util/TimeZone
>>> java/util/Calendar
>>> java/util/Formatter
>>> java/time
>>> closed/java/util/TimeZone
>>> closed/java/util/Calendar
>>>
>>> webrev:
>>>
>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/
>>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/
>>>
>>> Thanks!
>>> Sherman
>>
>


From anthony.petrov at oracle.com  Tue May 14 05:30:02 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 14 May 2013 16:30:02 +0400
Subject: <i18n dev> <AWT Dev> Preedit string is still exist after focus
	change operation
In-Reply-To: <518B5156.7060205@linux.vnet.ibm.com>
References: <518B5156.7060205@linux.vnet.ibm.com>
Message-ID: <51922E4A.4080004@oracle.com>

Hi Deven,

I'm copying i18n-dev@ because they manage the IM code.

As to a test, jtreg supports manual tests. See [1] for a lot of tips 
about using manual tests. An example of a manual test is at:

jdk/test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter.java

[1] http://openjdk.java.net/jtreg/faq.html

--
best regards,
Anthony

On 05/09/2013 11:33 AM, Deven You wrote:
> Hi All,
>
> I found there is a problem with our IMF(Input Methods Framework) when
> dealing with DBCS input like Chinese and Japanese on Windows 7 32bit env.
>
> The simple scenario is if your application has 2 windows and then:
>
> 1: focus on first window, change to microsoft pinyin input method
> Chinese mode.
> 2: Input some words, leave some words in preedit string not committed.
> 3: Move focus to the other window, change to English mode and input
> something
> 4: Move back to the first window. It is in English mode, but the preedit
> string is still there(this is the bug).
> 5: Delete the preedit string with backspace and press enter, it appears
> again.
>
> I have raised  a sunbug for this issue, the internal ID is: 9002399
>
> I have written a test case[1] to reproduce this problem on windows 7 32
> bit machine with latest OpenJDK 8.
> Since I am not clear how to run this test case as a jtreg, I just put it
> to cr.openjdk.java.net. There are several files within this test case:
>
> actual-step*.png                    Steps reproducing the bug. (can not )
> JTextAreaTest3.java                 The test case.
> Readme.txt                              Simple description
> IMF_04_69120.txt                    More detail.
>
> I also made possible patch[2] for this problem.
>
> Please anyone take a look at this issue and give your suggestion.
>
> [1] http://cr.openjdk.java.net/~youdwei/ojdk-687/IMF4/
> <http://cr.openjdk.java.net/%7Eyoudwei/ojdk-687/IMF4/>
> [2] http://cr.openjdk.java.net/~youdwei/ojdk-687/webrev/
> <http://cr.openjdk.java.net/%7Eyoudwei/ojdk-687/webrev/>
>
> Thanks a lot!

From naoto.sato at oracle.com  Tue May 14 09:06:00 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 14 May 2013 09:06:00 -0700
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <5191820B.1030600@oracle.com>
References: <5187FB81.7080203@oracle.com> <5188837E.1060005@oracle.com>
	<51897BE6.40005@oracle.com> <5190786A.8050007@oracle.com>
	<51913D1F.1090208@oracle.com> <5191820B.1030600@oracle.com>
Message-ID: <519260E8.5040402@oracle.com>

Well, I just want to make sure that, in case of expected == null, the 
result value still is non null, which assures that FALLBACK provider has 
kicked in. So I think checking "result != null" is still needed.

Naoto

On 5/13/13 5:15 PM, Masayoshi Okutsu wrote:
> I see. The test case should get the expected value first, then. If
> expected == null, skip the test case (no need to get the result value)?
>
> Masayoshi
>
> On 5/14/2013 4:21 AM, Naoto Sato wrote:
>> Actually, the bug itself is the case that Objects.equals(result,
>> expected) would fail. Since on that machine, result="mk" and
>> expected=(null) where fallback kicks in. Maybe the variable name
>> "expected" be replaced with something like "resultFromHOST", but the
>> test itself cannot just use Objects.equals().
>>
>> Naoto
>>
>> On 5/12/13 10:21 PM, Masayoshi Okutsu wrote:
>>> I think Objects.equals(Object, Object) should be used when comparing
>>> result and expected. Otherwise, the fix looks OK to me.
>>>
>>> Masayoshi
>>>
>>> On 5/8/2013 7:10 AM, Naoto Sato wrote:
>>>> On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
>>>>> Not sure how the test can detect bugs in the provider of the host
>>>>> adapter.
>>>>
>>>> The test case only checks the Java side code paths, i.e., whether the
>>>> returned display name from the HOST adapter is honored over JRE's one
>>>> or not. In the case of "mk", that detects the failure.
>>>>
>>>>> BTW, some lines are very long requiring a wide screen monitor.
>>>>
>>>> Fixed: http://cr.openjdk.java.net/~naoto/8013233/webrev.01/
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> Masayoshi
>>>>>
>>>>> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following changeset:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>>>>>
>>>>>> for the following bug:
>>>>>>
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>>>>>
>>>>>> The original test case assumed Windows ver 6.0 or upper always
>>>>>> contain
>>>>>> the localized display name for Macedonian, which wasn't the case in
>>>>>> some installation. Removed the hard coded name and replaced them with
>>>>>> the actual returned name from the host adapter.
>>>>>>
>>>>>> Naoto
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Tue May 14 11:37:29 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 14 May 2013 11:37:29 -0700
Subject: <i18n dev> <AWT Dev> Preedit string is still exist after focus
 change operation
In-Reply-To: <51922E4A.4080004@oracle.com>
References: <518B5156.7060205@linux.vnet.ibm.com> <51922E4A.4080004@oracle.com>
Message-ID: <51928469.6090009@oracle.com>

It does sound like a bug. Moved the web incidents into a JDK bug (8014558)

Naoto

On 5/14/13 5:30 AM, Anthony Petrov wrote:
> Hi Deven,
>
> I'm copying i18n-dev@ because they manage the IM code.
>
> As to a test, jtreg supports manual tests. See [1] for a lot of tips
> about using manual tests. An example of a manual test is at:
>
> jdk/test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter.java
>
> [1] http://openjdk.java.net/jtreg/faq.html
>
> --
> best regards,
> Anthony
>
> On 05/09/2013 11:33 AM, Deven You wrote:
>> Hi All,
>>
>> I found there is a problem with our IMF(Input Methods Framework) when
>> dealing with DBCS input like Chinese and Japanese on Windows 7 32bit env.
>>
>> The simple scenario is if your application has 2 windows and then:
>>
>> 1: focus on first window, change to microsoft pinyin input method
>> Chinese mode.
>> 2: Input some words, leave some words in preedit string not committed.
>> 3: Move focus to the other window, change to English mode and input
>> something
>> 4: Move back to the first window. It is in English mode, but the preedit
>> string is still there(this is the bug).
>> 5: Delete the preedit string with backspace and press enter, it appears
>> again.
>>
>> I have raised  a sunbug for this issue, the internal ID is: 9002399
>>
>> I have written a test case[1] to reproduce this problem on windows 7 32
>> bit machine with latest OpenJDK 8.
>> Since I am not clear how to run this test case as a jtreg, I just put it
>> to cr.openjdk.java.net. There are several files within this test case:
>>
>> actual-step*.png                    Steps reproducing the bug. (can not )
>> JTextAreaTest3.java                 The test case.
>> Readme.txt                              Simple description
>> IMF_04_69120.txt                    More detail.
>>
>> I also made possible patch[2] for this problem.
>>
>> Please anyone take a look at this issue and give your suggestion.
>>
>> [1] http://cr.openjdk.java.net/~youdwei/ojdk-687/IMF4/
>> <http://cr.openjdk.java.net/%7Eyoudwei/ojdk-687/IMF4/>
>> [2] http://cr.openjdk.java.net/~youdwei/ojdk-687/webrev/
>> <http://cr.openjdk.java.net/%7Eyoudwei/ojdk-687/webrev/>
>>
>> Thanks a lot!


From masayoshi.okutsu at oracle.com  Tue May 14 21:22:05 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 15 May 2013 13:22:05 +0900
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <519260E8.5040402@oracle.com>
References: <5187FB81.7080203@oracle.com> <5188837E.1060005@oracle.com>
	<51897BE6.40005@oracle.com> <5190786A.8050007@oracle.com>
	<51913D1F.1090208@oracle.com> <5191820B.1030600@oracle.com>
	<519260E8.5040402@oracle.com>
Message-ID: <51930D6D.9000002@oracle.com>

Do you mean this?

         if (result == null ||
             expected != null &&
             !result.equals(expected)) {
                 throw new RuntimeException(...);
         }

Masayoshi

On 5/15/2013 1:06 AM, Naoto Sato wrote:
> Well, I just want to make sure that, in case of expected == null, the 
> result value still is non null, which assures that FALLBACK provider 
> has kicked in. So I think checking "result != null" is still needed.
>
> Naoto
>
> On 5/13/13 5:15 PM, Masayoshi Okutsu wrote:
>> I see. The test case should get the expected value first, then. If
>> expected == null, skip the test case (no need to get the result value)?
>>
>> Masayoshi
>>
>> On 5/14/2013 4:21 AM, Naoto Sato wrote:
>>> Actually, the bug itself is the case that Objects.equals(result,
>>> expected) would fail. Since on that machine, result="mk" and
>>> expected=(null) where fallback kicks in. Maybe the variable name
>>> "expected" be replaced with something like "resultFromHOST", but the
>>> test itself cannot just use Objects.equals().
>>>
>>> Naoto
>>>
>>> On 5/12/13 10:21 PM, Masayoshi Okutsu wrote:
>>>> I think Objects.equals(Object, Object) should be used when comparing
>>>> result and expected. Otherwise, the fix looks OK to me.
>>>>
>>>> Masayoshi
>>>>
>>>> On 5/8/2013 7:10 AM, Naoto Sato wrote:
>>>>> On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
>>>>>> Not sure how the test can detect bugs in the provider of the host
>>>>>> adapter.
>>>>>
>>>>> The test case only checks the Java side code paths, i.e., whether the
>>>>> returned display name from the HOST adapter is honored over JRE's one
>>>>> or not. In the case of "mk", that detects the failure.
>>>>>
>>>>>> BTW, some lines are very long requiring a wide screen monitor.
>>>>>
>>>>> Fixed: http://cr.openjdk.java.net/~naoto/8013233/webrev.01/
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> Masayoshi
>>>>>>
>>>>>> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following changeset:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>>>>>>
>>>>>>> for the following bug:
>>>>>>>
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>>>>>>
>>>>>>> The original test case assumed Windows ver 6.0 or upper always
>>>>>>> contain
>>>>>>> the localized display name for Macedonian, which wasn't the case in
>>>>>>> some installation. Removed the hard coded name and replaced them 
>>>>>>> with
>>>>>>> the actual returned name from the host adapter.
>>>>>>>
>>>>>>> Naoto
>>>>>>
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Wed May 15 13:55:49 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 15 May 2013 13:55:49 -0700
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <51930D6D.9000002@oracle.com>
References: <5187FB81.7080203@oracle.com> <5188837E.1060005@oracle.com>
	<51897BE6.40005@oracle.com> <5190786A.8050007@oracle.com>
	<51913D1F.1090208@oracle.com> <5191820B.1030600@oracle.com>
	<519260E8.5040402@oracle.com> <51930D6D.9000002@oracle.com>
Message-ID: <5193F655.4060602@oracle.com>

I initially thought the case only for result==null && expected!=null, 
but your test looks better. Here is the modified webrev, with the 
variable name "expected" replaced with "hostResult" to avoid confusion.

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

Naoto

On 5/14/13 9:22 PM, Masayoshi Okutsu wrote:
> Do you mean this?
>
>          if (result == null ||
>              expected != null &&
>              !result.equals(expected)) {
>                  throw new RuntimeException(...);
>          }
>
> Masayoshi
>
> On 5/15/2013 1:06 AM, Naoto Sato wrote:
>> Well, I just want to make sure that, in case of expected == null, the
>> result value still is non null, which assures that FALLBACK provider
>> has kicked in. So I think checking "result != null" is still needed.
>>
>> Naoto
>>
>> On 5/13/13 5:15 PM, Masayoshi Okutsu wrote:
>>> I see. The test case should get the expected value first, then. If
>>> expected == null, skip the test case (no need to get the result value)?
>>>
>>> Masayoshi
>>>
>>> On 5/14/2013 4:21 AM, Naoto Sato wrote:
>>>> Actually, the bug itself is the case that Objects.equals(result,
>>>> expected) would fail. Since on that machine, result="mk" and
>>>> expected=(null) where fallback kicks in. Maybe the variable name
>>>> "expected" be replaced with something like "resultFromHOST", but the
>>>> test itself cannot just use Objects.equals().
>>>>
>>>> Naoto
>>>>
>>>> On 5/12/13 10:21 PM, Masayoshi Okutsu wrote:
>>>>> I think Objects.equals(Object, Object) should be used when comparing
>>>>> result and expected. Otherwise, the fix looks OK to me.
>>>>>
>>>>> Masayoshi
>>>>>
>>>>> On 5/8/2013 7:10 AM, Naoto Sato wrote:
>>>>>> On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
>>>>>>> Not sure how the test can detect bugs in the provider of the host
>>>>>>> adapter.
>>>>>>
>>>>>> The test case only checks the Java side code paths, i.e., whether the
>>>>>> returned display name from the HOST adapter is honored over JRE's one
>>>>>> or not. In the case of "mk", that detects the failure.
>>>>>>
>>>>>>> BTW, some lines are very long requiring a wide screen monitor.
>>>>>>
>>>>>> Fixed: http://cr.openjdk.java.net/~naoto/8013233/webrev.01/
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>>>
>>>>>>> Masayoshi
>>>>>>>
>>>>>>> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the following changeset:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>>>>>>>
>>>>>>>> for the following bug:
>>>>>>>>
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>>>>>>>
>>>>>>>> The original test case assumed Windows ver 6.0 or upper always
>>>>>>>> contain
>>>>>>>> the localized display name for Macedonian, which wasn't the case in
>>>>>>>> some installation. Removed the hard coded name and replaced them
>>>>>>>> with
>>>>>>>> the actual returned name from the host adapter.
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Wed May 15 16:29:39 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 16 May 2013 08:29:39 +0900
Subject: <i18n dev> [8] RFR: 8013233,
 java/util/Locale/LocaleProviders.sh fails
In-Reply-To: <5193F655.4060602@oracle.com>
References: <5187FB81.7080203@oracle.com> <5188837E.1060005@oracle.com>
	<51897BE6.40005@oracle.com> <5190786A.8050007@oracle.com>
	<51913D1F.1090208@oracle.com> <5191820B.1030600@oracle.com>
	<519260E8.5040402@oracle.com> <51930D6D.9000002@oracle.com>
	<5193F655.4060602@oracle.com>
Message-ID: <51941A63.10104@oracle.com>

Looks good to me.

Masayoshi

On 5/16/2013 5:55 AM, Naoto Sato wrote:
> I initially thought the case only for result==null && expected!=null, 
> but your test looks better. Here is the modified webrev, with the 
> variable name "expected" replaced with "hostResult" to avoid confusion.
>
> http://cr.openjdk.java.net/~naoto/8013233/webrev.02/
>
> Naoto
>
> On 5/14/13 9:22 PM, Masayoshi Okutsu wrote:
>> Do you mean this?
>>
>>          if (result == null ||
>>              expected != null &&
>>              !result.equals(expected)) {
>>                  throw new RuntimeException(...);
>>          }
>>
>> Masayoshi
>>
>> On 5/15/2013 1:06 AM, Naoto Sato wrote:
>>> Well, I just want to make sure that, in case of expected == null, the
>>> result value still is non null, which assures that FALLBACK provider
>>> has kicked in. So I think checking "result != null" is still needed.
>>>
>>> Naoto
>>>
>>> On 5/13/13 5:15 PM, Masayoshi Okutsu wrote:
>>>> I see. The test case should get the expected value first, then. If
>>>> expected == null, skip the test case (no need to get the result 
>>>> value)?
>>>>
>>>> Masayoshi
>>>>
>>>> On 5/14/2013 4:21 AM, Naoto Sato wrote:
>>>>> Actually, the bug itself is the case that Objects.equals(result,
>>>>> expected) would fail. Since on that machine, result="mk" and
>>>>> expected=(null) where fallback kicks in. Maybe the variable name
>>>>> "expected" be replaced with something like "resultFromHOST", but the
>>>>> test itself cannot just use Objects.equals().
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 5/12/13 10:21 PM, Masayoshi Okutsu wrote:
>>>>>> I think Objects.equals(Object, Object) should be used when comparing
>>>>>> result and expected. Otherwise, the fix looks OK to me.
>>>>>>
>>>>>> Masayoshi
>>>>>>
>>>>>> On 5/8/2013 7:10 AM, Naoto Sato wrote:
>>>>>>> On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
>>>>>>>> Not sure how the test can detect bugs in the provider of the host
>>>>>>>> adapter.
>>>>>>>
>>>>>>> The test case only checks the Java side code paths, i.e., 
>>>>>>> whether the
>>>>>>> returned display name from the HOST adapter is honored over 
>>>>>>> JRE's one
>>>>>>> or not. In the case of "mk", that detects the failure.
>>>>>>>
>>>>>>>> BTW, some lines are very long requiring a wide screen monitor.
>>>>>>>
>>>>>>> Fixed: http://cr.openjdk.java.net/~naoto/8013233/webrev.01/
>>>>>>>
>>>>>>> Naoto
>>>>>>>
>>>>>>>>
>>>>>>>> Masayoshi
>>>>>>>>
>>>>>>>> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the following changeset:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>>>>>>>>
>>>>>>>>> for the following bug:
>>>>>>>>>
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>>>>>>>>
>>>>>>>>> The original test case assumed Windows ver 6.0 or upper always
>>>>>>>>> contain
>>>>>>>>> the localized display name for Macedonian, which wasn't the 
>>>>>>>>> case in
>>>>>>>>> some installation. Removed the hard coded name and replaced them
>>>>>>>>> with
>>>>>>>>> the actual returned name from the host adapter.
>>>>>>>>>
>>>>>>>>> Naoto
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Thu May 16 14:59:44 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 16 May 2013 14:59:44 -0700
Subject: <i18n dev> [8] Request for Review: 8013903: Japanese calendar field
 names are not displayed with -Djava.locale.providers=HOST on Windows
Message-ID: <519556D0.9080101@oracle.com>

Please review the fix for the following bug:

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

The webrev is located at:

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

Here's the summary of the changes:
- Removed CalendarNameProvider implementation in Windows HOST adapter.
- Fixed FALLBACK provider to only work in the case of ROOT locale.

Naoto

From yong.huang at oracle.com  Fri May 17 01:23:30 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Fri, 17 May 2013 16:23:30 +0800
Subject: <i18n dev> Review Request - 7074882 : Locale data needs correction
 (Month names for Maltese language)
Message-ID: <5195E902.6060309@oracle.com>

Hello,

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

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

thanks,
Yong


From naoto.sato at oracle.com  Mon May 20 13:19:37 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 20 May 2013 13:19:37 -0700
Subject: <i18n dev> Review Request - 7074882 : Locale data needs
 correction (Month names for Maltese language)
In-Reply-To: <5195E902.6060309@oracle.com>
References: <5195E902.6060309@oracle.com>
Message-ID: <519A8559.1030806@oracle.com>

Looks good to me.

Naoto

On 5/17/13 1:23 AM, Yong Huang wrote:
> Hello,
>
> This is the review request for 7074882,
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7074882.
>
> Webrev:
> http://cr.openjdk.java.net/~yhuang/7074882/webrev.00/
>
> thanks,
> Yong
>


From naoto.sato at oracle.com  Wed May 22 11:45:18 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 22 May 2013 11:45:18 -0700
Subject: <i18n dev> [8] Request for document changes review
Message-ID: <519D123E.1090608@oracle.com>

Hello,

Please review the changes for the following two simple document fixes:

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

The proposed webrev is located at:

http://cr.openjdk.java.net/~naoto/7056126.7083668/

Naoto

From masayoshi.okutsu at oracle.com  Wed May 22 15:57:03 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 23 May 2013 07:57:03 +0900
Subject: <i18n dev> [8] Request for document changes review
In-Reply-To: <519D123E.1090608@oracle.com>
References: <519D123E.1090608@oracle.com>
Message-ID: <519D4D3F.30601@oracle.com>

Looks good to me.

Masayoshi

On 5/23/2013 3:45 AM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following two simple document fixes:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7056126
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7083668
>
> The proposed webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/7056126.7083668/
>
> Naoto


From yuka.kamiya at oracle.com  Fri May 24 06:19:53 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 24 May 2013 22:19:53 +0900
Subject: <i18n dev> [8] Request for document changes review
In-Reply-To: <519D123E.1090608@oracle.com>
References: <519D123E.1090608@oracle.com>
Message-ID: <519F68F9.8080502@oracle.com>

Hi,

The fix looks ok to me.

Thanks,
--
Yuka


(2013/05/23 3:45), Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following two simple document fixes:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7056126
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7083668
>
> The proposed webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/7056126.7083668/
>
> Naoto


From yuka.kamiya at oracle.com  Wed May 29 01:50:36 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 29 May 2013 17:50:36 +0900
Subject: <i18n dev> Review request for 8014469 and 8015570 for 7u40
Message-ID: <51A5C15C.40707@oracle.com>

Masayoshi,

Could you please review my fix for the following bugs?

http://bugs.sun.com/view_bug.do?bug_id=8014469
8014469 : (tz) Support tzdata2013c
http://bugs.sun.com/view_bug.do?bug_id=8015570 (may not be browseable yet)
8015570: Use long comparison in Rule.getRules().

webrev: http://cr.openjdk.java.net/~peytoia/8014469.8015570/webrev/


This webrev is a part of the webrev that I showed you today and contains changes in opened area only.
I need an approval in an OpenJDK thread to get an approval for 7u40.

Thanks,
--
Yuka

From masayoshi.okutsu at oracle.com  Wed May 29 07:44:15 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 29 May 2013 23:44:15 +0900
Subject: <i18n dev> Review request for 8014469 and 8015570 for 7u40
In-Reply-To: <51A5C15C.40707@oracle.com>
References: <51A5C15C.40707@oracle.com>
Message-ID: <51A6143F.2060203@oracle.com>

Looks good to me.

Masayoshi

On 5/29/2013 5:50 PM, Yuka Kamiya wrote:
> Masayoshi,
>
> Could you please review my fix for the following bugs?
>
> http://bugs.sun.com/view_bug.do?bug_id=8014469
> 8014469 : (tz) Support tzdata2013c
> http://bugs.sun.com/view_bug.do?bug_id=8015570 (may not be browseable yet)
> 8015570: Use long comparison in Rule.getRules().
>
> webrev: http://cr.openjdk.java.net/~peytoia/8014469.8015570/webrev/
>
>
> This webrev is a part of the webrev that I showed you today and contains changes in opened area only.
> I need an approval in an OpenJDK thread to get an approval for 7u40.
>
> Thanks,
> --
> Yuka


From naoto.sato at oracle.com  Fri May 31 16:58:43 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 31 May 2013 16:58:43 -0700
Subject: <i18n dev> [8] Request for Review: 8013903: Japanese calendar
 field names are not displayed with -Djava.locale.providers=HOST on Windows
In-Reply-To: <519556D0.9080101@oracle.com>
References: <519556D0.9080101@oracle.com>
Message-ID: <51A93933.9000807@oracle.com>

Hello,

I updated the fix according to an internal comment, which added a 
paragraph in java.util.spi.LocaleServiceProvider.java's class 
description. Other changes remain the same with the prior webrev.

Please review the following updated one:

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

Naoto

On 5/16/13 2:59 PM, Naoto Sato wrote:
> Please review the fix for the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013903
>
> The webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/8013903/webrev.00/
>
> Here's the summary of the changes:
> - Removed CalendarNameProvider implementation in Windows HOST adapter.
> - Fixed FALLBACK provider to only work in the case of ROOT locale.
>
> Naoto