From masayoshi.okutsu at oracle.com  Mon Jun  3 01:56:18 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 03 Jun 2013 17:56:18 +0900
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: <51A93933.9000807@oracle.com>
References: <519556D0.9080101@oracle.com> <51A93933.9000807@oracle.com>
Message-ID: <51AC5A32.4000004@oracle.com>

I'd suggest use of Collections.singleton(T o) for 
FallbackLocaleProviderAdapter.rootTagSet. Otherwise, the changes look 
good to me.

Thanks,
Masayoshi

On 6/1/2013 8:58 AM, Naoto Sato wrote:
> 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
>


From naoto.sato at oracle.com  Mon Jun  3 14:28:48 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 03 Jun 2013 14:28:48 -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: <51AC5A32.4000004@oracle.com>
References: <519556D0.9080101@oracle.com> <51A93933.9000807@oracle.com>
	<51AC5A32.4000004@oracle.com>
Message-ID: <51AD0A90.7090406@oracle.com>

Thanks. I should have known. Here is the revised webrev:

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

Naoto

On 6/3/13 1:56 AM, Masayoshi Okutsu wrote:
> I'd suggest use of Collections.singleton(T o) for
> FallbackLocaleProviderAdapter.rootTagSet. Otherwise, the changes look
> good to me.
>
> Thanks,
> Masayoshi
>
> On 6/1/2013 8:58 AM, Naoto Sato wrote:
>> 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
>>
>


From masayoshi.okutsu at oracle.com  Mon Jun  3 22:21:26 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 04 Jun 2013 14:21:26 +0900
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: <51AD0A90.7090406@oracle.com>
References: <519556D0.9080101@oracle.com> <51A93933.9000807@oracle.com>
	<51AC5A32.4000004@oracle.com> <51AD0A90.7090406@oracle.com>
Message-ID: <51AD7956.3020809@oracle.com>

Looks good to me.

Masayoshi

On 6/4/2013 6:28 AM, Naoto Sato wrote:
> Thanks. I should have known. Here is the revised webrev:
>
> http://cr.openjdk.java.net/~naoto/8013903/webrev.02/
>
> Naoto
>
> On 6/3/13 1:56 AM, Masayoshi Okutsu wrote:
>> I'd suggest use of Collections.singleton(T o) for
>> FallbackLocaleProviderAdapter.rootTagSet. Otherwise, the changes look
>> good to me.
>>
>> Thanks,
>> Masayoshi
>>
>> On 6/1/2013 8:58 AM, Naoto Sato wrote:
>>> 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
>>>
>>
>


From yong.huang at oracle.com  Mon Jun  3 23:06:56 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Tue, 04 Jun 2013 14:06:56 +0800
Subject: <i18n dev> Review Request - 7040556 : SimpleDateFormat.format
 Portuguese Month should not be capitalized
Message-ID: <51AD8400.6010903@oracle.com>

Hello,

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

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

thanks,
Yong

From masayoshi.okutsu at oracle.com  Tue Jun  4 02:22:45 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 04 Jun 2013 18:22:45 +0900
Subject: <i18n dev> Review Request - 7040556 : SimpleDateFormat.format
 Portuguese Month should not be capitalized
In-Reply-To: <51AD8400.6010903@oracle.com>
References: <51AD8400.6010903@oracle.com>
Message-ID: <51ADB1E5.4010601@oracle.com>

Looks good to me.

Masayoshi

On 6/4/2013 3:06 PM, Yong Huang wrote:
> Hello,
>
> This is the review request for 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7040556
>
> Webrev: http://cr.openjdk.java.net/~yhuang/7040556/webrev.00/
>
> thanks,
> Yong


From Alan.Bateman at oracle.com  Tue Jun  4 05:49:11 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 04 Jun 2013 13:49:11 +0100
Subject: <i18n dev> 8015880: GenerateBreakIteratorData build warning
Message-ID: <51ADE247.9020405@oracle.com>


The new build emits a lot of warnings, the warnings when building the 
build tools are the most scary. One warning that is starting to stand 
out (as other issues are addressed) is the GenerateBreakIteratorData 
tool. In the case the issue is that it overrides equals but not hashCode.

This is easily fixed by adding a hashCode method but if I read the code 
correctly, the equals method doesn't match its javadoc. The javadoc 
claims that it returns true if "that" has the exact same characters but 
that isn't so. I would like to fix this tool with the attached patch but 
it requires careful review because the broken equals method is used. 
I've run the jdk tests with this fix and don't see any issues but I 
don't know how well that BreakIterator is exercised.

-Alan


diff -r 780fbbd50ce4 
make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
--- 
a/make/tools/src/build/tools/generatebreakiteratordata/CharSet.java    
Tue Jun 04 11:52:29 2013 +0100
+++ 
b/make/tools/src/build/tools/generatebreakiteratordata/CharSet.java    
Tue Jun 04 13:08:24 2013 +0100
@@ -39,6 +39,7 @@

  package build.tools.generatebreakiteratordata;

+import java.util.Arrays;
  import java.util.Hashtable;

  /**
@@ -701,7 +702,14 @@
       * the exact same characters as this one
       */
      public boolean equals(Object that) {
-        return (that instanceof CharSet) && 
chars.equals(((CharSet)that).chars);
+        return (that instanceof CharSet) && Arrays.equals(chars, 
((CharSet)that).chars);
+    }
+
+    /**
+     * Returns the hash code for this set of characters
+     */
+    public int hashCode() {
+       return Arrays.hashCode(chars);
      }

      /**


From yuka.kamiya at oracle.com  Wed Jun  5 00:23:36 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 05 Jun 2013 16:23:36 +0900
Subject: <i18n dev> 8015880: GenerateBreakIteratorData build warning
In-Reply-To: <51ADE247.9020405@oracle.com>
References: <51ADE247.9020405@oracle.com>
Message-ID: <51AEE778.4040606@oracle.com>

Hi Alan,

Thank you for taking care of this.

I investigated how the method had been used. Your fix looks okay. It is not only safe but improves the generator's behavior.
I think that we were just lucky that the method had merely wasted CPU and didn't cause a worse problem....

Thanks,
--
Yuka


(2013/06/04 21:49), Alan Bateman wrote:
>
> The new build emits a lot of warnings, the warnings when building the build tools are the most scary. One warning that is starting to stand out (as other issues are addressed) is the GenerateBreakIteratorData tool. In the case the issue is that it overrides equals but not hashCode.
>
> This is easily fixed by adding a hashCode method but if I read the code correctly, the equals method doesn't match its javadoc. The javadoc claims that it returns true if "that" has the exact same characters but that isn't so. I would like to fix this tool with the attached patch but it requires careful review because the broken equals method is used. I've run the jdk tests with this fix and don't see any issues but I don't know how well that BreakIterator is exercised.
>
> -Alan
>
>
> diff -r 780fbbd50ce4 make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
> --- a/make/tools/src/build/tools/generatebreakiteratordata/CharSet.java Tue Jun 04 11:52:29 2013 +0100
> +++ b/make/tools/src/build/tools/generatebreakiteratordata/CharSet.java Tue Jun 04 13:08:24 2013 +0100
> @@ -39,6 +39,7 @@
>
>  package build.tools.generatebreakiteratordata;
>
> +import java.util.Arrays;
>  import java.util.Hashtable;
>
>  /**
> @@ -701,7 +702,14 @@
>       * the exact same characters as this one
>       */
>      public boolean equals(Object that) {
> -        return (that instanceof CharSet) && chars.equals(((CharSet)that).chars);
> +        return (that instanceof CharSet) && Arrays.equals(chars, ((CharSet)that).chars);
> +    }
> +
> +    /**
> +     * Returns the hash code for this set of characters
> +     */
> +    public int hashCode() {
> +       return Arrays.hashCode(chars);
>      }
>
>      /**
>


From naoto.sato at oracle.com  Wed Jun  5 10:47:04 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 05 Jun 2013 10:47:04 -0700
Subject: <i18n dev> 8015880: GenerateBreakIteratorData build warning
In-Reply-To: <51AEE778.4040606@oracle.com>
References: <51ADE247.9020405@oracle.com> <51AEE778.4040606@oracle.com>
Message-ID: <51AF7998.8090705@oracle.com>

What about the regression risk? With this fix, the equality would differ 
from the prior releases. Would that be ignorable?

Naoto

On 6/5/13 12:23 AM, Yuka Kamiya wrote:
> Hi Alan,
>
> Thank you for taking care of this.
>
> I investigated how the method had been used. Your fix looks okay. It is
> not only safe but improves the generator's behavior.
> I think that we were just lucky that the method had merely wasted CPU
> and didn't cause a worse problem....
>
> Thanks,
> --
> Yuka
>
>
> (2013/06/04 21:49), Alan Bateman wrote:
>>
>> The new build emits a lot of warnings, the warnings when building the
>> build tools are the most scary. One warning that is starting to stand
>> out (as other issues are addressed) is the GenerateBreakIteratorData
>> tool. In the case the issue is that it overrides equals but not hashCode.
>>
>> This is easily fixed by adding a hashCode method but if I read the
>> code correctly, the equals method doesn't match its javadoc. The
>> javadoc claims that it returns true if "that" has the exact same
>> characters but that isn't so. I would like to fix this tool with the
>> attached patch but it requires careful review because the broken
>> equals method is used. I've run the jdk tests with this fix and don't
>> see any issues but I don't know how well that BreakIterator is exercised.
>>
>> -Alan
>>
>>
>> diff -r 780fbbd50ce4
>> make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
>> ---
>> a/make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
>> Tue Jun 04 11:52:29 2013 +0100
>> +++
>> b/make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
>> Tue Jun 04 13:08:24 2013 +0100
>> @@ -39,6 +39,7 @@
>>
>>  package build.tools.generatebreakiteratordata;
>>
>> +import java.util.Arrays;
>>  import java.util.Hashtable;
>>
>>  /**
>> @@ -701,7 +702,14 @@
>>       * the exact same characters as this one
>>       */
>>      public boolean equals(Object that) {
>> -        return (that instanceof CharSet) &&
>> chars.equals(((CharSet)that).chars);
>> +        return (that instanceof CharSet) && Arrays.equals(chars,
>> ((CharSet)that).chars);
>> +    }
>> +
>> +    /**
>> +     * Returns the hash code for this set of characters
>> +     */
>> +    public int hashCode() {
>> +       return Arrays.hashCode(chars);
>>      }
>>
>>      /**
>>
>


From Alan.Bateman at oracle.com  Wed Jun  5 13:27:11 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Jun 2013 13:27:11 -0700 (PDT)
Subject: <i18n dev> 8015880: GenerateBreakIteratorData build warning
In-Reply-To: <51AF7998.8090705@oracle.com>
References: <51ADE247.9020405@oracle.com> <51AEE778.4040606@oracle.com>
	<51AF7998.8090705@oracle.com>
Message-ID: <51AF9F1F.3030603@oracle.com>

On 05/06/2013 18:47, Naoto Sato wrote:
> What about the regression risk? With this fix, the equality would 
> differ from the prior releases. Would that be ignorable?
>
> Naoto
This is the tool used in the build, it's the generated data files are 
that included in the runtime. I've run the regression tests on all 
platforms, is there anything else that I should run?

-Alan.

From naoto.sato at oracle.com  Wed Jun  5 13:30:19 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 05 Jun 2013 13:30:19 -0700
Subject: <i18n dev> 8015880: GenerateBreakIteratorData build warning
In-Reply-To: <51AF9F1F.3030603@oracle.com>
References: <51ADE247.9020405@oracle.com> <51AEE778.4040606@oracle.com>
	<51AF7998.8090705@oracle.com> <51AF9F1F.3030603@oracle.com>
Message-ID: <51AF9FDB.10501@oracle.com>

I'd compare the generated break iterator data binary before and after 
the fix to make sure it is not affecting the compatibility.

Naoto

On 6/5/13 1:27 PM, Alan Bateman wrote:
> On 05/06/2013 18:47, Naoto Sato wrote:
>> What about the regression risk? With this fix, the equality would
>> differ from the prior releases. Would that be ignorable?
>>
>> Naoto
> This is the tool used in the build, it's the generated data files are
> that included in the runtime. I've run the regression tests on all
> platforms, is there anything else that I should run?
>
> -Alan.


From masayoshi.okutsu at oracle.com  Wed Jun  5 16:18:40 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 06 Jun 2013 08:18:40 +0900
Subject: <i18n dev> 8015880: GenerateBreakIteratorData build warning
In-Reply-To: <51AF9FDB.10501@oracle.com>
References: <51ADE247.9020405@oracle.com> <51AEE778.4040606@oracle.com>
	<51AF7998.8090705@oracle.com> <51AF9F1F.3030603@oracle.com>
	<51AF9FDB.10501@oracle.com>
Message-ID: <51AFC750.9090401@oracle.com>

When I noticed the warning, actually I tried the exactly same fix (both 
equals and hashCode). It was supposed to generate the same data after 
the fix, but the fixed one didn't generate identical data. I haven't had 
time to look into it further.

Yesterday Yuka looked into the fixed tool and confirmed that the fix 
didn't affect the runtime. She found the equals part of the fix actually 
fixed the tool behavior (redundant loop cycles, etc.).

So I think the fix should be pushed.

Masayoshi

On 6/6/2013 5:30 AM, Naoto Sato wrote:
> I'd compare the generated break iterator data binary before and after 
> the fix to make sure it is not affecting the compatibility.
>
> Naoto
>
> On 6/5/13 1:27 PM, Alan Bateman wrote:
>> On 05/06/2013 18:47, Naoto Sato wrote:
>>> What about the regression risk? With this fix, the equality would
>>> differ from the prior releases. Would that be ignorable?
>>>
>>> Naoto
>> This is the tool used in the build, it's the generated data files are
>> that included in the runtime. I've run the regression tests on all
>> platforms, is there anything else that I should run?
>>
>> -Alan.
>


From masayoshi.okutsu at oracle.com  Wed Jun  5 19:50:19 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 06 Jun 2013 11:50:19 +0900
Subject: <i18n dev> Review request - 7177315: SimpleDateFormat parses wrong
 2-digit year if input contains spaces
Message-ID: <51AFF8EB.4030603@oracle.com>

Hello,

This is a review request for the fix of 7177315: SimpleDateFormat parses 
wrong 2-digit year if input contains spaces

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

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

Thanks,
Masayoshi


From Alan.Bateman at oracle.com  Thu Jun  6 01:57:57 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 06 Jun 2013 09:57:57 +0100
Subject: <i18n dev> 8015880: GenerateBreakIteratorData build warning
In-Reply-To: <51AFC750.9090401@oracle.com>
References: <51ADE247.9020405@oracle.com> <51AEE778.4040606@oracle.com>
	<51AF7998.8090705@oracle.com> <51AF9F1F.3030603@oracle.com>
	<51AF9FDB.10501@oracle.com> <51AFC750.9090401@oracle.com>
Message-ID: <51B04F15.6050008@oracle.com>

On 06/06/2013 00:18, Masayoshi Okutsu wrote:
> When I noticed the warning, actually I tried the exactly same fix 
> (both equals and hashCode). It was supposed to generate the same data 
> after the fix, but the fixed one didn't generate identical data. I 
> haven't had time to look into it further.
>
> Yesterday Yuka looked into the fixed tool and confirmed that the fix 
> didn't affect the runtime. She found the equals part of the fix 
> actually fixed the tool behavior (redundant loop cycles, etc.).
>
> So I think the fix should be pushed.
>
> Masayoshi
I pushed this yesterday (after Yuka's mail and after I tested it on all 
platforms).

One thing to say that a "diff -r" of 
$OUTPUTDIR/jdk/classes/sun/text/resources to compare the generated 
resources between before & after builds doesn't show any differences. I 
only did this on one platform, not all. So I'm curious about your 
comment, just in case I'm doing something wrong.

-Alan


From yuka.kamiya at oracle.com  Thu Jun  6 18:43:52 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 07 Jun 2013 10:43:52 +0900
Subject: <i18n dev> Review request - 7177315: SimpleDateFormat parses
 wrong 2-digit year if input contains spaces
In-Reply-To: <51AFF8EB.4030603@oracle.com>
References: <51AFF8EB.4030603@oracle.com>
Message-ID: <51B13AD8.2040702@oracle.com>

Hi,

The fix looks good to me.

Thanks,
--
Yuka


(2013/06/06 11:50), Masayoshi Okutsu wrote:
> Hello,
>
> This is a review request for the fix of 7177315: SimpleDateFormat parses wrong 2-digit year if input contains spaces
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177315
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/8/7177315/webrev.00/
>
> Thanks,
> Masayoshi
>


From masayoshi.okutsu at oracle.com  Fri Jun  7 01:24:46 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 07 Jun 2013 17:24:46 +0900
Subject: <i18n dev> Review request - 7064270:
 java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8
Message-ID: <51B198CE.2060701@oracle.com>

Hello,

This is a review request for the fix of:

7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 
hi_IN.UTF-8
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064270

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

Thanks,
Masayoshi


From yuka.kamiya at oracle.com  Fri Jun  7 01:33:30 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 07 Jun 2013 17:33:30 +0900
Subject: <i18n dev> Review request - 7064270:
 java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8
In-Reply-To: <51B198CE.2060701@oracle.com>
References: <51B198CE.2060701@oracle.com>
Message-ID: <51B19ADA.3010305@oracle.com>

Hi,

The fix looks good to me.

Thanks,
--
Yuka


(2013/06/07 17:24), Masayoshi Okutsu wrote:
> Hello,
>
> This is a review request for the fix of:
>
> 7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064270
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/8/7064270/webrev.00/
>
> Thanks,
> Masayoshi
>


From naoto.sato at oracle.com  Tue Jun 11 10:55:56 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 11 Jun 2013 10:55:56 -0700
Subject: <i18n dev> [8] Request for review: 8015960:
 java/util/Locale/LocaleProviders.java failing again on Windows
Message-ID: <51B764AC.8080005@oracle.com>

Hello,

Please review an one-liner fix for the following bug:

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

The fix is simply to set the time zone in the formatter to "PST":

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

Naoto

From Alan.Bateman at oracle.com  Tue Jun 11 11:07:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Jun 2013 19:07:50 +0100
Subject: <i18n dev> [8] Request for review: 8015960:
 java/util/Locale/LocaleProviders.java failing again on Windows
In-Reply-To: <51B764AC.8080005@oracle.com>
References: <51B764AC.8080005@oracle.com>
Message-ID: <51B76776.4090207@oracle.com>

On 11/06/2013 18:55, Naoto Sato wrote:
> Hello,
>
> Please review an one-liner fix for the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015960
>
> The fix is simply to set the time zone in the formatter to "PST":
>
> http://cr.openjdk.java.net/~naoto/8015960/webrev.00/
>
> Naoto
This looks okay to me (and doesn't need to be restored because the test 
runs in its own VM).

-Alan.

From naoto.sato at oracle.com  Tue Jun 11 11:16:50 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 11 Jun 2013 11:16:50 -0700
Subject: <i18n dev> [8] Request for review: 8015960:
 java/util/Locale/LocaleProviders.java failing again on Windows
In-Reply-To: <51B76776.4090207@oracle.com>
References: <51B764AC.8080005@oracle.com> <51B76776.4090207@oracle.com>
Message-ID: <51B76992.2040007@oracle.com>

On 6/11/13 11:07 AM, Alan Bateman wrote:
> On 11/06/2013 18:55, Naoto Sato wrote:
>> Hello,
>>
>> Please review an one-liner fix for the following bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015960
>>
>> The fix is simply to set the time zone in the formatter to "PST":
>>
>> http://cr.openjdk.java.net/~naoto/8015960/webrev.00/
>>
>> Naoto
> This looks okay to me (and doesn't need to be restored because the test
> runs in its own VM).

Thanks for the review. Actually the time zone is set to a 
SimpleDateFormat instance, not to the system default, so it is ok to not 
restore anyway.

Naoto

From Alan.Bateman at oracle.com  Tue Jun 11 11:12:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Jun 2013 11:12:22 -0700 (PDT)
Subject: <i18n dev> [8] Request for review: 8015960:
 java/util/Locale/LocaleProviders.java failing again on Windows
In-Reply-To: <51B76992.2040007@oracle.com>
References: <51B764AC.8080005@oracle.com> <51B76776.4090207@oracle.com>
	<51B76992.2040007@oracle.com>
Message-ID: <51B76886.8080309@oracle.com>

On 11/06/2013 19:16, Naoto Sato wrote:
>
> Thanks for the review. Actually the time zone is set to a 
> SimpleDateFormat instance, not to the system default, so it is ok to 
> not restore anyway.
Oh right, I had setDefault(TZ) on the brain from another discussion.

From masayoshi.okutsu at oracle.com  Tue Jun 11 16:09:38 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 12 Jun 2013 08:09:38 +0900
Subject: <i18n dev> [8] Request for review: 8015960:
 java/util/Locale/LocaleProviders.java failing again on Windows
In-Reply-To: <51B764AC.8080005@oracle.com>
References: <51B764AC.8080005@oracle.com>
Message-ID: <51B7AE32.5040901@oracle.com>

I prefer to avoid use of deprecated 3-letter IDs of JDK 1.1. "PST" 
should be "America/Los_Angeles".

Masayoshi

On 6/12/2013 2:55 AM, Naoto Sato wrote:
> Hello,
>
> Please review an one-liner fix for the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015960
>
> The fix is simply to set the time zone in the formatter to "PST":
>
> http://cr.openjdk.java.net/~naoto/8015960/webrev.00/
>
> Naoto


From naoto.sato at oracle.com  Tue Jun 11 16:32:20 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 11 Jun 2013 16:32:20 -0700
Subject: <i18n dev> [8] Request for review: 8015960:
 java/util/Locale/LocaleProviders.java failing again on Windows
In-Reply-To: <51B7AE32.5040901@oracle.com>
References: <51B764AC.8080005@oracle.com> <51B7AE32.5040901@oracle.com>
Message-ID: <51B7B384.4030001@oracle.com>

Right. However, I've already pushed the changeset, so I will fix it next 
time I modify the test case.

Naoto

On 6/11/13 4:09 PM, Masayoshi Okutsu wrote:
> I prefer to avoid use of deprecated 3-letter IDs of JDK 1.1. "PST"
> should be "America/Los_Angeles".
>
> Masayoshi
>
> On 6/12/2013 2:55 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review an one-liner fix for the following bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015960
>>
>> The fix is simply to set the time zone in the formatter to "PST":
>>
>> http://cr.openjdk.java.net/~naoto/8015960/webrev.00/
>>
>> Naoto
>


From yong.huang at oracle.com  Thu Jun 13 23:51:52 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Fri, 14 Jun 2013 14:51:52 +0800
Subject: <i18n dev> Review Request - 8013836 : getFirstDayOfWeek reports
 wrong day for pt-BR locale
Message-ID: <51BABD88.1050801@oracle.com>

Hello,

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

Webrev: 
http://java-g11n.us.oracle.com/j2se/ws/1.8.0/ws/yonhuang/8013836/webrev.00/

thanks,
Yong

From naoto.sato at oracle.com  Fri Jun 14 12:10:06 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 14 Jun 2013 12:10:06 -0700
Subject: <i18n dev> Review Request - 8013836 : getFirstDayOfWeek reports
 wrong day for pt-BR locale
In-Reply-To: <51BABD88.1050801@oracle.com>
References: <51BABD88.1050801@oracle.com>
Message-ID: <51BB6A8E.9020404@oracle.com>

Hi Yong,

Changing the "pt" resource file would affect all the countries with 
Portuguese language, not only Brazil. It could result in the correct 
behavior for some countries, but could regress for others (haven't 
checked each of them). I think we need to create 
CalendarData_pt_BR.properties to explicitly change the first day for Brazil.

Naoto

On 6/13/13 11:51 PM, Yong Huang wrote:
> Hello,
>
> This is the review request for
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013836
>
> Webrev:
> http://java-g11n.us.oracle.com/j2se/ws/1.8.0/ws/yonhuang/8013836/webrev.00/
>
> thanks,
> Yong


From yong.huang at oracle.com  Sun Jun 16 20:20:07 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Mon, 17 Jun 2013 11:20:07 +0800
Subject: <i18n dev> Review Request - 8013836 : getFirstDayOfWeek reports
 wrong day for pt-BR locale
In-Reply-To: <51BB6A8E.9020404@oracle.com>
References: <51BABD88.1050801@oracle.com> <51BB6A8E.9020404@oracle.com>
Message-ID: <51BE8067.40907@oracle.com>

Hi Naoto,

Thanks for the review.

The revised webrev is at 
http://cr.openjdk.java.net/~yhuang/8013836/webrev.01/

thanks,
Yong

On 2013/6/15 3:10, Naoto Sato wrote:
> Hi Yong,
>
> Changing the "pt" resource file would affect all the countries with 
> Portuguese language, not only Brazil. It could result in the correct 
> behavior for some countries, but could regress for others (haven't 
> checked each of them). I think we need to create 
> CalendarData_pt_BR.properties to explicitly change the first day for 
> Brazil.
>
> Naoto
>
> On 6/13/13 11:51 PM, Yong Huang wrote:
>> Hello,
>>
>> This is the review request for
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013836
>>
>> Webrev:
>> http://java-g11n.us.oracle.com/j2se/ws/1.8.0/ws/yonhuang/8013836/webrev.00/ 
>>
>>
>> thanks,
>> Yong
>


From naoto.sato at oracle.com  Mon Jun 17 10:37:45 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 17 Jun 2013 10:37:45 -0700
Subject: <i18n dev> Review Request - 8013836 : getFirstDayOfWeek reports
 wrong day for pt-BR locale
In-Reply-To: <51BE8067.40907@oracle.com>
References: <51BABD88.1050801@oracle.com> <51BB6A8E.9020404@oracle.com>
	<51BE8067.40907@oracle.com>
Message-ID: <51BF4969.8020003@oracle.com>

IANAL, but I am not sure whether the Taligent/IBM copyright notice is 
needed, since you've created it. Can you please check it with the legal?

Naoto

On 6/16/13 8:20 PM, Yong Huang wrote:
> Hi Naoto,
>
> Thanks for the review.
>
> The revised webrev is at
> http://cr.openjdk.java.net/~yhuang/8013836/webrev.01/
>
> thanks,
> Yong
>
> On 2013/6/15 3:10, Naoto Sato wrote:
>> Hi Yong,
>>
>> Changing the "pt" resource file would affect all the countries with
>> Portuguese language, not only Brazil. It could result in the correct
>> behavior for some countries, but could regress for others (haven't
>> checked each of them). I think we need to create
>> CalendarData_pt_BR.properties to explicitly change the first day for
>> Brazil.
>>
>> Naoto
>>
>> On 6/13/13 11:51 PM, Yong Huang wrote:
>>> Hello,
>>>
>>> This is the review request for
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013836
>>>
>>> Webrev:
>>> http://java-g11n.us.oracle.com/j2se/ws/1.8.0/ws/yonhuang/8013836/webrev.00/
>>>
>>>
>>> thanks,
>>> Yong
>>
>


From yong.huang at oracle.com  Mon Jun 17 19:42:22 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Tue, 18 Jun 2013 10:42:22 +0800
Subject: <i18n dev> Review Request - 8013836 : getFirstDayOfWeek reports
 wrong day for pt-BR locale
In-Reply-To: <51BF4969.8020003@oracle.com>
References: <51BABD88.1050801@oracle.com> <51BB6A8E.9020404@oracle.com>
	<51BE8067.40907@oracle.com> <51BF4969.8020003@oracle.com>
Message-ID: <51BFC90E.3000805@oracle.com>

Hi Michael,

Since you are more familiar with the copyright in resource files, I'd 
like to get your help first. :-)

I copy CalendarData_pt.properties to CalendarData_pt_BR.properties and 
make some modification on it. Do I still need to keep Taligent/IBM 
copyright in the new file? If you are also not sure, do you know how to 
get help from legal about this?

thanks,
Yong

On 2013/6/18 1:37, Naoto Sato wrote:
> IANAL, but I am not sure whether the Taligent/IBM copyright notice is 
> needed, since you've created it. Can you please check it with the legal?
>
> Naoto
>
> On 6/16/13 8:20 PM, Yong Huang wrote:
>> Hi Naoto,
>>
>> Thanks for the review.
>>
>> The revised webrev is at
>> http://cr.openjdk.java.net/~yhuang/8013836/webrev.01/
>>
>> thanks,
>> Yong
>>
>> On 2013/6/15 3:10, Naoto Sato wrote:
>>> Hi Yong,
>>>
>>> Changing the "pt" resource file would affect all the countries with
>>> Portuguese language, not only Brazil. It could result in the correct
>>> behavior for some countries, but could regress for others (haven't
>>> checked each of them). I think we need to create
>>> CalendarData_pt_BR.properties to explicitly change the first day for
>>> Brazil.
>>>
>>> Naoto
>>>
>>> On 6/13/13 11:51 PM, Yong Huang wrote:
>>>> Hello,
>>>>
>>>> This is the review request for
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013836
>>>>
>>>> Webrev:
>>>> http://java-g11n.us.oracle.com/j2se/ws/1.8.0/ws/yonhuang/8013836/webrev.00/ 
>>>>
>>>>
>>>>
>>>> thanks,
>>>> Yong
>>>
>>
>


From michael.fang at oracle.com  Mon Jun 17 22:42:03 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 17 Jun 2013 22:42:03 -0700
Subject: <i18n dev> [8]Request for review: 8015657: jdk8 l10n resource file
 translation update 3
Message-ID: <51BFF32B.9030200@oracle.com>

Hello,

Please help to review the changes for the following CR:
http://bugs.sun.com/view_bug.do?bug_id=8015657

A list of English resource files are sent to translation group for 
translation update periodically that's why these l10n resource files 
have been updated.

You do not need to review the translation content at this time. We just 
need to make sure they do not break the build (which has been ensured 
with full test builds). Follow up i18n/l10n testing will be performed in 
promotion builds and i18n/l10n bugs will be reported and addressed.

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8015657/

thanks,

-michael

From michael.fang at oracle.com  Mon Jun 17 22:56:35 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 17 Jun 2013 22:56:35 -0700
Subject: <i18n dev> [8] Request for review: 8016824: jdk8 l10n resource file
 translation update 3 - jaxp
In-Reply-To: <51BFF50D.2040308@oracle.com>
References: <51BFF50D.2040308@oracle.com>
Message-ID: <51BFF693.5050203@oracle.com>

Hi Joe,

Please help to review the changes for the following CR:
http://bugs.sun.com/view_bug.do?bug_id=8016824

A list of English resource files are sent to translation group for 
translation update periodically that's why these l10n resource files 
have been updated.

You do not need to review the translation content at this time. We just 
need to make sure they do not break the build (which has been ensured 
with full test builds). Follow up i18n/l10n testing will be performed in 
promotion builds and i18n/l10n bugs will be reported and addressed.

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8016824/

thanks,

-michael

From yong.huang at oracle.com  Mon Jun 17 22:58:48 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Tue, 18 Jun 2013 13:58:48 +0800
Subject: <i18n dev> [8]Request for review: 8015657: jdk8 l10n resource
 file translation update 3
In-Reply-To: <51BFF32B.9030200@oracle.com>
References: <51BFF32B.9030200@oracle.com>
Message-ID: <51BFF718.7050208@oracle.com>

It looks good to me based on our internal testing, 
http://aseng-wiki.us.oracle.com/asengwiki/display/i18n/JDK+8+Message+Drop+30+PIT1+Test

Some bugs are filed, but it should be OK to integrate current l10n change.

thanks,
Yong

On 2013/6/18 13:42, Michael Fang wrote:
> Hello,
>
> Please help to review the changes for the following CR:
> http://bugs.sun.com/view_bug.do?bug_id=8015657
>
> A list of English resource files are sent to translation group for 
> translation update periodically that's why these l10n resource files 
> have been updated.
>
> You do not need to review the translation content at this time. We 
> just need to make sure they do not break the build (which has been 
> ensured with full test builds). Follow up i18n/l10n testing will be 
> performed in promotion builds and i18n/l10n bugs will be reported and 
> addressed.
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8015657/
>
> thanks,
>
> -michael


From michael.fang at oracle.com  Mon Jun 17 23:02:23 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 17 Jun 2013 23:02:23 -0700
Subject: <i18n dev> [8] Request for review: 8011870: i18n translations for
	JDK-8009636
Message-ID: <51BFF7EF.4090302@oracle.com>

Hi Joe and all,

Please help to review the changes for the following CR:
http://bugs.sun.com/view_bug.do?bug_id=8011870

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8011870/
It's part of webrev for 8015657: jdk8 l10n resource file translation 
update 3

Please only look at the webrev for the following 2 files:
src/share/classes/sun/security/tools/jarsigner/Resources_ja.java*
*src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java

thanks,

-michael

From michael.fang at oracle.com  Mon Jun 17 23:02:42 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 17 Jun 2013 23:02:42 -0700
Subject: <i18n dev> [8]Request for review: 8015657: jdk8 l10n resource
 file translation update 3
In-Reply-To: <51BFF718.7050208@oracle.com>
References: <51BFF32B.9030200@oracle.com> <51BFF718.7050208@oracle.com>
Message-ID: <51BFF802.7030809@oracle.com>

Thank you Yong for the review!

-michael

On 06/17/13 22:58, Yong Huang wrote:
> It looks good to me based on our internal testing, 
> http://aseng-wiki.us.oracle.com/asengwiki/display/i18n/JDK+8+Message+Drop+30+PIT1+Test
>
> Some bugs are filed, but it should be OK to integrate current l10n 
> change.
>
> thanks,
> Yong
>
> On 2013/6/18 13:42, Michael Fang wrote:
>> Hello,
>>
>> Please help to review the changes for the following CR:
>> http://bugs.sun.com/view_bug.do?bug_id=8015657
>>
>> A list of English resource files are sent to translation group for 
>> translation update periodically that's why these l10n resource files 
>> have been updated.
>>
>> You do not need to review the translation content at this time. We 
>> just need to make sure they do not break the build (which has been 
>> ensured with full test builds). Follow up i18n/l10n testing will be 
>> performed in promotion builds and i18n/l10n bugs will be reported and 
>> addressed.
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8015657/
>>
>> thanks,
>>
>> -michael
>

From huizhe.wang at oracle.com  Mon Jun 17 23:41:00 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 17 Jun 2013 23:41:00 -0700
Subject: <i18n dev> [8] Request for review: 8016824: jdk8 l10n resource
 file translation update 3 - jaxp
In-Reply-To: <51BFF693.5050203@oracle.com>
References: <51BFF50D.2040308@oracle.com> <51BFF693.5050203@oracle.com>
Message-ID: <51C000FC.2050103@oracle.com>

Hi Michael,

Thanks for translating the new messages.

I noticed that except XMLMessages, XMLSchemaMessages, and new language 
resources for XPath, others are mostly removing the Oracle copyright 
header.  Should the header be removed?  Other than the original English 
source file, others were added by Oracle.

-Joe

On 6/17/2013 10:56 PM, Michael Fang wrote:
> Hi Joe,
>
> Please help to review the changes for the following CR:
> http://bugs.sun.com/view_bug.do?bug_id=8016824
>
> A list of English resource files are sent to translation group for 
> translation update periodically that's why these l10n resource files 
> have been updated.
>
> You do not need to review the translation content at this time. We 
> just need to make sure they do not break the build (which has been 
> ensured with full test builds). Follow up i18n/l10n testing will be 
> performed in promotion builds and i18n/l10n bugs will be reported and 
> addressed.
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8016824/
>
> thanks,
>
> -michael


From huizhe.wang at oracle.com  Mon Jun 17 23:44:05 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 17 Jun 2013 23:44:05 -0700
Subject: <i18n dev> [8] Request for review: 8011870: i18n translations
	for JDK-8009636
In-Reply-To: <51BFF7EF.4090302@oracle.com>
References: <51BFF7EF.4090302@oracle.com>
Message-ID: <51C001B5.7090303@oracle.com>

Hi Michael,

I think you meant to ask Max to review this one.

-Joe

On 6/17/2013 11:02 PM, Michael Fang wrote:
> Hi Joe and all,
>
> Please help to review the changes for the following CR:
> http://bugs.sun.com/view_bug.do?bug_id=8011870
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8011870/
> It's part of webrev for 8015657: jdk8 l10n resource file translation 
> update 3
>
> Please only look at the webrev for the following 2 files:
> src/share/classes/sun/security/tools/jarsigner/Resources_ja.java*
> *src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
>
> thanks,
>
> -michael 


From michael.fang at oracle.com  Tue Jun 18 09:45:25 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 18 Jun 2013 09:45:25 -0700
Subject: <i18n dev> [8] Request for review: 8011870: i18n translations
	for JDK-8009636
In-Reply-To: <2E214EC5-9F71-44F7-A988-AD6646F7E329@oracle.com>
References: <51BFF7EF.4090302@oracle.com> <51C001B5.7090303@oracle.com>
	<2E214EC5-9F71-44F7-A988-AD6646F7E329@oracle.com>
Message-ID: <51C08EA5.70503@oracle.com>

Thank you Max!

-michael

On 06/18/13 02:25, Wang Weijun wrote:
>
>
> ? Jun 18, 2013?2:44 PM?huizhe wang <huizhe.wang at oracle.com 
> <mailto:huizhe.wang at oracle.com>> ???
>
>> Hi Michael,
>>
>> I think you meant to ask Max to review this one.
>
> I guess so.
>
> Michael, I'm on vacation this week. Will look at it next week.
>
> Thanks
> Max
>
>>
>> -Joe
>>
>> On 6/17/2013 11:02 PM, Michael Fang wrote:
>>> Hi Joe and all,
>>>
>>> Please help to review the changes for the following CR:
>>> http://bugs.sun.com/view_bug.do?bug_id=8011870
>>>
>>> The webrev is available here:
>>> http://cr.openjdk.java.net/~mfang/8011870/
>>> It's part of webrev for 8015657: jdk8 l10n resource file translation 
>>> update 3
>>>
>>> Please only look at the webrev for the following 2 files:
>>> src/share/classes/sun/security/tools/jarsigner/Resources_ja.java*
>>> *src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
>>>
>>> thanks,
>>>
>>> -michael 
>>

From michael.fang at oracle.com  Tue Jun 18 09:50:40 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 18 Jun 2013 09:50:40 -0700
Subject: <i18n dev> [8] Request for review: 8016824: jdk8 l10n resource
 file translation update 3 - jaxp
In-Reply-To: <51C000FC.2050103@oracle.com>
References: <51BFF50D.2040308@oracle.com> <51BFF693.5050203@oracle.com>
	<51C000FC.2050103@oracle.com>
Message-ID: <51C08FE0.9060206@oracle.com>

Hi Joe,

The translation team uses the English file as template and updated the 
l10n files to match. So, in these cases, the corresponding English 
resource files do not have these copyright headers, the l10n files were 
updated accordingly. Is this a problem?

thanks,

-michael

On 06/17/13 23:41, huizhe wang wrote:
> Hi Michael,
>
> Thanks for translating the new messages.
>
> I noticed that except XMLMessages, XMLSchemaMessages, and new language 
> resources for XPath, others are mostly removing the Oracle copyright 
> header.  Should the header be removed?  Other than the original 
> English source file, others were added by Oracle.
>
> -Joe
>
> On 6/17/2013 10:56 PM, Michael Fang wrote:
>> Hi Joe,
>>
>> Please help to review the changes for the following CR:
>> http://bugs.sun.com/view_bug.do?bug_id=8016824
>>
>> A list of English resource files are sent to translation group for 
>> translation update periodically that's why these l10n resource files 
>> have been updated.
>>
>> You do not need to review the translation content at this time. We 
>> just need to make sure they do not break the build (which has been 
>> ensured with full test builds). Follow up i18n/l10n testing will be 
>> performed in promotion builds and i18n/l10n bugs will be reported and 
>> addressed.
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8016824/
>>
>> thanks,
>>
>> -michael
>

From huizhe.wang at oracle.com  Tue Jun 18 10:07:48 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 18 Jun 2013 10:07:48 -0700
Subject: <i18n dev> [8] Request for review: 8016824: jdk8 l10n resource
 file translation update 3 - jaxp
In-Reply-To: <51C08FE0.9060206@oracle.com>
References: <51BFF50D.2040308@oracle.com> <51BFF693.5050203@oracle.com>
	<51C000FC.2050103@oracle.com> <51C08FE0.9060206@oracle.com>
Message-ID: <51C093E4.1070503@oracle.com>

Hi Michael,

The English came from Apache, a header was added there. So we'll need to 
add the Apache header when we update (which we plan to do in the next 
project).

The other language files were added by Oracle, reflecting the 
internationalization effort by Oracle. I think those Oracle copyright 
headers shouldn't have been removed.

Thanks,
Joe

On 6/18/2013 9:50 AM, Michael Fang wrote:
> Hi Joe,
>
> The translation team uses the English file as template and updated the 
> l10n files to match. So, in these cases, the corresponding English 
> resource files do not have these copyright headers, the l10n files 
> were updated accordingly. Is this a problem?
>
> thanks,
>
> -michael
>
> On 06/17/13 23:41, huizhe wang wrote:
>> Hi Michael,
>>
>> Thanks for translating the new messages.
>>
>> I noticed that except XMLMessages, XMLSchemaMessages, and new 
>> language resources for XPath, others are mostly removing the Oracle 
>> copyright header.  Should the header be removed?  Other than the 
>> original English source file, others were added by Oracle.
>>
>> -Joe
>>
>> On 6/17/2013 10:56 PM, Michael Fang wrote:
>>> Hi Joe,
>>>
>>> Please help to review the changes for the following CR:
>>> http://bugs.sun.com/view_bug.do?bug_id=8016824
>>>
>>> A list of English resource files are sent to translation group for 
>>> translation update periodically that's why these l10n resource files 
>>> have been updated.
>>>
>>> You do not need to review the translation content at this time. We 
>>> just need to make sure they do not break the build (which has been 
>>> ensured with full test builds). Follow up i18n/l10n testing will be 
>>> performed in promotion builds and i18n/l10n bugs will be reported 
>>> and addressed.
>>>
>>> The webrev is available here:
>>> http://cr.openjdk.java.net/~mfang/8016824/
>>>
>>> thanks,
>>>
>>> -michael
>>


From michael.fang at oracle.com  Tue Jun 18 10:13:38 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 18 Jun 2013 10:13:38 -0700
Subject: <i18n dev> [8] Request for review: 8016824: jdk8 l10n resource
 file translation update 3 - jaxp
In-Reply-To: <51C093E4.1070503@oracle.com>
References: <51BFF50D.2040308@oracle.com> <51BFF693.5050203@oracle.com>
	<51C000FC.2050103@oracle.com> <51C08FE0.9060206@oracle.com>
	<51C093E4.1070503@oracle.com>
Message-ID: <51C09542.5050109@oracle.com>

Hi Joe,

I see. This is not part of automated translation process. Let me see 
what I can do.

thanks,

-michael

On 06/18/13 10:07, huizhe wang wrote:
> Hi Michael,
>
> The English came from Apache, a header was added there. So we'll need 
> to add the Apache header when we update (which we plan to do in the 
> next project).
>
> The other language files were added by Oracle, reflecting the 
> internationalization effort by Oracle. I think those Oracle copyright 
> headers shouldn't have been removed.
>
> Thanks,
> Joe
>
> On 6/18/2013 9:50 AM, Michael Fang wrote:
>> Hi Joe,
>>
>> The translation team uses the English file as template and updated 
>> the l10n files to match. So, in these cases, the corresponding 
>> English resource files do not have these copyright headers, the l10n 
>> files were updated accordingly. Is this a problem?
>>
>> thanks,
>>
>> -michael
>>
>> On 06/17/13 23:41, huizhe wang wrote:
>>> Hi Michael,
>>>
>>> Thanks for translating the new messages.
>>>
>>> I noticed that except XMLMessages, XMLSchemaMessages, and new 
>>> language resources for XPath, others are mostly removing the Oracle 
>>> copyright header.  Should the header be removed?  Other than the 
>>> original English source file, others were added by Oracle.
>>>
>>> -Joe
>>>
>>> On 6/17/2013 10:56 PM, Michael Fang wrote:
>>>> Hi Joe,
>>>>
>>>> Please help to review the changes for the following CR:
>>>> http://bugs.sun.com/view_bug.do?bug_id=8016824
>>>>
>>>> A list of English resource files are sent to translation group for 
>>>> translation update periodically that's why these l10n resource 
>>>> files have been updated.
>>>>
>>>> You do not need to review the translation content at this time. We 
>>>> just need to make sure they do not break the build (which has been 
>>>> ensured with full test builds). Follow up i18n/l10n testing will be 
>>>> performed in promotion builds and i18n/l10n bugs will be reported 
>>>> and addressed.
>>>>
>>>> The webrev is available here:
>>>> http://cr.openjdk.java.net/~mfang/8016824/
>>>>
>>>> thanks,
>>>>
>>>> -michael
>>>
>

From weijun.wang at oracle.com  Tue Jun 18 02:25:03 2013
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 18 Jun 2013 17:25:03 +0800
Subject: <i18n dev> [8] Request for review: 8011870: i18n translations
	for JDK-8009636
In-Reply-To: <51C001B5.7090303@oracle.com>
References: <51BFF7EF.4090302@oracle.com> <51C001B5.7090303@oracle.com>
Message-ID: <2E214EC5-9F71-44F7-A988-AD6646F7E329@oracle.com>



?? Jun 18, 2013??2:44 PM??huizhe wang <huizhe.wang at oracle.com> ??????

> Hi Michael,
> 
> I think you meant to ask Max to review this one.

I guess so.

Michael, I'm on vacation this week. Will look at it next week.

Thanks
Max

> 
> -Joe
> 
> On 6/17/2013 11:02 PM, Michael Fang wrote:
>> Hi Joe and all, 
>> 
>> Please help to review the changes for the following CR: 
>> http://bugs.sun.com/view_bug.do?bug_id=8011870 
>> 
>> The webrev is available here: 
>> http://cr.openjdk.java.net/~mfang/8011870/
>> It's part of webrev for 8015657: jdk8 l10n resource file translation update 3
>> 
>> Please only look at the webrev for the following 2 files:
>> src/share/classes/sun/security/tools/jarsigner/Resources_ja.java
>> src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
>> 
>> thanks, 
>> 
>> -michael
> 

From naoto.sato at oracle.com  Tue Jun 18 11:52:54 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Jun 2013 11:52:54 -0700
Subject: <i18n dev> [8]Request for review: 8015657: jdk8 l10n resource
 file translation update 3
In-Reply-To: <51BFF32B.9030200@oracle.com>
References: <51BFF32B.9030200@oracle.com>
Message-ID: <51C0AC86.8050305@oracle.com>

Looks good to me.

Naoto

On 6/17/13 10:42 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes for the following CR:
> http://bugs.sun.com/view_bug.do?bug_id=8015657
>
> A list of English resource files are sent to translation group for
> translation update periodically that's why these l10n resource files
> have been updated.
>
> You do not need to review the translation content at this time. We just
> need to make sure they do not break the build (which has been ensured
> with full test builds). Follow up i18n/l10n testing will be performed in
> promotion builds and i18n/l10n bugs will be reported and addressed.
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8015657/
>
> thanks,
>
> -michael


From michael.fang at oracle.com  Tue Jun 18 11:51:29 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 18 Jun 2013 11:51:29 -0700
Subject: <i18n dev> [8]Request for review: 8015657: jdk8 l10n resource
 file translation update 3
In-Reply-To: <51C0AC86.8050305@oracle.com>
References: <51BFF32B.9030200@oracle.com> <51C0AC86.8050305@oracle.com>
Message-ID: <51C0AC31.5090003@oracle.com>

Thanks Naoto for the review.

-michael

On 06/18/13 11:52, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 6/17/13 10:42 PM, Michael Fang wrote:
>> Hello,
>>
>> Please help to review the changes for the following CR:
>> http://bugs.sun.com/view_bug.do?bug_id=8015657
>>
>> A list of English resource files are sent to translation group for
>> translation update periodically that's why these l10n resource files
>> have been updated.
>>
>> You do not need to review the translation content at this time. We just
>> need to make sure they do not break the build (which has been ensured
>> with full test builds). Follow up i18n/l10n testing will be performed in
>> promotion builds and i18n/l10n bugs will be reported and addressed.
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8015657/
>>
>> thanks,
>>
>> -michael
>

From naoto.sato at oracle.com  Tue Jun 18 13:35:00 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Jun 2013 13:35:00 -0700
Subject: <i18n dev> [8] Request for Review: 6863624 :
 java/util/Currency/PropertiesTest.sh writable check is incorrect
Message-ID: <51C0C474.1060004@oracle.com>

Hello,

Please review this test case fix:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6863624
http://cr.openjdk.java.net/~naoto/6863624/webrev.00/

Basically it enforces the check for non-writable JDKs, with a workaround 
for Cygwin's inconsistent behavior for `test` command. Changes for 
LocaleProviders are irrelevant for this fix, just the left over from 
previous fix for 8015960.

Naoto

From michael.fang at oracle.com  Tue Jun 18 22:41:42 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 18 Jun 2013 22:41:42 -0700
Subject: <i18n dev> [8] Request for review: 8016824: jdk8 l10n resource
 file translation update 3 - jaxp
In-Reply-To: <51C09542.5050109@oracle.com>
References: <51BFF50D.2040308@oracle.com> <51BFF693.5050203@oracle.com>
	<51C000FC.2050103@oracle.com> <51C08FE0.9060206@oracle.com>
	<51C093E4.1070503@oracle.com> <51C09542.5050109@oracle.com>
Message-ID: <51C14496.1020608@oracle.com>

Hi Joe,

I have updated the copyright.

The webrev has been updated at: 
http://cr.openjdk.java.net/~mfang/8016824/webrev.jaxp.01/

thanks,

-michael

On 06/18/13 10:13, Michael Fang wrote:
> Hi Joe,
>
> I see. This is not part of automated translation process. Let me see 
> what I can do.
>
> thanks,
>
> -michael
>
> On 06/18/13 10:07, huizhe wang wrote:
>> Hi Michael,
>>
>> The English came from Apache, a header was added there. So we'll need 
>> to add the Apache header when we update (which we plan to do in the 
>> next project).
>>
>> The other language files were added by Oracle, reflecting the 
>> internationalization effort by Oracle. I think those Oracle copyright 
>> headers shouldn't have been removed.
>>
>> Thanks,
>> Joe
>>
>> On 6/18/2013 9:50 AM, Michael Fang wrote:
>>> Hi Joe,
>>>
>>> The translation team uses the English file as template and updated 
>>> the l10n files to match. So, in these cases, the corresponding 
>>> English resource files do not have these copyright headers, the l10n 
>>> files were updated accordingly. Is this a problem?
>>>
>>> thanks,
>>>
>>> -michael
>>>
>>> On 06/17/13 23:41, huizhe wang wrote:
>>>> Hi Michael,
>>>>
>>>> Thanks for translating the new messages.
>>>>
>>>> I noticed that except XMLMessages, XMLSchemaMessages, and new 
>>>> language resources for XPath, others are mostly removing the Oracle 
>>>> copyright header.  Should the header be removed?  Other than the 
>>>> original English source file, others were added by Oracle.
>>>>
>>>> -Joe
>>>>
>>>> On 6/17/2013 10:56 PM, Michael Fang wrote:
>>>>> Hi Joe,
>>>>>
>>>>> Please help to review the changes for the following CR:
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016824
>>>>>
>>>>> A list of English resource files are sent to translation group for 
>>>>> translation update periodically that's why these l10n resource 
>>>>> files have been updated.
>>>>>
>>>>> You do not need to review the translation content at this time. We 
>>>>> just need to make sure they do not break the build (which has been 
>>>>> ensured with full test builds). Follow up i18n/l10n testing will 
>>>>> be performed in promotion builds and i18n/l10n bugs will be 
>>>>> reported and addressed.
>>>>>
>>>>> The webrev is available here:
>>>>> http://cr.openjdk.java.net/~mfang/8016824/
>>>>>
>>>>> thanks,
>>>>>
>>>>> -michael
>>>>
>>

From huizhe.wang at oracle.com  Tue Jun 18 22:44:34 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 18 Jun 2013 22:44:34 -0700
Subject: <i18n dev> [8] Request for review: 8016824: jdk8 l10n resource
 file translation update 3 - jaxp
In-Reply-To: <51C14496.1020608@oracle.com>
References: <51BFF50D.2040308@oracle.com> <51BFF693.5050203@oracle.com>
	<51C000FC.2050103@oracle.com> <51C08FE0.9060206@oracle.com>
	<51C093E4.1070503@oracle.com> <51C09542.5050109@oracle.com>
	<51C14496.1020608@oracle.com>
Message-ID: <51C14542.7020000@oracle.com>

Looks great!  Thanks for taking the time to fix the legal notice.

-Joe

On 6/18/2013 10:41 PM, Michael Fang wrote:
> Hi Joe,
>
> I have updated the copyright.
>
> The webrev has been updated at: 
> http://cr.openjdk.java.net/~mfang/8016824/webrev.jaxp.01/
>
> thanks,
>
> -michael
>
> On 06/18/13 10:13, Michael Fang wrote:
>> Hi Joe,
>>
>> I see. This is not part of automated translation process. Let me see 
>> what I can do.
>>
>> thanks,
>>
>> -michael
>>
>> On 06/18/13 10:07, huizhe wang wrote:
>>> Hi Michael,
>>>
>>> The English came from Apache, a header was added there. So we'll 
>>> need to add the Apache header when we update (which we plan to do in 
>>> the next project).
>>>
>>> The other language files were added by Oracle, reflecting the 
>>> internationalization effort by Oracle. I think those Oracle 
>>> copyright headers shouldn't have been removed.
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 6/18/2013 9:50 AM, Michael Fang wrote:
>>>> Hi Joe,
>>>>
>>>> The translation team uses the English file as template and updated 
>>>> the l10n files to match. So, in these cases, the corresponding 
>>>> English resource files do not have these copyright headers, the 
>>>> l10n files were updated accordingly. Is this a problem?
>>>>
>>>> thanks,
>>>>
>>>> -michael
>>>>
>>>> On 06/17/13 23:41, huizhe wang wrote:
>>>>> Hi Michael,
>>>>>
>>>>> Thanks for translating the new messages.
>>>>>
>>>>> I noticed that except XMLMessages, XMLSchemaMessages, and new 
>>>>> language resources for XPath, others are mostly removing the 
>>>>> Oracle copyright header.  Should the header be removed?  Other 
>>>>> than the original English source file, others were added by Oracle.
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 6/17/2013 10:56 PM, Michael Fang wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> Please help to review the changes for the following CR:
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016824
>>>>>>
>>>>>> A list of English resource files are sent to translation group 
>>>>>> for translation update periodically that's why these l10n 
>>>>>> resource files have been updated.
>>>>>>
>>>>>> You do not need to review the translation content at this time. 
>>>>>> We just need to make sure they do not break the build (which has 
>>>>>> been ensured with full test builds). Follow up i18n/l10n testing 
>>>>>> will be performed in promotion builds and i18n/l10n bugs will be 
>>>>>> reported and addressed.
>>>>>>
>>>>>> The webrev is available here:
>>>>>> http://cr.openjdk.java.net/~mfang/8016824/
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> -michael
>>>>>
>>>


From michael.fang at oracle.com  Tue Jun 18 22:49:29 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 18 Jun 2013 22:49:29 -0700
Subject: <i18n dev> [8] Request for review: 8016824: jdk8 l10n resource
 file translation update 3 - jaxp
In-Reply-To: <51C14542.7020000@oracle.com>
References: <51BFF50D.2040308@oracle.com> <51BFF693.5050203@oracle.com>
	<51C000FC.2050103@oracle.com> <51C08FE0.9060206@oracle.com>
	<51C093E4.1070503@oracle.com> <51C09542.5050109@oracle.com>
	<51C14496.1020608@oracle.com> <51C14542.7020000@oracle.com>
Message-ID: <51C14669.30904@oracle.com>

Thanks Joe.

-michael

On 06/18/13 22:44, huizhe wang wrote:
> Looks great!  Thanks for taking the time to fix the legal notice.
>
> -Joe
>
> On 6/18/2013 10:41 PM, Michael Fang wrote:
>> Hi Joe,
>>
>> I have updated the copyright.
>>
>> The webrev has been updated at: 
>> http://cr.openjdk.java.net/~mfang/8016824/webrev.jaxp.01/
>>
>> thanks,
>>
>> -michael
>>
>> On 06/18/13 10:13, Michael Fang wrote:
>>> Hi Joe,
>>>
>>> I see. This is not part of automated translation process. Let me see 
>>> what I can do.
>>>
>>> thanks,
>>>
>>> -michael
>>>
>>> On 06/18/13 10:07, huizhe wang wrote:
>>>> Hi Michael,
>>>>
>>>> The English came from Apache, a header was added there. So we'll 
>>>> need to add the Apache header when we update (which we plan to do 
>>>> in the next project).
>>>>
>>>> The other language files were added by Oracle, reflecting the 
>>>> internationalization effort by Oracle. I think those Oracle 
>>>> copyright headers shouldn't have been removed.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>> On 6/18/2013 9:50 AM, Michael Fang wrote:
>>>>> Hi Joe,
>>>>>
>>>>> The translation team uses the English file as template and updated 
>>>>> the l10n files to match. So, in these cases, the corresponding 
>>>>> English resource files do not have these copyright headers, the 
>>>>> l10n files were updated accordingly. Is this a problem?
>>>>>
>>>>> thanks,
>>>>>
>>>>> -michael
>>>>>
>>>>> On 06/17/13 23:41, huizhe wang wrote:
>>>>>> Hi Michael,
>>>>>>
>>>>>> Thanks for translating the new messages.
>>>>>>
>>>>>> I noticed that except XMLMessages, XMLSchemaMessages, and new 
>>>>>> language resources for XPath, others are mostly removing the 
>>>>>> Oracle copyright header.  Should the header be removed?  Other 
>>>>>> than the original English source file, others were added by Oracle.
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>> On 6/17/2013 10:56 PM, Michael Fang wrote:
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> Please help to review the changes for the following CR:
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016824
>>>>>>>
>>>>>>> A list of English resource files are sent to translation group 
>>>>>>> for translation update periodically that's why these l10n 
>>>>>>> resource files have been updated.
>>>>>>>
>>>>>>> You do not need to review the translation content at this time. 
>>>>>>> We just need to make sure they do not break the build (which has 
>>>>>>> been ensured with full test builds). Follow up i18n/l10n testing 
>>>>>>> will be performed in promotion builds and i18n/l10n bugs will be 
>>>>>>> reported and addressed.
>>>>>>>
>>>>>>> The webrev is available here:
>>>>>>> http://cr.openjdk.java.net/~mfang/8016824/
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> -michael
>>>>>>
>>>>
>

From yong.huang at oracle.com  Tue Jun 18 23:39:02 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Wed, 19 Jun 2013 14:39:02 +0800
Subject: <i18n dev> Review Request - 6964022:
 Java.util.Currency.getSymbol(Locale) returns wrong value when locale is not
 US
Message-ID: <51C15206.6050905@oracle.com>

Hello,

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

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

thanks,
Yong

From jeff.dinkins at oracle.com  Wed Jun 19 10:46:36 2013
From: jeff.dinkins at oracle.com (Jeff Dinkins)
Date: Wed, 19 Jun 2013 10:46:36 -0700
Subject: <i18n dev> Review Request - 8013836 : getFirstDayOfWeek reports
	wrong day for pt-BR locale
In-Reply-To: <51BFC90E.3000805@oracle.com>
References: <51BABD88.1050801@oracle.com> <51BB6A8E.9020404@oracle.com>
	<51BE8067.40907@oracle.com> <51BF4969.8020003@oracle.com>
	<51BFC90E.3000805@oracle.com>
Message-ID: <0F637BD9-8FDC-4442-AA0F-ABE4FFEDC5FE@oracle.com>


I'm pretty sure we generally don't remove the original copyright.


On Jun 17, 2013, at 7:42 PM, Yong Huang <yong.huang at oracle.com> wrote:

> Hi Michael,
> 
> Since you are more familiar with the copyright in resource files, I'd like to get your help first. :-)
> 
> I copy CalendarData_pt.properties to CalendarData_pt_BR.properties and make some modification on it. Do I still need to keep Taligent/IBM copyright in the new file? If you are also not sure, do you know how to get help from legal about this?
> 
> thanks,
> Yong
> 
> On 2013/6/18 1:37, Naoto Sato wrote:
>> IANAL, but I am not sure whether the Taligent/IBM copyright notice is needed, since you've created it. Can you please check it with the legal?
>> 
>> Naoto
>> 
>> On 6/16/13 8:20 PM, Yong Huang wrote:
>>> Hi Naoto,
>>> 
>>> Thanks for the review.
>>> 
>>> The revised webrev is at
>>> http://cr.openjdk.java.net/~yhuang/8013836/webrev.01/
>>> 
>>> thanks,
>>> Yong
>>> 
>>> On 2013/6/15 3:10, Naoto Sato wrote:
>>>> Hi Yong,
>>>> 
>>>> Changing the "pt" resource file would affect all the countries with
>>>> Portuguese language, not only Brazil. It could result in the correct
>>>> behavior for some countries, but could regress for others (haven't
>>>> checked each of them). I think we need to create
>>>> CalendarData_pt_BR.properties to explicitly change the first day for
>>>> Brazil.
>>>> 
>>>> Naoto
>>>> 
>>>> On 6/13/13 11:51 PM, Yong Huang wrote:
>>>>> Hello,
>>>>> 
>>>>> This is the review request for
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013836
>>>>> 
>>>>> Webrev:
>>>>> http://java-g11n.us.oracle.com/j2se/ws/1.8.0/ws/yonhuang/8013836/webrev.00/ 
>>>>> 
>>>>> 
>>>>> thanks,
>>>>> Yong
>>>> 
>>> 
>> 
> 


From naoto.sato at oracle.com  Wed Jun 19 10:44:17 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 19 Jun 2013 10:44:17 -0700
Subject: <i18n dev> Review Request - 6964022:
 Java.util.Currency.getSymbol(Locale) returns wrong value when locale is not
 US
In-Reply-To: <51C15206.6050905@oracle.com>
References: <51C15206.6050905@oracle.com>
Message-ID: <51C1EDF1.10305@oracle.com>

Hi Yong,

Looks like you are going to fix this not only for Australia, but also 
for other countries that use Dollar. That's good, but it's not limited 
to English countries ("en_*"), e.g., Taiwan. Would it be possible to fix 
for all the Dollar countries?

Naoto

On 6/18/13 11:39 PM, Yong Huang wrote:
> Hello,
>
> This is the review request for
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6964022
>
> Webrev: http://cr.openjdk.java.net/~yhuang/6964022/webrev.00/
>
> thanks,
> Yong


From yong.huang at oracle.com  Wed Jun 19 19:20:27 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Thu, 20 Jun 2013 10:20:27 +0800
Subject: <i18n dev> Review Request - 6964022:
 Java.util.Currency.getSymbol(Locale) returns wrong value when locale is not
 US
In-Reply-To: <51C1EDF1.10305@oracle.com>
References: <51C15206.6050905@oracle.com> <51C1EDF1.10305@oracle.com>
Message-ID: <51C266EB.2030005@oracle.com>

Hi Naoto,

OK, I will try to fix all the countries where Dollar symbol is in CLDR 
data file.

In some countries, for example, zh_Hant.xml, USD is <symbol 
draft="contributed">. Do I need to include these draft entries?

Can I use the latest CLDR data, like 23.1 to generate currency resource 
file that also may also include currency name, or is there any 
regulation about the version of CLDR data to be used?

thanks,
Yong

On 2013/6/20 1:44, Naoto Sato wrote:
> Hi Yong,
>
> Looks like you are going to fix this not only for Australia, but also 
> for other countries that use Dollar. That's good, but it's not limited 
> to English countries ("en_*"), e.g., Taiwan. Would it be possible to 
> fix for all the Dollar countries?
>
> Naoto
>
> On 6/18/13 11:39 PM, Yong Huang wrote:
>> Hello,
>>
>> This is the review request for
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6964022
>>
>> Webrev: http://cr.openjdk.java.net/~yhuang/6964022/webrev.00/
>>
>> thanks,
>> Yong
>


From naoto.sato at oracle.com  Fri Jun 21 10:30:32 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 21 Jun 2013 10:30:32 -0700
Subject: <i18n dev> [8] Request for Review: 6863624 :
 java/util/Currency/PropertiesTest.sh writable check is incorrect
In-Reply-To: <51C0C474.1060004@oracle.com>
References: <51C0C474.1060004@oracle.com>
Message-ID: <51C48DB8.7050100@oracle.com>

Still need a reviewer for this one.

Naoto

On 6/18/13 1:35 PM, Naoto Sato wrote:
> Hello,
>
> Please review this test case fix:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6863624
> http://cr.openjdk.java.net/~naoto/6863624/webrev.00/
>
> Basically it enforces the check for non-writable JDKs, with a workaround
> for Cygwin's inconsistent behavior for `test` command. Changes for
> LocaleProviders are irrelevant for this fix, just the left over from
> previous fix for 8015960.
>
> Naoto


From Alan.Bateman at oracle.com  Fri Jun 21 13:03:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Jun 2013 21:03:36 +0100
Subject: <i18n dev> [8] Request for Review: 6863624 :
 java/util/Currency/PropertiesTest.sh writable check is incorrect
In-Reply-To: <51C48DB8.7050100@oracle.com>
References: <51C0C474.1060004@oracle.com> <51C48DB8.7050100@oracle.com>
Message-ID: <51C4B198.5010801@oracle.com>

Naoto,

As the test might copy a currency.data into the JDK under test then it 
makes me wonder if this might cause interference for tests that are 
running concurrently (in other VMs). We might have to adding this 
directory to the exclusiveAccess.dir list (I don't know if there is an 
equivalent option that can be added to the @run tag).

Otherwise, I'm scratching my head a bit on why the changes are needed. 
Clearly it fixes the case where $TESTJAVA is writable but the lib or 
jre/lib directory is not. Or is the main fix the cygpath -u ${TESTJAVA} 
so that TESTJAVA has the right path for -w ? If so then the changes look 
fine to me.

-Alan.


On 21/06/2013 18:30, Naoto Sato wrote:
> Still need a reviewer for this one.
>
> Naoto
>
> On 6/18/13 1:35 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review this test case fix:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6863624
>> http://cr.openjdk.java.net/~naoto/6863624/webrev.00/
>>
>> Basically it enforces the check for non-writable JDKs, with a workaround
>> for Cygwin's inconsistent behavior for `test` command. Changes for
>> LocaleProviders are irrelevant for this fix, just the left over from
>> previous fix for 8015960.
>>
>> Naoto
>


From naoto.sato at oracle.com  Fri Jun 21 13:30:16 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 21 Jun 2013 13:30:16 -0700
Subject: <i18n dev> [8] Request for Review: 6863624 :
 java/util/Currency/PropertiesTest.sh writable check is incorrect
In-Reply-To: <51C4B198.5010801@oracle.com>
References: <51C0C474.1060004@oracle.com> <51C48DB8.7050100@oracle.com>
	<51C4B198.5010801@oracle.com>
Message-ID: <51C4B7D8.3070301@oracle.com>

On 6/21/13 1:03 PM, Alan Bateman wrote:
> Naoto,
>
> As the test might copy a currency.data into the JDK under test then it
> makes me wonder if this might cause interference for tests that are
> running concurrently (in other VMs). We might have to adding this
> directory to the exclusiveAccess.dir list (I don't know if there is an
> equivalent option that can be added to the @run tag).

Good point. I will fix this later as it is not inherently related to 
this bug.

>
> Otherwise, I'm scratching my head a bit on why the changes are needed.
> Clearly it fixes the case where $TESTJAVA is writable but the lib or
> jre/lib directory is not.

Apparently the bug description claims the situation. That's why I moved 
the writable check from the top dir to the exact dir where the test 
copies the properties file.

> Or is the main fix the cygpath -u ${TESTJAVA}
> so that TESTJAVA has the right path for -w ?

This is merely working around a bug with Cygwin's writable check (`test 
-w d:/foo` returns 1 even though the directory is not writable, while 
/cygdrive/d/foo returns 0)

Naoto

> If so then the changes look
> fine to me.
>
> -Alan.
>
>
> On 21/06/2013 18:30, Naoto Sato wrote:
>> Still need a reviewer for this one.
>>
>> Naoto
>>
>> On 6/18/13 1:35 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review this test case fix:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6863624
>>> http://cr.openjdk.java.net/~naoto/6863624/webrev.00/
>>>
>>> Basically it enforces the check for non-writable JDKs, with a workaround
>>> for Cygwin's inconsistent behavior for `test` command. Changes for
>>> LocaleProviders are irrelevant for this fix, just the left over from
>>> previous fix for 8015960.
>>>
>>> Naoto
>>
>


From Alan.Bateman at oracle.com  Fri Jun 21 13:34:47 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Jun 2013 21:34:47 +0100
Subject: <i18n dev> [8] Request for Review: 6863624 :
 java/util/Currency/PropertiesTest.sh writable check is incorrect
In-Reply-To: <51C4B7D8.3070301@oracle.com>
References: <51C0C474.1060004@oracle.com> <51C48DB8.7050100@oracle.com>
	<51C4B198.5010801@oracle.com> <51C4B7D8.3070301@oracle.com>
Message-ID: <51C4B8E7.3040103@oracle.com>

On 21/06/2013 21:30, Naoto Sato wrote:
>
> Good point. I will fix this later as it is not inherently related to 
> this bug.
Sure, it was just something that came to mind as I looked at it.

>
> Apparently the bug description claims the situation. That's why I 
> moved the writable check from the top dir to the exact dir where the 
> test copies the properties file.
Okay, although I suspect this case isn't too common.

>
> This is merely working around a bug with Cygwin's writable check 
> (`test -w d:/foo` returns 1 even though the directory is not writable, 
> while /cygdrive/d/foo returns 0)
Got it, looks good to me.

-Alan.

From Alan.Bateman at oracle.com  Sat Jun 22 08:34:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 22 Jun 2013 16:34:34 +0100
Subject: <i18n dev> TimeZone.DispayNames - remove it?
Message-ID: <51C5C40A.1040002@oracle.com>


While snooping around in java.util.TimeZone I came across DisplayNames 
which doesn't appear to be be used anymore as the display cache is moved 
to TimeZoneNameUtility. Any objection if I remove it via the attached 
patched? The JDK builds without it and I am confident it is not used 
anywhere.

-Alan


diff --git a/src/share/classes/java/util/TimeZone.java 
b/src/share/classes/java/util/TimeZone.java
--- a/src/share/classes/java/util/TimeZone.java
+++ b/src/share/classes/java/util/TimeZone.java
@@ -419,17 +419,6 @@
          return ZoneInfoFile.toCustomID(offset);
      }

-    private static class DisplayNames {
-        // Cache for managing display names per timezone per locale
-        // The structure is:
-        //   Map(key=id, value=SoftReference(Map(key=locale, 
value=displaynames)))
-        private static final Map<String, SoftReference<Map<Locale, 
String[]>>> CACHE =
-            new ConcurrentHashMap<>();
-
-        private DisplayNames() {
-        }
-    }
-
      private static String[] getDisplayNames(String id, Locale locale) {
          return TimeZoneNameUtility.retrieveDisplayNames(id, locale);
      }

From masayoshi.okutsu at oracle.com  Sun Jun 23 19:49:45 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 24 Jun 2013 11:49:45 +0900
Subject: <i18n dev> TimeZone.DispayNames - remove it?
In-Reply-To: <51C5C40A.1040002@oracle.com>
References: <51C5C40A.1040002@oracle.com>
Message-ID: <51C7B3C9.9050109@oracle.com>

This appears to be a leftover of the cache cleanup activity. The fix 
looks good to me.

Masayoshi

On 6/23/2013 12:34 AM, Alan Bateman wrote:
>
> While snooping around in java.util.TimeZone I came across DisplayNames 
> which doesn't appear to be be used anymore as the display cache is 
> moved to TimeZoneNameUtility. Any objection if I remove it via the 
> attached patched? The JDK builds without it and I am confident it is 
> not used anywhere.
>
> -Alan
>
>
> diff --git a/src/share/classes/java/util/TimeZone.java 
> b/src/share/classes/java/util/TimeZone.java
> --- a/src/share/classes/java/util/TimeZone.java
> +++ b/src/share/classes/java/util/TimeZone.java
> @@ -419,17 +419,6 @@
>          return ZoneInfoFile.toCustomID(offset);
>      }
>
> -    private static class DisplayNames {
> -        // Cache for managing display names per timezone per locale
> -        // The structure is:
> -        //   Map(key=id, value=SoftReference(Map(key=locale, 
> value=displaynames)))
> -        private static final Map<String, SoftReference<Map<Locale, 
> String[]>>> CACHE =
> -            new ConcurrentHashMap<>();
> -
> -        private DisplayNames() {
> -        }
> -    }
> -
>      private static String[] getDisplayNames(String id, Locale locale) {
>          return TimeZoneNameUtility.retrieveDisplayNames(id, locale);
>      }


From Alan.Bateman at oracle.com  Mon Jun 24 03:30:15 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 24 Jun 2013 11:30:15 +0100
Subject: <i18n dev> TimeZone.DispayNames - remove it?
In-Reply-To: <51C7B3C9.9050109@oracle.com>
References: <51C5C40A.1040002@oracle.com> <51C7B3C9.9050109@oracle.com>
Message-ID: <51C81FB7.2030803@oracle.com>

On 24/06/2013 03:49, Masayoshi Okutsu wrote:
> This appears to be a leftover of the cache cleanup activity. The fix 
> looks good to me.
>
> Masayoshi
>
Thanks. I've created 8017477 and will push this to jdk8/tl shortly.

-Alan


From naoto.sato at oracle.com  Mon Jun 24 14:20:46 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 24 Jun 2013 14:20:46 -0700
Subject: <i18n dev> [8] Request for review: 8017322:
 java/util/Currency/PropertiesTest.sh should run exclusively
Message-ID: <51C8B82E.40601@oracle.com>

Hello,

Please review the following test case fix. This is a follow-up for the 
issue that Alan pointed out [1].

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017322
http://cr.openjdk.java.net/~naoto/8017322/webrev.00/

Naoto

[1]: http://mail.openjdk.java.net/pipermail/i18n-dev/2013-June/001047.html

From naoto.sato at oracle.com  Mon Jun 24 15:18:48 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 24 Jun 2013 15:18:48 -0700
Subject: <i18n dev> [8] Request for review: 8017468 : typo in javadoc: "
 ResourceBunlde "
Message-ID: <51C8C5C8.3050303@oracle.com>

Another very simple review request:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017468
http://cr.openjdk.java.net/~naoto/8017468/webrev.00/

It's just fixing a typo in the ResourceBundle's class documentation.

Naoto

From masayoshi.okutsu at oracle.com  Mon Jun 24 16:15:49 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 25 Jun 2013 08:15:49 +0900
Subject: <i18n dev> [8] Request for review: 8017468 : typo in javadoc: "
 ResourceBunlde "
In-Reply-To: <51C8C5C8.3050303@oracle.com>
References: <51C8C5C8.3050303@oracle.com>
Message-ID: <51C8D325.8030003@oracle.com>

Looks good.

Masayoshi

On 6/25/2013 7:18 AM, Naoto Sato wrote:
> Another very simple review request:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017468
> http://cr.openjdk.java.net/~naoto/8017468/webrev.00/
>
> It's just fixing a typo in the ResourceBundle's class documentation.
>
> Naoto


From weijun.wang at oracle.com  Mon Jun 24 21:31:41 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 25 Jun 2013 12:31:41 +0800
Subject: <i18n dev> [8] Request for review: 8011870: i18n translations
	for JDK-8009636
In-Reply-To: <51C08EA5.70503@oracle.com>
References: <51BFF7EF.4090302@oracle.com> <51C001B5.7090303@oracle.com>
	<2E214EC5-9F71-44F7-A988-AD6646F7E329@oracle.com>
	<51C08EA5.70503@oracle.com>
Message-ID: <51C91D2D.2010800@oracle.com>

The change looks fine.

Thanks
Max

>>>
>>> On 6/17/2013 11:02 PM, Michael Fang wrote:
>>>> Hi Joe and all,
>>>>
>>>> Please help to review the changes for the following CR:
>>>> http://bugs.sun.com/view_bug.do?bug_id=8011870
>>>>
>>>> The webrev is available here:
>>>> http://cr.openjdk.java.net/~mfang/8011870/
>>>> It's part of webrev for 8015657: jdk8 l10n resource file translation
>>>> update 3
>>>>
>>>> Please only look at the webrev for the following 2 files:
>>>> src/share/classes/sun/security/tools/jarsigner/Resources_ja.java*
>>>> *src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
>>>>
>>>> thanks,
>>>>
>>>> -michael
>>>

From Alan.Bateman at oracle.com  Tue Jun 25 01:30:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Jun 2013 09:30:16 +0100
Subject: <i18n dev> [8] Request for review: 8017322:
 java/util/Currency/PropertiesTest.sh should run exclusively
In-Reply-To: <51C8B82E.40601@oracle.com>
References: <51C8B82E.40601@oracle.com>
Message-ID: <51C95518.5010501@oracle.com>

On 24/06/2013 22:20, Naoto Sato wrote:
> Hello,
>
> Please review the following test case fix. This is a follow-up for the 
> issue that Alan pointed out [1].
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017322
> http://cr.openjdk.java.net/~naoto/8017322/webrev.00/
>
> Naoto
>
> [1]: 
> http://mail.openjdk.java.net/pipermail/i18n-dev/2013-June/001047.html
This forces all tests in java/util/Currency/** to execute sequentially. 
I wonder if there is an option for @run to require this on a per tests 
basis, I think we should check this first. If there isn't an option then 
the change in the webrev looks fine.

-Alan

From naoto.sato at oracle.com  Tue Jun 25 09:50:44 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 25 Jun 2013 09:50:44 -0700
Subject: <i18n dev> [8] Request for review: 8017322:
 java/util/Currency/PropertiesTest.sh should run exclusively
In-Reply-To: <51C95518.5010501@oracle.com>
References: <51C8B82E.40601@oracle.com> <51C95518.5010501@oracle.com>
Message-ID: <51C9CA64.2050200@oracle.com>

I could not find the option for @run to execute individual tests 
exclusively in this doc:

http://openjdk.java.net/jtreg/tag-spec.txt

Naoto

On 6/25/13 1:30 AM, Alan Bateman wrote:
> On 24/06/2013 22:20, Naoto Sato wrote:
>> Hello,
>>
>> Please review the following test case fix. This is a follow-up for the
>> issue that Alan pointed out [1].
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017322
>> http://cr.openjdk.java.net/~naoto/8017322/webrev.00/
>>
>> Naoto
>>
>> [1]:
>> http://mail.openjdk.java.net/pipermail/i18n-dev/2013-June/001047.html
> This forces all tests in java/util/Currency/** to execute sequentially.
> I wonder if there is an option for @run to require this on a per tests
> basis, I think we should check this first. If there isn't an option then
> the change in the webrev looks fine.
>
> -Alan


From naoto.sato at oracle.com  Wed Jun 26 16:58:30 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 26 Jun 2013 16:58:30 -0700
Subject: <i18n dev> [8] Request for review: 6609431 : (rb)
 ResourceBundle.getString() returns incorrect value
Message-ID: <51CB8026.10109@oracle.com>

Hello,

Please review the following fix:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6609431
http://cr.openjdk.java.net/~naoto/6609431/webrev.00/

The failure was caused by an unnecessary escaping when a backslash is at 
the very end of a properties file.

Naoto

From masayoshi.okutsu at oracle.com  Wed Jun 26 22:36:17 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 27 Jun 2013 14:36:17 +0900
Subject: <i18n dev> [8] Request for review: 6609431 : (rb)
 ResourceBundle.getString() returns incorrect value
In-Reply-To: <51CB8026.10109@oracle.com>
References: <51CB8026.10109@oracle.com>
Message-ID: <51CBCF51.1060402@oracle.com>

Looks good to me. But I'd like Sherman to take a look at the fix.

Masayoshi

On 6/27/2013 8:58 AM, Naoto Sato wrote:
> Hello,
>
> Please review the following fix:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6609431
> http://cr.openjdk.java.net/~naoto/6609431/webrev.00/
>
> The failure was caused by an unnecessary escaping when a backslash is 
> at the very end of a properties file.
>
> Naoto


From youdwei at linux.vnet.ibm.com  Sun Jun 30 23:20:32 2013
From: youdwei at linux.vnet.ibm.com (Deven You)
Date: Mon, 01 Jul 2013 14:20:32 +0800
Subject: <i18n dev> <AWT Dev> Preedit string is still exist after focus
 change operation
In-Reply-To: <51928469.6090009@oracle.com>
References: <518B5156.7060205@linux.vnet.ibm.com>
	<51922E4A.4080004@oracle.com> <51928469.6090009@oracle.com>
Message-ID: <51D11FB0.6030708@linux.vnet.ibm.com>

Hi Anthony and Naoto,

Thanks very much for your suggestions and help!

I have created a jtreg test[1] according to the example of 
SpuriousExitEnter.java.

The more detail information about the test could still be inspected by [2].

Please review the updated webrev[1].

Thanks a lot!

[1] http://cr.openjdk.java.net/~youdwei/ojdk-687/webrev0.2/
[2] http://cr.openjdk.java.net/~youdwei/ojdk-687/IMF4/
On 05/15/2013 02:37 AM, Naoto Sato wrote:
> 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!
>