From yuka.kamiya at oracle.com  Tue Oct  1 19:56:53 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 02 Oct 2013 11:56:53 +0900
Subject: <i18n dev> [8]RFR: 6902861: (cal) GregorianCalendar roll
 WEEK_OF_YEAR is broken for January 1 2010
In-Reply-To: <5243FF6C.3030406@oracle.com>
References: <5243FF6C.3030406@oracle.com>
Message-ID: <524B8B75.2000406@oracle.com>

Hi,

The fix looks ok to me.

Thanks,
--
Yuka

(2013/09/26 18:33), Masayoshi Okutsu wrote:
> Hi,
>
> Please view the fix (workaround) for the following bug.
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6902861
>
> Added a workaround that Calendar.roll tries to stay in the same calendar year even when WEEK_OF_YEAR and YEAR are "out of sync". The real fix should be to add a new method, like rollWeeksInWeekYear(int amount), which handles rolling weeks within a week-based year rather than a calendar year.
>
> http://cr.openjdk.java.net/~okutsu/8/6902861/webrev.00/
>
> Thanks,
> Masayoshi
>


From masayoshi.okutsu at oracle.com  Wed Oct  2 00:50:48 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 02 Oct 2013 16:50:48 +0900
Subject: <i18n dev> [8]RFR: 8022666: java.util.Calendar.set(int, int, int,
 int, int, int) documentation typo
Message-ID: <524BD058.1000901@oracle.com>

Hi,

Please review the doc fix for the following bug:

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

Webev:
http://cr.openjdk.java.net/~okutsu/8/8022666/webrev.00/

Thanks,
Masayoshi


From yuka.kamiya at oracle.com  Wed Oct  2 01:40:58 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 02 Oct 2013 17:40:58 +0900
Subject: <i18n dev> [8]RFR: 8022666: java.util.Calendar.set(int, int, int,
 int, int, int) documentation typo
In-Reply-To: <524BD058.1000901@oracle.com>
References: <524BD058.1000901@oracle.com>
Message-ID: <524BDC1A.3000706@oracle.com>

Hi,

The change looks good to me.

Thanks,
--
Yuka

(2013/10/02 16:50), Masayoshi Okutsu wrote:
> Hi,
>
> Please review the doc fix for the following bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8022666
>
> Webev:
> http://cr.openjdk.java.net/~okutsu/8/8022666/webrev.00/
>
> Thanks,
> Masayoshi
>


From amarshi.mohanty at nsn.com  Tue Oct  8 02:07:03 2013
From: amarshi.mohanty at nsn.com (amarshi)
Date: Tue, 8 Oct 2013 02:07:03 -0700 (PDT)
Subject: <i18n dev> DST for Israel
Message-ID: <1381223223351-159220.post@n7.nabble.com>

Hi,
I am currently using openJDK-7 , but there is a problem with the Daylight
Savings Time in Israel Location.
With openJDK-7, the DST is not taken into account for Israel.
Please let me know any solution / suggestion for any fix to this problem.

Regards,
amarshi



--
View this message in context: http://openjdk.5641.n7.nabble.com/DST-for-Israel-tp159220.html
Sent from the OpenJDK Internationalization Libraries mailing list archive at Nabble.com.

From naoto.sato at oracle.com  Tue Oct  8 11:16:55 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 08 Oct 2013 11:16:55 -0700
Subject: <i18n dev> java sinhalese...
In-Reply-To: <1377049923825-149658.post@n7.nabble.com>
References: <1377049923825-149658.post@n7.nabble.com>
Message-ID: <52544C17.9090308@oracle.com>

Hello,

Although we don't officially support Sinhala script, the rendering 
engine should be able to render Sinhala with a proper font provided. You 
are welcome to file a bug on this at bugs.openjdk.java.net.

JavaFX8 which is bundled in JDK8 may be able to render it correctly, but 
not sure as I haven't tried.

Naoto

On 8/20/13 6:52 PM, stark9000 wrote:
> Please let me know how to fix this :
>
> <http://openjdk.5641.n7.nabble.com/file/n149658/1.jpg>
>
> Unicode font used : http://www.kaputa.com/slword/kaputaunicode.zip
>
>
>
>
>
> --
> View this message in context: http://openjdk.5641.n7.nabble.com/java-sinhalese-tp149658.html
> Sent from the OpenJDK Internationalization Libraries mailing list archive at Nabble.com.
>


From steven.loomis at oracle.com  Tue Oct  8 11:30:01 2013
From: steven.loomis at oracle.com (Steven R. Loomis)
Date: Tue, 08 Oct 2013 11:30:01 -0700
Subject: <i18n dev> java sinhalese...
In-Reply-To: <52544C17.9090308@oracle.com>
References: <1377049923825-149658.post@n7.nabble.com>
	<52544C17.9090308@oracle.com>
Message-ID: <52544F29.4040000@oracle.com>

Is there different behavior with a different font?
As noted, please create a minimal test case and file a bug. Be sure the
original text is included so that it is reproducible.
-s

On 08/10/13 11:16, Naoto Sato wrote:
> Hello,
>
> Although we don't officially support Sinhala script, the rendering
> engine should be able to render Sinhala with a proper font provided.
> You are welcome to file a bug on this at bugs.openjdk.java.net.
>
> JavaFX8 which is bundled in JDK8 may be able to render it correctly,
> but not sure as I haven't tried.
>
> Naoto
>
> On 8/20/13 6:52 PM, stark9000 wrote:
>> Please let me know how to fix this :
>>
>> <http://openjdk.5641.n7.nabble.com/file/n149658/1.jpg>
>>
>> Unicode font used : http://www.kaputa.com/slword/kaputaunicode.zip


From masayoshi.okutsu at oracle.com  Tue Oct  8 21:24:16 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 09 Oct 2013 13:24:16 +0900
Subject: <i18n dev> DST for Israel
In-Reply-To: <1381223223351-159220.post@n7.nabble.com>
References: <1381223223351-159220.post@n7.nabble.com>
Message-ID: <5254DA70.60904@oracle.com>

Hi amarshi,

The current tzdata version of openjdk-7 seems to be 2013d which should 
be the latest for Israel. What version of openjdk-7 are you using?

Thanks,
Masayoshi

On 10/8/2013 6:07 PM, amarshi wrote:
> Hi,
> I am currently using openJDK-7 , but there is a problem with the Daylight
> Savings Time in Israel Location.
> With openJDK-7, the DST is not taken into account for Israel.
> Please let me know any solution / suggestion for any fix to this problem.
>
> Regards,
> amarshi
>
>
>
> --
> View this message in context: http://openjdk.5641.n7.nabble.com/DST-for-Israel-tp159220.html
> Sent from the OpenJDK Internationalization Libraries mailing list archive at Nabble.com.


From naoto.sato at oracle.com  Wed Oct  9 12:49:51 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 09 Oct 2013 12:49:51 -0700
Subject: <i18n dev> RFR: JDK-8025712, ,
 (props) Possible memory leak in java_props_md.c / ParseLocale
In-Reply-To: <5255A597.9030007@oracle.com>
References: <5255A597.9030007@oracle.com>
Message-ID: <5255B35F.6090104@oracle.com>

Looks good to me.

Naoto

On 10/9/13 11:51 AM, Dan Xu wrote:
> Hi All,
>
> This fix is to solve the memory leak issue in ParseLocale() function of
> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale,
> lc, is copied into temp, it is not necessary to do the strdup(), which
> leads to the memery leak. The fix simply removes the line of strdup
> operation. Thanks!
>
> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712
>
> -Dan


From dan.xu at oracle.com  Wed Oct  9 11:51:03 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 09 Oct 2013 11:51:03 -0700
Subject: <i18n dev> RFR: JDK-8025712, ,
 (props) Possible memory leak in java_props_md.c / ParseLocale
Message-ID: <5255A597.9030007@oracle.com>

Hi All,

This fix is to solve the memory leak issue in ParseLocale() function of 
jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, 
lc, is copied into temp, it is not necessary to do the strdup(), which 
leads to the memery leak. The fix simply removes the line of strdup 
operation. Thanks!

Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8025712

-Dan

From amarshi.mohanty at nsn.com  Tue Oct  8 22:04:17 2013
From: amarshi.mohanty at nsn.com (amarshi)
Date: Tue, 8 Oct 2013 22:04:17 -0700 (PDT)
Subject: <i18n dev> DST for Israel
In-Reply-To: <1381223223351-159220.post@n7.nabble.com>
References: <1381223223351-159220.post@n7.nabble.com>
Message-ID: <1381295057103-159510.post@n7.nabble.com>

Hi Masayoshi,
Thanks for your response.
Currently i am using  "openjdk-7u6-fcs-src-b24-28_aug_2012".
With this version , the DST of 1 hour is not considered.
Do you think any other version of openjdk7 will resolve this issue.

Regards,
amarshi




--
View this message in context: http://openjdk.5641.n7.nabble.com/DST-for-Israel-tp159220p159510.html
Sent from the OpenJDK Internationalization Libraries mailing list archive at Nabble.com.

From scolebourne at joda.org  Wed Oct  9 15:24:21 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 9 Oct 2013 23:24:21 +0100
Subject: <i18n dev> Support Hijri calendar
In-Reply-To: <523C5AD1.5040507@gmail.com>
References: <523C5AD1.5040507@gmail.com>
Message-ID: <CACzrW9AJo13vbhZCDB6Cita14Wa3o7-sMDFMNP=RNzA5=cWLOw@mail.gmail.com>

On 20 September 2013 15:25, Suhail Alkowaileet <xsoh.k7 at gmail.com> wrote:
> I would like to support the lunar Hijri calendar(see:
> https://en.wikipedia.org/wiki/Hijri ) to the jdk and I'm just asking should
> I do something before doing this?
> My plan is to clone the jdk8/l10n/jdk and add the appropriate files to of
> the Hijri and push them back. I'm going to use the Umm al-Qura calendar as
> the way of calculating(see:
> https://en.wikipedia.org/wiki/Hijri#Saudi_Arabia.27s_Umm_al-Qura_calendar ).

Just to note that JDK8 will include Hijri Umm al-Qura
http://download.java.net/jdk8/docs/api/java/time/chrono/package-summary.html

Stephen

From chris.hegarty at oracle.com  Thu Oct 10 02:22:18 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 10 Oct 2013 10:22:18 +0100
Subject: <i18n dev> RFR: JDK-8025712, ,
 (props) Possible memory leak in java_props_md.c / ParseLocale
In-Reply-To: <5255A597.9030007@oracle.com>
References: <5255A597.9030007@oracle.com>
Message-ID: <525671CA.5080904@oracle.com>

Dan,

Your changes look fine to me.

While looking at this I notice that there is another potential leak. If 
the malloc for temp fails, then we need to free lc ( for MAC only ), right?

-Chris.

On 10/09/2013 07:51 PM, Dan Xu wrote:
> Hi All,
>
> This fix is to solve the memory leak issue in ParseLocale() function of
> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale,
> lc, is copied into temp, it is not necessary to do the strdup(), which
> leads to the memery leak. The fix simply removes the line of strdup
> operation. Thanks!
>
> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712
>
> -Dan

From aleksej.efimov at oracle.com  Thu Oct 10 06:30:05 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 10 Oct 2013 17:30:05 +0400
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
Message-ID: <5256ABDD.9060900@oracle.com>

Hi,

Please, review the changes [1] needed to address the tz data update in 
JDK 8 from tzdata2013d to tzdata2013g.

The brief list of changes:
1. tzdata2013g data was integrated to tzdb data files 
(make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data 
files (test/sun/util/calendar/zi/tzdata/* changes).
2. a) Updates to long time zone names
     b) Updates to short name changes to address corresponding changes 
in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
     c) Removed unused ACT[] array
     d) Added "Europe/Busingen" time zone name
     All this changes a)->d) relates to 
src/share/classes/sun/util/resources/TimeZoneNames*.java files

The following tests were executed on JDK 8 with fix:
test/java/util/TimeZone
test/java/util/Calendar
test/java/util/Formatter
test/sun/util/calendar
test/java/time

Testing result: All test passed

Thanks!
Aleksej

[1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ 
<http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>


From naoto.sato at oracle.com  Thu Oct 10 15:14:40 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 10 Oct 2013 15:14:40 -0700
Subject: <i18n dev> RFR: JDK-8025712, ,
 (props) Possible memory leak in java_props_md.c / ParseLocale
In-Reply-To: <52570CD6.6040602@oracle.com>
References: <5255A597.9030007@oracle.com> <525671CA.5080904@oracle.com>
	<52570CD6.6040602@oracle.com>
Message-ID: <525726D0.9030807@oracle.com>

You could, but that part only relates to the @euro locales handling, 
which is at this moment almost obsolete, let alone for MacOSX platform. 
So the current code should work fine.

Naoto

On 10/10/13 1:23 PM, Dan Xu wrote:
> Good catch, Chris.
>
> Btw, according to the description, it seems the block in #ifndef
> __linux__ is the workaround only for Solaris. Shall we use a more strict
> macro here instead of #ifndef __linux__? Thanks!
>
> -Dan
>
> On 10/10/2013 02:22 AM, Chris Hegarty wrote:
>> Dan,
>>
>> Your changes look fine to me.
>>
>> While looking at this I notice that there is another potential leak.
>> If the malloc for temp fails, then we need to free lc ( for MAC only
>> ), right?
>>
>> -Chris.
>>
>> On 10/09/2013 07:51 PM, Dan Xu wrote:
>>> Hi All,
>>>
>>> This fix is to solve the memory leak issue in ParseLocale() function of
>>> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale,
>>> lc, is copied into temp, it is not necessary to do the strdup(), which
>>> leads to the memery leak. The fix simply removes the line of strdup
>>> operation. Thanks!
>>>
>>> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712
>>>
>>> -Dan
>


From masayoshi.okutsu at oracle.com  Thu Oct 10 21:54:07 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 11 Oct 2013 13:54:07 +0900
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <5256ABDD.9060900@oracle.com>
References: <5256ABDD.9060900@oracle.com>
Message-ID: <5257846F.6020509@oracle.com>

Hi Aleksej,

Here are my review comments.

- The copyright header of the data files shouldn't be removed.

- TimeZoneNames.java:

-                                  "Middle Europe Time", "MET"}},
+                                  "MET", "MET"}},

I don't think the long name should be changed.

I didn't review the localized TimeZoneNames_*.java files. If L10N Team 
is OK with them, I'm fine.

Thanks,
Masayoshi

On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
> Hi,
>
> Please, review the changes [1] needed to address the tz data update in 
> JDK 8 from tzdata2013d to tzdata2013g.
>
> The brief list of changes:
> 1. tzdata2013g data was integrated to tzdb data files 
> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data 
> files (test/sun/util/calendar/zi/tzdata/* changes).
> 2. a) Updates to long time zone names
>     b) Updates to short name changes to address corresponding changes 
> in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>     c) Removed unused ACT[] array
>     d) Added "Europe/Busingen" time zone name
>     All this changes a)->d) relates to 
> src/share/classes/sun/util/resources/TimeZoneNames*.java files
>
> The following tests were executed on JDK 8 with fix:
> test/java/util/TimeZone
> test/java/util/Calendar
> test/java/util/Formatter
> test/sun/util/calendar
> test/java/time
>
> Testing result: All test passed
>
> Thanks!
> Aleksej
>
> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
>


From aleksej.efimov at oracle.com  Fri Oct 11 02:37:20 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 11 Oct 2013 13:37:20 +0400
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <5257846F.6020509@oracle.com>
References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com>
Message-ID: <5257C6D0.9060404@oracle.com>

Hi Masayoshi,
Thank you for your comments. Replies are below.

On 10/11/2013 08:54 AM, Masayoshi Okutsu wrote:
> Hi Aleksej,
>
> Here are my review comments.
>
> - The copyright header of the data files shouldn't be removed.
The copyright header is absent in raw tzdata2013g release (in 
tzdata2013g.tar.gz). I didn't do any modification to it.
>
> - TimeZoneNames.java:
> -                                  "Middle Europe Time", "MET"}},
> +                                  "MET", "MET"}},
> I don't think the long name should be changed.

Agree, will change it back.

>
> I didn't review the localized TimeZoneNames_*.java files. If L10N Team 
> is OK with them, I'm fine.
>
> Thanks,
> Masayoshi
>
> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>> Hi,
>>
>> Please, review the changes [1] needed to address the tz data update 
>> in JDK 8 from tzdata2013d to tzdata2013g.
>>
>> The brief list of changes:
>> 1. tzdata2013g data was integrated to tzdb data files 
>> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test 
>> data files (test/sun/util/calendar/zi/tzdata/* changes).
>> 2. a) Updates to long time zone names
>>     b) Updates to short name changes to address corresponding changes 
>> in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>>     c) Removed unused ACT[] array
>>     d) Added "Europe/Busingen" time zone name
>>     All this changes a)->d) relates to 
>> src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>
>> The following tests were executed on JDK 8 with fix:
>> test/java/util/TimeZone
>> test/java/util/Calendar
>> test/java/util/Formatter
>> test/sun/util/calendar
>> test/java/time
>>
>> Testing result: All test passed
>>
>> Thanks!
>> Aleksej
>>
>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
>>
>


From chris.hegarty at oracle.com  Fri Oct 11 03:48:06 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 11 Oct 2013 11:48:06 +0100
Subject: <i18n dev> RFR: JDK-8025712, ,
 (props) Possible memory leak in java_props_md.c / ParseLocale
In-Reply-To: <5257666C.3080104@oracle.com>
References: <5255A597.9030007@oracle.com> <525671CA.5080904@oracle.com>
	<52570CD6.6040602@oracle.com> <525726D0.9030807@oracle.com>
	<5257666C.3080104@oracle.com>
Message-ID: <5257D766.30408@oracle.com>

Thanks Dan, looks good to me.

-Chris.

On 11/10/2013 03:46, Dan Xu wrote:
> Thanks for your clarification, Naoto.
>
> Here is the updated webrev,
> http://cr.openjdk.java.net/~dxu/8025712/webrev.01/. Please help review it.
>
> -Dan
>
> On 10/10/2013 03:14 PM, Naoto Sato wrote:
>> You could, but that part only relates to the @euro locales handling,
>> which is at this moment almost obsolete, let alone for MacOSX
>> platform. So the current code should work fine.
>>
>> Naoto
>>
>> On 10/10/13 1:23 PM, Dan Xu wrote:
>>> Good catch, Chris.
>>>
>>> Btw, according to the description, it seems the block in #ifndef
>>> __linux__ is the workaround only for Solaris. Shall we use a more strict
>>> macro here instead of #ifndef __linux__? Thanks!
>>>
>>> -Dan
>>>
>>> On 10/10/2013 02:22 AM, Chris Hegarty wrote:
>>>> Dan,
>>>>
>>>> Your changes look fine to me.
>>>>
>>>> While looking at this I notice that there is another potential leak.
>>>> If the malloc for temp fails, then we need to free lc ( for MAC only
>>>> ), right?
>>>>
>>>> -Chris.
>>>>
>>>> On 10/09/2013 07:51 PM, Dan Xu wrote:
>>>>> Hi All,
>>>>>
>>>>> This fix is to solve the memory leak issue in ParseLocale()
>>>>> function of
>>>>> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale,
>>>>> lc, is copied into temp, it is not necessary to do the strdup(), which
>>>>> leads to the memery leak. The fix simply removes the line of strdup
>>>>> operation. Thanks!
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712
>>>>>
>>>>> -Dan
>>>
>>
>

From aleksej.efimov at oracle.com  Fri Oct 11 06:46:58 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 11 Oct 2013 17:46:58 +0400
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <5257C6D0.9060404@oracle.com>
References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com>
	<5257C6D0.9060404@oracle.com>
Message-ID: <52580152.90801@oracle.com>

Hi Masayoshi,
The new webrev with addressed review comments: 
http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.01/ 
<http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.01/>

The list of changes:
1. "Middle Europe Time" remained untouched.
2. The copyright headers were added.

Best Regards,
Aleksej


On 10/11/2013 01:37 PM, Aleksej Efimov wrote:
> Hi Masayoshi,
> Thank you for your comments. Replies are below.
>
> On 10/11/2013 08:54 AM, Masayoshi Okutsu wrote:
>> Hi Aleksej,
>>
>> Here are my review comments.
>>
>> - The copyright header of the data files shouldn't be removed.
> The copyright header is absent in raw tzdata2013g release (in 
> tzdata2013g.tar.gz). I didn't do any modification to it.
>>
>> - TimeZoneNames.java:
>> -                                  "Middle Europe Time", "MET"}},
>> +                                  "MET", "MET"}},
>> I don't think the long name should be changed.
>
> Agree, will change it back.
>
>>
>> I didn't review the localized TimeZoneNames_*.java files. If L10N 
>> Team is OK with them, I'm fine.
>>
>> Thanks,
>> Masayoshi
>>
>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>>> Hi,
>>>
>>> Please, review the changes [1] needed to address the tz data update 
>>> in JDK 8 from tzdata2013d to tzdata2013g.
>>>
>>> The brief list of changes:
>>> 1. tzdata2013g data was integrated to tzdb data files 
>>> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test 
>>> data files (test/sun/util/calendar/zi/tzdata/* changes).
>>> 2. a) Updates to long time zone names
>>>     b) Updates to short name changes to address corresponding 
>>> changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>>>     c) Removed unused ACT[] array
>>>     d) Added "Europe/Busingen" time zone name
>>>     All this changes a)->d) relates to 
>>> src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>>
>>> The following tests were executed on JDK 8 with fix:
>>> test/java/util/TimeZone
>>> test/java/util/Calendar
>>> test/java/util/Formatter
>>> test/sun/util/calendar
>>> test/java/time
>>>
>>> Testing result: All test passed
>>>
>>> Thanks!
>>> Aleksej
>>>
>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
>>>
>>
>


From michael.fang at oracle.com  Fri Oct 11 10:41:38 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Fri, 11 Oct 2013 10:41:38 -0700
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <5257846F.6020509@oracle.com>
References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com>
Message-ID: <52583852.3010004@oracle.com>

Hi Aleksej,

I took a look at the localized TimeZoneNames_*.java files. They do not 
contain generic time zone names for JSR310...

I think we can file a separate bug to track that issue.

thanks,

-michael

On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote:
> Hi Aleksej,
>
> Here are my review comments.
>
> - The copyright header of the data files shouldn't be removed.
>
> - TimeZoneNames.java:
>
> - "Middle Europe Time", "MET"}},
> + "MET", "MET"}},
>
> I don't think the long name should be changed.
>
> I didn't review the localized TimeZoneNames_*.java files. If L10N Team 
> is OK with them, I'm fine.
>
> Thanks,
> Masayoshi
>
> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>> Hi,
>>
>> Please, review the changes [1] needed to address the tz data update 
>> in JDK 8 from tzdata2013d to tzdata2013g.
>>
>> The brief list of changes:
>> 1. tzdata2013g data was integrated to tzdb data files 
>> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test 
>> data files (test/sun/util/calendar/zi/tzdata/* changes).
>> 2. a) Updates to long time zone names
>> b) Updates to short name changes to address corresponding changes in 
>> tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>> c) Removed unused ACT[] array
>> d) Added "Europe/Busingen" time zone name
>> All this changes a)->d) relates to 
>> src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>
>> The following tests were executed on JDK 8 with fix:
>> test/java/util/TimeZone
>> test/java/util/Calendar
>> test/java/util/Formatter
>> test/sun/util/calendar
>> test/java/time
>>
>> Testing result: All test passed
>>
>> Thanks!
>> Aleksej
>>
>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
>>
>


From naoto.sato at oracle.com  Fri Oct 11 11:06:14 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 11 Oct 2013 11:06:14 -0700
Subject: <i18n dev> RFR: JDK-8025712, ,
 (props) Possible memory leak in java_props_md.c / ParseLocale
In-Reply-To: <5257666C.3080104@oracle.com>
References: <5255A597.9030007@oracle.com> <525671CA.5080904@oracle.com>
	<52570CD6.6040602@oracle.com> <525726D0.9030807@oracle.com>
	<5257666C.3080104@oracle.com>
Message-ID: <52583E16.7030100@oracle.com>

Looks good. Thank you for fixing this.

Naoto

On 10/10/13 7:46 PM, Dan Xu wrote:
> Thanks for your clarification, Naoto.
>
> Here is the updated webrev,
> http://cr.openjdk.java.net/~dxu/8025712/webrev.01/. Please help review it.
>
> -Dan
>
> On 10/10/2013 03:14 PM, Naoto Sato wrote:
>> You could, but that part only relates to the @euro locales handling,
>> which is at this moment almost obsolete, let alone for MacOSX
>> platform. So the current code should work fine.
>>
>> Naoto
>>
>> On 10/10/13 1:23 PM, Dan Xu wrote:
>>> Good catch, Chris.
>>>
>>> Btw, according to the description, it seems the block in #ifndef
>>> __linux__ is the workaround only for Solaris. Shall we use a more strict
>>> macro here instead of #ifndef __linux__? Thanks!
>>>
>>> -Dan
>>>
>>> On 10/10/2013 02:22 AM, Chris Hegarty wrote:
>>>> Dan,
>>>>
>>>> Your changes look fine to me.
>>>>
>>>> While looking at this I notice that there is another potential leak.
>>>> If the malloc for temp fails, then we need to free lc ( for MAC only
>>>> ), right?
>>>>
>>>> -Chris.
>>>>
>>>> On 10/09/2013 07:51 PM, Dan Xu wrote:
>>>>> Hi All,
>>>>>
>>>>> This fix is to solve the memory leak issue in ParseLocale()
>>>>> function of
>>>>> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale,
>>>>> lc, is copied into temp, it is not necessary to do the strdup(), which
>>>>> leads to the memery leak. The fix simply removes the line of strdup
>>>>> operation. Thanks!
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712
>>>>>
>>>>> -Dan
>>>
>>
>


From aleksej.efimov at oracle.com  Fri Oct 11 12:20:41 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 11 Oct 2013 23:20:41 +0400
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <52583852.3010004@oracle.com>
References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com>
	<52583852.3010004@oracle.com>
Message-ID: <52584F89.3030007@oracle.com>

Hi Michael,
As I can see this topic was touched a little here: 
http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. 
AFAIU from the above discussion the CLDR generic names were translated 
in all locales, but the legacy JRE time zone names doesn't contain this 
translations.  And actually we already have opened bug for this task: 
https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it 
right after the tzdata update and it will include this changes.
But anyway, it's not highly related to tzdata updates. I think, this two 
processes can go separately. Do you agree?

Thanks and Best Regards,
Aleksej

On 11.10.2013 21:41, Michael Fang wrote:
> Hi Aleksej,
>
> I took a look at the localized TimeZoneNames_*.java files. They do not 
> contain generic time zone names for JSR310...
>
> I think we can file a separate bug to track that issue.
>
> thanks,
>
> -michael
>
> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote:
>> Hi Aleksej,
>>
>> Here are my review comments.
>>
>> - The copyright header of the data files shouldn't be removed.
>>
>> - TimeZoneNames.java:
>>
>> - "Middle Europe Time", "MET"}},
>> + "MET", "MET"}},
>>
>> I don't think the long name should be changed.
>>
>> I didn't review the localized TimeZoneNames_*.java files. If L10N 
>> Team is OK with them, I'm fine.
>>
>> Thanks,
>> Masayoshi
>>
>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>>> Hi,
>>>
>>> Please, review the changes [1] needed to address the tz data update 
>>> in JDK 8 from tzdata2013d to tzdata2013g.
>>>
>>> The brief list of changes:
>>> 1. tzdata2013g data was integrated to tzdb data files 
>>> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test 
>>> data files (test/sun/util/calendar/zi/tzdata/* changes).
>>> 2. a) Updates to long time zone names
>>> b) Updates to short name changes to address corresponding changes in 
>>> tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>>> c) Removed unused ACT[] array
>>> d) Added "Europe/Busingen" time zone name
>>> All this changes a)->d) relates to 
>>> src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>>
>>> The following tests were executed on JDK 8 with fix:
>>> test/java/util/TimeZone
>>> test/java/util/Calendar
>>> test/java/util/Formatter
>>> test/sun/util/calendar
>>> test/java/time
>>>
>>> Testing result: All test passed
>>>
>>> Thanks!
>>> Aleksej
>>>
>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
>>>
>>
>


From michael.fang at oracle.com  Fri Oct 11 13:43:08 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Fri, 11 Oct 2013 13:43:08 -0700
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <52584F89.3030007@oracle.com>
References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com>
	<52583852.3010004@oracle.com> <52584F89.3030007@oracle.com>
Message-ID: <ADA0C198-43E5-4389-B5DC-B6578BE9F7D9@oracle.com>

Hi Aleksej,

Yes, you are right. They can be handled separately. Thanks!

Regards,

Michael
Sent from my iPhone

On Oct 11, 2013, at 12:20 PM, Aleksej Efimov <aleksej.efimov at oracle.com> wrote:

> Hi Michael,
> As I can see this topic was touched a little here: http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations.  And actually we already have opened bug for this task: https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes.
> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree?
> 
> Thanks and Best Regards,
> Aleksej
> 
> On 11.10.2013 21:41, Michael Fang wrote:
>> Hi Aleksej,
>> 
>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310...
>> 
>> I think we can file a separate bug to track that issue.
>> 
>> thanks,
>> 
>> -michael
>> 
>> On 13?~10??10?? 09:54 ?U??, Masayoshi Okutsu wrote:
>>> Hi Aleksej,
>>> 
>>> Here are my review comments.
>>> 
>>> - The copyright header of the data files shouldn't be removed.
>>> 
>>> - TimeZoneNames.java:
>>> 
>>> - "Middle Europe Time", "MET"}},
>>> + "MET", "MET"}},
>>> 
>>> I don't think the long name should be changed.
>>> 
>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine.
>>> 
>>> Thanks,
>>> Masayoshi
>>> 
>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>>>> Hi,
>>>> 
>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g.
>>>> 
>>>> The brief list of changes:
>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes).
>>>> 2. a) Updates to long time zone names
>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>>>> c) Removed unused ACT[] array
>>>> d) Added "Europe/Busingen" time zone name
>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>>> 
>>>> The following tests were executed on JDK 8 with fix:
>>>> test/java/util/TimeZone
>>>> test/java/util/Calendar
>>>> test/java/util/Formatter
>>>> test/sun/util/calendar
>>>> test/java/time
>>>> 
>>>> Testing result: All test passed
>>>> 
>>>> Thanks!
>>>> Aleksej
>>>> 
>>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
> 

From aleksej.efimov at oracle.com  Sun Oct 13 03:23:47 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Sun, 13 Oct 2013 14:23:47 +0400
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <ADA0C198-43E5-4389-B5DC-B6578BE9F7D9@oracle.com>
References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com>
	<52583852.3010004@oracle.com> <52584F89.3030007@oracle.com>
	<ADA0C198-43E5-4389-B5DC-B6578BE9F7D9@oracle.com>
Message-ID: <525A74B3.6040300@oracle.com>

Michael, Masayoshi,

Looks like, we can commit this changes with following items in mind:
1. Generic names in TimeZoneNames_*.java should be added as part of
JDK-8025051 resolution.
2. I need another one approval from a JDK 8 reviewer for this one.

Anyway, the hg changeset patch can be found here:
http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch

Best Regards,
Aleksej

On 10/12/2013 12:43 AM, Michael Fang wrote:
> Hi Aleksej,
>
> Yes, you are right. They can be handled separately. Thanks!
>
> Regards,
>
> Michael
> Sent from my iPhone
>
> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov <aleksej.efimov at oracle.com> wrote:
>
>> Hi Michael,
>> As I can see this topic was touched a little here: http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations.  And actually we already have opened bug for this task: https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes.
>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree?
>>
>> Thanks and Best Regards,
>> Aleksej
>>
>> On 11.10.2013 21:41, Michael Fang wrote:
>>> Hi Aleksej,
>>>
>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310...
>>>
>>> I think we can file a separate bug to track that issue.
>>>
>>> thanks,
>>>
>>> -michael
>>>
>>> On 13?~10??10?? 09:54 ?U??, Masayoshi Okutsu wrote:
>>>> Hi Aleksej,
>>>>
>>>> Here are my review comments.
>>>>
>>>> - The copyright header of the data files shouldn't be removed.
>>>>
>>>> - TimeZoneNames.java:
>>>>
>>>> - "Middle Europe Time", "MET"}},
>>>> + "MET", "MET"}},
>>>>
>>>> I don't think the long name should be changed.
>>>>
>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>>>>> Hi,
>>>>>
>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g.
>>>>>
>>>>> The brief list of changes:
>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes).
>>>>> 2. a) Updates to long time zone names
>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>>>>> c) Removed unused ACT[] array
>>>>> d) Added "Europe/Busingen" time zone name
>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>>>>
>>>>> The following tests were executed on JDK 8 with fix:
>>>>> test/java/util/TimeZone
>>>>> test/java/util/Calendar
>>>>> test/java/util/Formatter
>>>>> test/sun/util/calendar
>>>>> test/java/time
>>>>>
>>>>> Testing result: All test passed
>>>>>
>>>>> Thanks!
>>>>> Aleksej
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>


From aleksej.efimov at oracle.com  Mon Oct 14 02:36:02 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 14 Oct 2013 13:36:02 +0400
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <525A74B3.6040300@oracle.com>
References: <5256ABDD.9060900@oracle.com>
	<5257846F.6020509@oracle.com>	<52583852.3010004@oracle.com>
	<52584F89.3030007@oracle.com>	<ADA0C198-43E5-4389-B5DC-B6578BE9F7D9@oracle.com>
	<525A74B3.6040300@oracle.com>
Message-ID: <525BBB02.9060805@oracle.com>

Hi,
The second item is dropped - I was informed in a parallel review thread,
that I can have one approval from a Reviewer and another approval[s]
from members.
The hg patch was updated and located here:
http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch
<http://cr.openjdk.java.net/%7Eaefimov/8025255/8/8025255_jdk8.patch>

Can I ask for a sponsor help to push this fix?

Thank you and Best Regards,
Aleksej

On 10/13/2013 02:23 PM, Aleksej Efimov wrote:
> Michael, Masayoshi,
>
> Looks like, we can commit this changes with following items in mind:
> 1. Generic names in TimeZoneNames_*.java should be added as part of
> JDK-8025051 resolution.
> 2. I need another one approval from a JDK 8 reviewer for this one.
>
> Anyway, the hg changeset patch can be found here:
> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch
>
> Best Regards,
> Aleksej
>
> On 10/12/2013 12:43 AM, Michael Fang wrote:
>> Hi Aleksej,
>>
>> Yes, you are right. They can be handled separately. Thanks!
>>
>> Regards,
>>
>> Michael
>> Sent from my iPhone
>>
>> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov <aleksej.efimov at oracle.com> wrote:
>>
>>> Hi Michael,
>>> As I can see this topic was touched a little here: http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations.  And actually we already have opened bug for this task: https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes.
>>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree?
>>>
>>> Thanks and Best Regards,
>>> Aleksej
>>>
>>> On 11.10.2013 21:41, Michael Fang wrote:
>>>> Hi Aleksej,
>>>>
>>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310...
>>>>
>>>> I think we can file a separate bug to track that issue.
>>>>
>>>> thanks,
>>>>
>>>> -michael
>>>>
>>>> On 13?~10??10?? 09:54 ?U??, Masayoshi Okutsu wrote:
>>>>> Hi Aleksej,
>>>>>
>>>>> Here are my review comments.
>>>>>
>>>>> - The copyright header of the data files shouldn't be removed.
>>>>>
>>>>> - TimeZoneNames.java:
>>>>>
>>>>> - "Middle Europe Time", "MET"}},
>>>>> + "MET", "MET"}},
>>>>>
>>>>> I don't think the long name should be changed.
>>>>>
>>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g.
>>>>>>
>>>>>> The brief list of changes:
>>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes).
>>>>>> 2. a) Updates to long time zone names
>>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>>>>>> c) Removed unused ACT[] array
>>>>>> d) Added "Europe/Busingen" time zone name
>>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>>>>>
>>>>>> The following tests were executed on JDK 8 with fix:
>>>>>> test/java/util/TimeZone
>>>>>> test/java/util/Calendar
>>>>>> test/java/util/Formatter
>>>>>> test/sun/util/calendar
>>>>>> test/java/time
>>>>>>
>>>>>> Testing result: All test passed
>>>>>>
>>>>>> Thanks!
>>>>>> Aleksej
>>>>>>
>>>>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>


From masayoshi.okutsu at oracle.com  Mon Oct 14 21:31:54 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 15 Oct 2013 13:31:54 +0900
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <525BBB02.9060805@oracle.com>
References: <5256ABDD.9060900@oracle.com>
	<5257846F.6020509@oracle.com>	<52583852.3010004@oracle.com>
	<52584F89.3030007@oracle.com>	<ADA0C198-43E5-4389-B5DC-B6578BE9F7D9@oracle.com>
	<525A74B3.6040300@oracle.com> <525BBB02.9060805@oracle.com>
Message-ID: <525CC53A.6020809@oracle.com>

Hi Aleksej and Michael,

TimeZoneNames_de.java:

-        String DARWIN[] = new String[] {"Zentrale Normalzeit (Northern Territory)", "CST",
+        String DARWIN[] = new String[] {"Central Normalzeit (Northern Territory)", "CST",

Is this change correct?

BTW, is there any reason to change lower case to upper case for the 
\uxxxx notation?

Thanks,
Masayoshi

On 10/14/2013 6:36 PM, Aleksej Efimov wrote:
> Hi,
> The second item is dropped - I was informed in a parallel review 
> thread, that I can have one approval from a Reviewer and another 
> approval[s] from members.
> The hg patch was updated and located here: 
> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch 
> <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/8025255_jdk8.patch>
>
> Can I ask for a sponsor help to push this fix?
>
> Thank you and Best Regards,
> Aleksej
>
> On 10/13/2013 02:23 PM, Aleksej Efimov wrote:
>> Michael, Masayoshi,
>>
>> Looks like, we can commit this changes with following items in mind:
>> 1. Generic names in TimeZoneNames_*.java should be added as part of
>> JDK-8025051 resolution.
>> 2. I need another one approval from a JDK 8 reviewer for this one.
>>
>> Anyway, the hg changeset patch can be found here:
>> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch
>>
>> Best Regards,
>> Aleksej
>>
>> On 10/12/2013 12:43 AM, Michael Fang wrote:
>>> Hi Aleksej,
>>>
>>> Yes, you are right. They can be handled separately. Thanks!
>>>
>>> Regards,
>>>
>>> Michael
>>> Sent from my iPhone
>>>
>>> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov<aleksej.efimov at oracle.com>  wrote:
>>>
>>>> Hi Michael,
>>>> As I can see this topic was touched a little here:http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations.  And actually we already have opened bug for this task:https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes.
>>>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree?
>>>>
>>>> Thanks and Best Regards,
>>>> Aleksej
>>>>
>>>> On 11.10.2013 21:41, Michael Fang wrote:
>>>>> Hi Aleksej,
>>>>>
>>>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310...
>>>>>
>>>>> I think we can file a separate bug to track that issue.
>>>>>
>>>>> thanks,
>>>>>
>>>>> -michael
>>>>>
>>>>> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote:
>>>>>> Hi Aleksej,
>>>>>>
>>>>>> Here are my review comments.
>>>>>>
>>>>>> - The copyright header of the data files shouldn't be removed.
>>>>>>
>>>>>> - TimeZoneNames.java:
>>>>>>
>>>>>> - "Middle Europe Time", "MET"}},
>>>>>> + "MET", "MET"}},
>>>>>>
>>>>>> I don't think the long name should be changed.
>>>>>>
>>>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine.
>>>>>>
>>>>>> Thanks,
>>>>>> Masayoshi
>>>>>>
>>>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g.
>>>>>>>
>>>>>>> The brief list of changes:
>>>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes).
>>>>>>> 2. a) Updates to long time zone names
>>>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART)
>>>>>>> c) Removed unused ACT[] array
>>>>>>> d) Added "Europe/Busingen" time zone name
>>>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>>>>>>
>>>>>>> The following tests were executed on JDK 8 with fix:
>>>>>>> test/java/util/TimeZone
>>>>>>> test/java/util/Calendar
>>>>>>> test/java/util/Formatter
>>>>>>> test/sun/util/calendar
>>>>>>> test/java/time
>>>>>>>
>>>>>>> Testing result: All test passed
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Aleksej
>>>>>>>
>>>>>>> [1]http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/  <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
>


From michael.fang at oracle.com  Mon Oct 14 22:19:10 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 14 Oct 2013 22:19:10 -0700
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <525CC53A.6020809@oracle.com>
References: <5256ABDD.9060900@oracle.com>
	<5257846F.6020509@oracle.com>	<52583852.3010004@oracle.com>
	<52584F89.3030007@oracle.com>	<ADA0C198-43E5-4389-B5DC-B6578BE9F7D9@oracle.com>
	<525A74B3.6040300@oracle.com> <525BBB02.9060805@oracle.com>
	<525CC53A.6020809@oracle.com>
Message-ID: <525CD04E.60003@oracle.com>

Hi Masayoshi,

I am not sure if the changes are correct. I need to check with 
translation team for confirmation. There are several other similar cases.

About the upper casing, it's the way Oracle translation team returns 
their translation. Nothing we can do about it. I think it's a way for 
them to know if anyone else has changed the translation without their 
knowledge. Translation changes has to be done on their translation 
memory by them instead of manually editing the resource files. 
Otherwise, the next time they deliver l10n resource files back, the 
manually changes will not be there.

thanks,

-michael

On 13?10?14? 09:31 ??, Masayoshi Okutsu wrote:
> Hi Aleksej and Michael,
>
> TimeZoneNames_de.java:
> -        String DARWIN[] = new String[] {"Zentrale Normalzeit (Northern Territory)", "CST",
> +        String DARWIN[] = new String[] {"Central Normalzeit (Northern Territory)", "CST",
> Is this change correct?
>
> BTW, is there any reason to change lower case to upper case for the 
> \uxxxx notation?
>
> Thanks,
> Masayoshi
>
> On 10/14/2013 6:36 PM, Aleksej Efimov wrote:
>> Hi,
>> The second item is dropped - I was informed in a parallel review 
>> thread, that I can have one approval from a Reviewer and another 
>> approval[s] from members.
>> The hg patch was updated and located here: 
>> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch 
>> <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/8025255_jdk8.patch>
>>
>> Can I ask for a sponsor help to push this fix?
>>
>> Thank you and Best Regards,
>> Aleksej
>>
>> On 10/13/2013 02:23 PM, Aleksej Efimov wrote:
>>> Michael, Masayoshi,
>>>
>>> Looks like, we can commit this changes with following items in mind:
>>> 1. Generic names in TimeZoneNames_*.java should be added as part of
>>> JDK-8025051 resolution.
>>> 2. I need another one approval from a JDK 8 reviewer for this one.
>>>
>>> Anyway, the hg changeset patch can be found here:
>>> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch
>>>
>>> Best Regards,
>>> Aleksej
>>>
>>> On 10/12/2013 12:43 AM, Michael Fang wrote:
>>>> Hi Aleksej,
>>>>
>>>> Yes, you are right. They can be handled separately. Thanks!
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>> Sent from my iPhone
>>>>
>>>> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov<aleksej.efimov at oracle.com>  wrote:
>>>>
>>>>> Hi Michael,
>>>>> As I can see this topic was touched a little here:http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations.  And actually we already have opened bug for this task:https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes.
>>>>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree?
>>>>>
>>>>> Thanks and Best Regards,
>>>>> Aleksej
>>>>>
>>>>> On 11.10.2013 21:41, Michael Fang wrote:
>>>>>> Hi Aleksej,
>>>>>>
>>>>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310...
>>>>>>
>>>>>> I think we can file a separate bug to track that issue.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> -michael
>>>>>>
>>>>>> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote:
>>>>>>> Hi Aleksej,
>>>>>>>
>>>>>>> Here are my review comments.
>>>>>>>
>>>>>>> - The copyright header of the data files shouldn't be removed.
>>>>>>>
>>>>>>> - TimeZoneNames.java:
>>>>>>>
>>>>>>> - "Middle Europe Time", "MET"}},
>>>>>>> + "MET", "MET"}},
>>>>>>>
>>>>>>> I don't think the long name should be changed.
>>>>>>>
>>>>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Masayoshi
>>>>>>>
>>>>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g.
>>>>>>>>
>>>>>>>> The brief list of changes:
>>>>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes).
>>>>>>>> 2. a) Updates to long time zone names
>>>>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST ->  WIB/WITA/WIT/ART)
>>>>>>>> c) Removed unused ACT[] array
>>>>>>>> d) Added "Europe/Busingen" time zone name
>>>>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>>>>>>>
>>>>>>>> The following tests were executed on JDK 8 with fix:
>>>>>>>> test/java/util/TimeZone
>>>>>>>> test/java/util/Calendar
>>>>>>>> test/java/util/Formatter
>>>>>>>> test/sun/util/calendar
>>>>>>>> test/java/time
>>>>>>>>
>>>>>>>> Testing result: All test passed
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Aleksej
>>>>>>>>
>>>>>>>> [1]http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/  <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
>>
>

From michael.fang at oracle.com  Wed Oct 16 07:43:03 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Wed, 16 Oct 2013 07:43:03 -0700
Subject: <i18n dev> RFR: 8025255: (tz) Support tzdata2013g
In-Reply-To: <525CD04E.60003@oracle.com>
References: <5256ABDD.9060900@oracle.com>
	<5257846F.6020509@oracle.com>	<52583852.3010004@oracle.com>
	<52584F89.3030007@oracle.com>	<ADA0C198-43E5-4389-B5DC-B6578BE9F7D9@oracle.com>
	<525A74B3.6040300@oracle.com> <525BBB02.9060805@oracle.com>
	<525CC53A.6020809@oracle.com> <525CD04E.60003@oracle.com>
Message-ID: <525EA5F7.6090507@oracle.com>

Hi Aleksej and Masayoshi,

The translation of the timezone names are correct according to the 
translators. So, the files in your webrev look fine to me.

thanks,

-michael

On 13?10?14? 10:19 ??, Michael Fang wrote:
> Hi Masayoshi,
>
> I am not sure if the changes are correct. I need to check with 
> translation team for confirmation. There are several other similar cases.
>
> About the upper casing, it's the way Oracle translation team returns 
> their translation. Nothing we can do about it. I think it's a way for 
> them to know if anyone else has changed the translation without their 
> knowledge. Translation changes has to be done on their translation 
> memory by them instead of manually editing the resource files. 
> Otherwise, the next time they deliver l10n resource files back, the 
> manually changes will not be there.
>
> thanks,
>
> -michael
>
> On 13?10?14? 09:31 ??, Masayoshi Okutsu wrote:
>> Hi Aleksej and Michael,
>>
>> TimeZoneNames_de.java:
>> -        String DARWIN[] = new String[] {"Zentrale Normalzeit (Northern Territory)", "CST",
>> +        String DARWIN[] = new String[] {"Central Normalzeit (Northern Territory)", "CST",
>> Is this change correct?
>>
>> BTW, is there any reason to change lower case to upper case for the 
>> \uxxxx notation?
>>
>> Thanks,
>> Masayoshi
>>
>> On 10/14/2013 6:36 PM, Aleksej Efimov wrote:
>>> Hi,
>>> The second item is dropped - I was informed in a parallel review 
>>> thread, that I can have one approval from a Reviewer and another 
>>> approval[s] from members.
>>> The hg patch was updated and located here: 
>>> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch 
>>> <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/8025255_jdk8.patch>
>>>
>>> Can I ask for a sponsor help to push this fix?
>>>
>>> Thank you and Best Regards,
>>> Aleksej
>>>
>>> On 10/13/2013 02:23 PM, Aleksej Efimov wrote:
>>>> Michael, Masayoshi,
>>>>
>>>> Looks like, we can commit this changes with following items in mind:
>>>> 1. Generic names in TimeZoneNames_*.java should be added as part of
>>>> JDK-8025051 resolution.
>>>> 2. I need another one approval from a JDK 8 reviewer for this one.
>>>>
>>>> Anyway, the hg changeset patch can be found here:
>>>> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch
>>>>
>>>> Best Regards,
>>>> Aleksej
>>>>
>>>> On 10/12/2013 12:43 AM, Michael Fang wrote:
>>>>> Hi Aleksej,
>>>>>
>>>>> Yes, you are right. They can be handled separately. Thanks!
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael
>>>>> Sent from my iPhone
>>>>>
>>>>> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov<aleksej.efimov at oracle.com>  wrote:
>>>>>
>>>>>> Hi Michael,
>>>>>> As I can see this topic was touched a little here:http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations.  And actually we already have opened bug for this task:https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes.
>>>>>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree?
>>>>>>
>>>>>> Thanks and Best Regards,
>>>>>> Aleksej
>>>>>>
>>>>>> On 11.10.2013 21:41, Michael Fang wrote:
>>>>>>> Hi Aleksej,
>>>>>>>
>>>>>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310...
>>>>>>>
>>>>>>> I think we can file a separate bug to track that issue.
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> -michael
>>>>>>>
>>>>>>> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote:
>>>>>>>> Hi Aleksej,
>>>>>>>>
>>>>>>>> Here are my review comments.
>>>>>>>>
>>>>>>>> - The copyright header of the data files shouldn't be removed.
>>>>>>>>
>>>>>>>> - TimeZoneNames.java:
>>>>>>>>
>>>>>>>> - "Middle Europe Time", "MET"}},
>>>>>>>> + "MET", "MET"}},
>>>>>>>>
>>>>>>>> I don't think the long name should be changed.
>>>>>>>>
>>>>>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Masayoshi
>>>>>>>>
>>>>>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g.
>>>>>>>>>
>>>>>>>>> The brief list of changes:
>>>>>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes).
>>>>>>>>> 2. a) Updates to long time zone names
>>>>>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST ->  WIB/WITA/WIT/ART)
>>>>>>>>> c) Removed unused ACT[] array
>>>>>>>>> d) Added "Europe/Busingen" time zone name
>>>>>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files
>>>>>>>>>
>>>>>>>>> The following tests were executed on JDK 8 with fix:
>>>>>>>>> test/java/util/TimeZone
>>>>>>>>> test/java/util/Calendar
>>>>>>>>> test/java/util/Formatter
>>>>>>>>> test/sun/util/calendar
>>>>>>>>> test/java/time
>>>>>>>>>
>>>>>>>>> Testing result: All test passed
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Aleksej
>>>>>>>>>
>>>>>>>>> [1]http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/  <http://cr.openjdk.java.net/%7Eaefimov/8025255/8/webrev.00/>
>>>
>>

From yuka.kamiya at oracle.com  Wed Oct 16 18:39:00 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Thu, 17 Oct 2013 10:39:00 +0900
Subject: <i18n dev> RFR:  8025703: Update LSR datafile for BCP 47
Message-ID: <525F3FB4.5000305@oracle.com>

Hi,

Please review this fix for JDK 8. This is to update data for locale matching.

http://bugs.sun.com/view_bug.do?bug_id=8025703
http://cr.openjdk.java.net/~peytoia/8025703/webrev.00/

Thanks,
--
Yuka


From masayoshi.okutsu at oracle.com  Wed Oct 16 21:41:15 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 17 Oct 2013 13:41:15 +0900
Subject: <i18n dev> RFR:  8025703: Update LSR datafile for BCP 47
In-Reply-To: <525F3FB4.5000305@oracle.com>
References: <525F3FB4.5000305@oracle.com>
Message-ID: <525F6A6B.7010502@oracle.com>

Looks good to me.

Masayoshi

On 10/17/2013 10:39 AM, Yuka Kamiya wrote:
> Hi,
>
> Please review this fix for JDK 8. This is to update data for locale matching.
>
> http://bugs.sun.com/view_bug.do?bug_id=8025703
> http://cr.openjdk.java.net/~peytoia/8025703/webrev.00/
>
> Thanks,
> --
> Yuka
>


From yuka.kamiya at oracle.com  Wed Oct 16 21:42:00 2013
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Thu, 17 Oct 2013 13:42:00 +0900
Subject: <i18n dev> RFR:  8025703: Update LSR datafile for BCP 47
In-Reply-To: <525F6A6B.7010502@oracle.com>
References: <525F3FB4.5000305@oracle.com> <525F6A6B.7010502@oracle.com>
Message-ID: <525F6A98.405@oracle.com>

Hi Masayoshi,

Thank you!!
--
Yuka

(2013/10/17 13:41), Masayoshi Okutsu wrote:
> Looks good to me.
>
> Masayoshi
>
> On 10/17/2013 10:39 AM, Yuka Kamiya wrote:
>> Hi,
>>
>> Please review this fix for JDK 8. This is to update data for locale matching.
>>
>> http://bugs.sun.com/view_bug.do?bug_id=8025703
>> http://cr.openjdk.java.net/~peytoia/8025703/webrev.00/
>>
>> Thanks,
>> --
>> Yuka
>>


From aleksej.efimov at oracle.com  Thu Oct 17 01:47:00 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 17 Oct 2013 12:47:00 +0400
Subject: <i18n dev> Request for approval for 8025255: (tz) Support
	tzdata2013g
In-Reply-To: <525F8FF2.7020105@oracle.com>
References: <525F0151.3030008@oracle.com> <525F8FF2.7020105@oracle.com>
Message-ID: <525FA404.6050907@oracle.com>

Alan,
Of course, I'll wait for few days.
Also, I'll fix JDK-8026772 - the root cause is mine changes: All time 
zone names translations are based on internal translation file of 
globalization/translation team. I'll ask them to check this file for 
correctness one more time.

Thanks,
Aleksej

On 10/17/2013 11:21 AM, Alan Bateman wrote:
> On 16/10/2013 22:12, Aleksej Efimov wrote:
>> Hi,
>> This is a backport of the following JDK 8 bug [1] to 7u-dev.
> Would it be possible to wait a day or two to see if any issues come 
> from the change pushed to jdk8/tl? There is at least one new test 
> failure in jdk8/tl (see JDK-8026772) that may be caused by this 
> change. It might be just a that a test was missed by the change but I 
> think it would be good to be confident that there aren't any issues 
> before back-porting.
>
> -Alan


From aleksej.efimov at oracle.com  Tue Oct 22 04:13:00 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 22 Oct 2013 15:13:00 +0400
Subject: <i18n dev> RFR: 8026772:
	test/sun/util/resources/TimeZone/Bug6317929.java failing
Message-ID: <52665DBC.5080100@oracle.com>

Hi,
Can I have a review for 8026772 [1] fix.
The webrev link: [2]
The timezone test is failed because of the changed TimeZone names 
introduced in 8025255 [3].
This timezone names were changed according to updated translation 
resource files introduced by 8025215 [4].

The fix changes the hard-coded time zone names for "Australia/Currie" to 
the values specified in 8025215.

Thanks in Advance,
Aleksej

[1] http://bugs.sun.com/view_bug.do?bug_id=8026772
[2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/
[3] http://bugs.sun.com/view_bug.do?bug_id=8025255
[4] http://bugs.sun.com/view_bug.do?bug_id=8025215



From michael.fang at oracle.com  Tue Oct 22 10:40:37 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 22 Oct 2013 10:40:37 -0700
Subject: <i18n dev> [8] Request for review: 6607048: clear extra l10n
 resource files in demo
Message-ID: <5266B895.60609@oracle.com>

Hello,

Please help to review the changes for the following CR:
<https://bugs.openjdk.java.net/browse/JDK-6607048>https://bugs.openjdk.java.net/browse/JDK-6607048

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

Unit testing has been performed by yhuang.

thanks!

-michael

From naoto.sato at oracle.com  Tue Oct 22 11:21:17 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 22 Oct 2013 11:21:17 -0700
Subject: <i18n dev> [8] Request for review: 6607048: clear extra l10n
 resource files in demo
In-Reply-To: <5266B895.60609@oracle.com>
References: <5266B895.60609@oracle.com>
Message-ID: <5266C21D.3010607@oracle.com>

Looks good to me.

Naoto

On 10/22/13 10:40 AM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes for the following CR:
> <https://bugs.openjdk.java.net/browse/JDK-6607048>https://bugs.openjdk.java.net/browse/JDK-6607048
>
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/6607048/webrev.00/
>
> Unit testing has been performed by yhuang.
>
> thanks!
>
> -michael


From michael.fang at oracle.com  Tue Oct 22 11:29:37 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 22 Oct 2013 11:29:37 -0700
Subject: <i18n dev> [8] Request for review: 6607048: clear extra l10n
 resource files in demo
In-Reply-To: <5266C21D.3010607@oracle.com>
References: <5266B895.60609@oracle.com> <5266C21D.3010607@oracle.com>
Message-ID: <5266C411.6050503@oracle.com>

Thanks Naoto for the review.

-michael

On 13?10?22? 11:21 ??, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 10/22/13 10:40 AM, Michael Fang wrote:
>> Hello,
>>
>> Please help to review the changes for the following CR:
>> <https://bugs.openjdk.java.net/browse/JDK-6607048>https://bugs.openjdk.java.net/browse/JDK-6607048 
>>
>>
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/6607048/webrev.00/
>>
>> Unit testing has been performed by yhuang.
>>
>> thanks!
>>
>> -michael
>


From michael.fang at oracle.com  Tue Oct 22 11:33:15 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 22 Oct 2013 11:33:15 -0700
Subject: <i18n dev> [8] Request for review: 8026109: [ja] overtranslation of
 jarsigner in command line output
Message-ID: <5266C4EB.8070903@oracle.com>

Hello,

Please help to review the changes (1 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8026109

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

thanks!

-michael

From naoto.sato at oracle.com  Tue Oct 22 13:59:33 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 22 Oct 2013 13:59:33 -0700
Subject: <i18n dev> [8] Request for review: 8026109: [ja]
 overtranslation of jarsigner in command line output
In-Reply-To: <5266C4EB.8070903@oracle.com>
References: <5266C4EB.8070903@oracle.com>
Message-ID: <5266E735.8020907@oracle.com>

Looks good to me.

Naoto

On 10/22/13 11:33 AM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes (1 line fix) for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8026109
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8026109/
>
> thanks!
>
> -michael


From masayoshi.okutsu at oracle.com  Tue Oct 22 21:29:08 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 23 Oct 2013 13:29:08 +0900
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <52665DBC.5080100@oracle.com>
References: <52665DBC.5080100@oracle.com>
Message-ID: <52675094.6020507@oracle.com>

Hi Michael,

   27  *@summary Test case for tzdata2005m support for 9 locales

What's the purpose of this test? Do we really need to keep this one?

Thanks,
Masayoshi

On 10/22/2013 8:13 PM, Aleksej Efimov wrote:
> Hi,
> Can I have a review for 8026772 [1] fix.
> The webrev link: [2]
> The timezone test is failed because of the changed TimeZone names 
> introduced in 8025255 [3].
> This timezone names were changed according to updated translation 
> resource files introduced by 8025215 [4].
>
> The fix changes the hard-coded time zone names for "Australia/Currie" 
> to the values specified in 8025215.
>
> Thanks in Advance,
> Aleksej
>
> [1] http://bugs.sun.com/view_bug.do?bug_id=8026772
> [2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/
> [3] http://bugs.sun.com/view_bug.do?bug_id=8025255
> [4] http://bugs.sun.com/view_bug.do?bug_id=8025215
>
>


From michael.fang at oracle.com  Wed Oct 23 08:12:49 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Wed, 23 Oct 2013 08:12:49 -0700
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <52675094.6020507@oracle.com>
References: <52665DBC.5080100@oracle.com> <52675094.6020507@oracle.com>
Message-ID: <5267E771.7090805@oracle.com>

Hi Masayoshi,

At that time I was asked to have regression test to validate each 
translation changes.

With our new translation process for TimeZoneNames and new planned 
regression tests from Aleksej for JDK-8025051 
<https://bugs.openjdk.java.net/browse/JDK-8025051>, I believe we can 
remove those unnecessary tests in the future (probably together with 
JDK-8025051 <https://bugs.openjdk.java.net/browse/JDK-8025051>).

For now,  webrev [2] looks fine to take care of the short term 
regression failure.

thanks,

-michael

On 13?10?22? 09:29 ??, Masayoshi Okutsu wrote:
> Hi Michael,
>
>   27  *@summary Test case for tzdata2005m support for 9 locales
>
> What's the purpose of this test? Do we really need to keep this one?
>
> Thanks,
> Masayoshi
>
> On 10/22/2013 8:13 PM, Aleksej Efimov wrote:
>> Hi,
>> Can I have a review for 8026772 [1] fix.
>> The webrev link: [2]
>> The timezone test is failed because of the changed TimeZone names 
>> introduced in 8025255 [3].
>> This timezone names were changed according to updated translation 
>> resource files introduced by 8025215 [4].
>>
>> The fix changes the hard-coded time zone names for "Australia/Currie" 
>> to the values specified in 8025215.
>>
>> Thanks in Advance,
>> Aleksej
>>
>> [1] http://bugs.sun.com/view_bug.do?bug_id=8026772
>> [2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/
>> [3] http://bugs.sun.com/view_bug.do?bug_id=8025255
>> [4] http://bugs.sun.com/view_bug.do?bug_id=8025215
>>
>>
>

From masayoshi.okutsu at oracle.com  Thu Oct 24 01:55:59 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 24 Oct 2013 17:55:59 +0900
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <5267E771.7090805@oracle.com>
References: <52665DBC.5080100@oracle.com> <52675094.6020507@oracle.com>
	<5267E771.7090805@oracle.com>
Message-ID: <5268E09F.8040000@oracle.com>

The test detected the translation changes as regression, but that was 
unnecessary? I prefer to remove this test rather than changing the data.

Thanks,
Masayoshi

On 10/24/2013 12:12 AM, Michael Fang wrote:
> Hi Masayoshi,
>
> At that time I was asked to have regression test to validate each 
> translation changes.
>
> With our new translation process for TimeZoneNames and new planned 
> regression tests from Aleksej for JDK-8025051 
> <https://bugs.openjdk.java.net/browse/JDK-8025051>, I believe we can 
> remove those unnecessary tests in the future (probably together with 
> JDK-8025051 <https://bugs.openjdk.java.net/browse/JDK-8025051>).
>
> For now,  webrev [2] looks fine to take care of the short term 
> regression failure.
>
> thanks,
>
> -michael
>
> On 13?10?22? 09:29 ??, Masayoshi Okutsu wrote:
>> Hi Michael,
>>
>>   27  *@summary Test case for tzdata2005m support for 9 locales
>>
>> What's the purpose of this test? Do we really need to keep this one?
>>
>> Thanks,
>> Masayoshi
>>
>> On 10/22/2013 8:13 PM, Aleksej Efimov wrote:
>>> Hi,
>>> Can I have a review for 8026772 [1] fix.
>>> The webrev link: [2]
>>> The timezone test is failed because of the changed TimeZone names 
>>> introduced in 8025255 [3].
>>> This timezone names were changed according to updated translation 
>>> resource files introduced by 8025215 [4].
>>>
>>> The fix changes the hard-coded time zone names for 
>>> "Australia/Currie" to the values specified in 8025215.
>>>
>>> Thanks in Advance,
>>> Aleksej
>>>
>>> [1] http://bugs.sun.com/view_bug.do?bug_id=8026772
>>> [2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/
>>> [3] http://bugs.sun.com/view_bug.do?bug_id=8025255
>>> [4] http://bugs.sun.com/view_bug.do?bug_id=8025215
>>>
>>>
>>


From aleksej.efimov at oracle.com  Thu Oct 24 02:05:32 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 24 Oct 2013 13:05:32 +0400
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <5268E09F.8040000@oracle.com>
References: <52665DBC.5080100@oracle.com> <52675094.6020507@oracle.com>
	<5267E771.7090805@oracle.com> <5268E09F.8040000@oracle.com>
Message-ID: <5268E2DC.7010109@oracle.com>

Masayoshi,
As Michael said, the time zone names changes is not finalized yet and 
I'll add new regression test as part of 8025051 and will remove this 
one. So, I suggest to keep this test and later remove it. I prefer not 
just remove a workable/questionable test, but add some replacement for it.

Thanks,
Aleksej

On 24.10.2013 12:55, Masayoshi Okutsu wrote:
> The test detected the translation changes as regression, but that was 
> unnecessary? I prefer to remove this test rather than changing the data.
>
> Thanks,
> Masayoshi
>
> On 10/24/2013 12:12 AM, Michael Fang wrote:
>> Hi Masayoshi,
>>
>> At that time I was asked to have regression test to validate each 
>> translation changes.
>>
>> With our new translation process for TimeZoneNames and new planned 
>> regression tests from Aleksej for JDK-8025051 
>> <https://bugs.openjdk.java.net/browse/JDK-8025051>, I believe we can 
>> remove those unnecessary tests in the future (probably together with 
>> JDK-8025051 <https://bugs.openjdk.java.net/browse/JDK-8025051>).
>>
>> For now,  webrev [2] looks fine to take care of the short term 
>> regression failure.
>>
>> thanks,
>>
>> -michael
>>
>> On 13?10?22? 09:29 ??, Masayoshi Okutsu wrote:
>>> Hi Michael,
>>>
>>>   27  *@summary Test case for tzdata2005m support for 9 locales
>>>
>>> What's the purpose of this test? Do we really need to keep this one?
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 10/22/2013 8:13 PM, Aleksej Efimov wrote:
>>>> Hi,
>>>> Can I have a review for 8026772 [1] fix.
>>>> The webrev link: [2]
>>>> The timezone test is failed because of the changed TimeZone names 
>>>> introduced in 8025255 [3].
>>>> This timezone names were changed according to updated translation 
>>>> resource files introduced by 8025215 [4].
>>>>
>>>> The fix changes the hard-coded time zone names for 
>>>> "Australia/Currie" to the values specified in 8025215.
>>>>
>>>> Thanks in Advance,
>>>> Aleksej
>>>>
>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=8026772
>>>> [2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/
>>>> [3] http://bugs.sun.com/view_bug.do?bug_id=8025255
>>>> [4] http://bugs.sun.com/view_bug.do?bug_id=8025215
>>>>
>>>>
>>>
>


From Alan.Bateman at oracle.com  Thu Oct 24 05:00:09 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Oct 2013 13:00:09 +0100
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <5268E2DC.7010109@oracle.com>
References: <52665DBC.5080100@oracle.com> <52675094.6020507@oracle.com>
	<5267E771.7090805@oracle.com> <5268E09F.8040000@oracle.com>
	<5268E2DC.7010109@oracle.com>
Message-ID: <52690BC9.60106@oracle.com>

On 24/10/2013 10:05, Aleksej Efimov wrote:
> Masayoshi,
> As Michael said, the time zone names changes is not finalized yet and 
> I'll add new regression test as part of 8025051 and will remove this 
> one. So, I suggest to keep this test and later remove it. I prefer not 
> just remove a workable/questionable test, but add some replacement for 
> it.
It is possible to exclude the test (by adding it to 
jdk/test/ProblemList.txt) while you resolve this? At it stands then it's 
pointless running it.

-Alan.

From aleksej.efimov at oracle.com  Thu Oct 24 05:08:49 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 24 Oct 2013 16:08:49 +0400
Subject: <i18n dev> Request for approval for 8025255: (tz) Support
	tzdata2013g
In-Reply-To: <525FA404.6050907@oracle.com>
References: <525F0151.3030008@oracle.com> <525F8FF2.7020105@oracle.com>
	<525FA404.6050907@oracle.com>
Message-ID: <52690DD1.20904@oracle.com>

Ok,
The fix for failed time zone names test (JDK-8026772) is under review. 
Currently, there is a discussion about test - should we remove it or 
update, but anyway the time zone names and tzdata will remain untouched. 
So we can proceed with pushing this backport to 7u-dev.

Thanks you,
Aleksej

On 10/17/2013 12:47 PM, Aleksej Efimov wrote:
> Alan,
> Of course, I'll wait for few days.
> Also, I'll fix JDK-8026772 - the root cause is mine changes: All time 
> zone names translations are based on internal translation file of 
> globalization/translation team. I'll ask them to check this file for 
> correctness one more time.
>
> Thanks,
> Aleksej
>
> On 10/17/2013 11:21 AM, Alan Bateman wrote:
>> On 16/10/2013 22:12, Aleksej Efimov wrote:
>>> Hi,
>>> This is a backport of the following JDK 8 bug [1] to 7u-dev.
>> Would it be possible to wait a day or two to see if any issues come 
>> from the change pushed to jdk8/tl? There is at least one new test 
>> failure in jdk8/tl (see JDK-8026772) that may be caused by this 
>> change. It might be just a that a test was missed by the change but I 
>> think it would be good to be confident that there aren't any issues 
>> before back-porting.
>>
>> -Alan
>


From aleksej.efimov at oracle.com  Thu Oct 24 05:27:13 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 24 Oct 2013 16:27:13 +0400
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <52690BC9.60106@oracle.com>
References: <52665DBC.5080100@oracle.com> <52675094.6020507@oracle.com>
	<5267E771.7090805@oracle.com> <5268E09F.8040000@oracle.com>
	<5268E2DC.7010109@oracle.com> <52690BC9.60106@oracle.com>
Message-ID: <52691221.6050706@oracle.com>

Alan,
I have added this test to ProblemList.txt and keep the test update: 
http://cr.openjdk.java.net/~aefimov/8026772/webrev.01/.
I suppose, with such resolution we can safely close this minor bug. And 
we will decide this test destiny in 8025051.

Thanks,
Aleksej

On 10/24/2013 04:00 PM, Alan Bateman wrote:
> On 24/10/2013 10:05, Aleksej Efimov wrote:
>> Masayoshi,
>> As Michael said, the time zone names changes is not finalized yet and 
>> I'll add new regression test as part of 8025051 and will remove this 
>> one. So, I suggest to keep this test and later remove it. I prefer 
>> not just remove a workable/questionable test, but add some 
>> replacement for it.
> It is possible to exclude the test (by adding it to 
> jdk/test/ProblemList.txt) while you resolve this? At it stands then 
> it's pointless running it.
>
> -Alan.


From aleksej.efimov at oracle.com  Thu Oct 24 05:56:21 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 24 Oct 2013 16:56:21 +0400
Subject: <i18n dev> Request for approval for 8025255: (tz) Support
	tzdata2013g
In-Reply-To: <52690DD1.20904@oracle.com>
References: <525F0151.3030008@oracle.com>
	<525F8FF2.7020105@oracle.com>	<525FA404.6050907@oracle.com>
	<52690DD1.20904@oracle.com>
Message-ID: <526918F5.9000403@oracle.com>

The new webrev [1] contains the fixed test (it was also added to 
ProblemsList.txt) and the same tzdata2013g related update.

-Aleksej

[1] http://cr.openjdk.java.net/~aefimov/8025255/7/webrev.01/

On 10/24/2013 04:08 PM, Aleksej Efimov wrote:
> Ok,
> The fix for failed time zone names test (JDK-8026772) is under review. 
> Currently, there is a discussion about test - should we remove it or 
> update, but anyway the time zone names and tzdata will remain 
> untouched. So we can proceed with pushing this backport to 7u-dev.
>
> Thanks you,
> Aleksej
>
> On 10/17/2013 12:47 PM, Aleksej Efimov wrote:
>> Alan,
>> Of course, I'll wait for few days.
>> Also, I'll fix JDK-8026772 - the root cause is mine changes: All time 
>> zone names translations are based on internal translation file of 
>> globalization/translation team. I'll ask them to check this file for 
>> correctness one more time.
>>
>> Thanks,
>> Aleksej
>>
>> On 10/17/2013 11:21 AM, Alan Bateman wrote:
>>> On 16/10/2013 22:12, Aleksej Efimov wrote:
>>>> Hi,
>>>> This is a backport of the following JDK 8 bug [1] to 7u-dev.
>>> Would it be possible to wait a day or two to see if any issues come 
>>> from the change pushed to jdk8/tl? There is at least one new test 
>>> failure in jdk8/tl (see JDK-8026772) that may be caused by this 
>>> change. It might be just a that a test was missed by the change but 
>>> I think it would be good to be confident that there aren't any 
>>> issues before back-porting.
>>>
>>> -Alan
>>
>


From aleksej.efimov at oracle.com  Thu Oct 24 06:32:56 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 24 Oct 2013 17:32:56 +0400
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <52691221.6050706@oracle.com>
References: <52665DBC.5080100@oracle.com>
	<52675094.6020507@oracle.com>	<5267E771.7090805@oracle.com>
	<5268E09F.8040000@oracle.com>	<5268E2DC.7010109@oracle.com>
	<52690BC9.60106@oracle.com> <52691221.6050706@oracle.com>
Message-ID: <52692188.3060103@oracle.com>

Alan, Masayoshi, Michael,

If you agree with the proposed changes then we can proceed with closing 
this bug. Can I ask you to sponsorship this change in such case?
The hg patch located here: 
http://cr.openjdk.java.net/~aefimov/8026772/8026772_jdk8.patch.

Thank you,
Aleksej

On 10/24/2013 04:27 PM, Aleksej Efimov wrote:
> Alan,
> I have added this test to ProblemList.txt and keep the test update: 
> http://cr.openjdk.java.net/~aefimov/8026772/webrev.01/.
> I suppose, with such resolution we can safely close this minor bug. 
> And we will decide this test destiny in 8025051.
>
> Thanks,
> Aleksej
>
> On 10/24/2013 04:00 PM, Alan Bateman wrote:
>> On 24/10/2013 10:05, Aleksej Efimov wrote:
>>> Masayoshi,
>>> As Michael said, the time zone names changes is not finalized yet 
>>> and I'll add new regression test as part of 8025051 and will remove 
>>> this one. So, I suggest to keep this test and later remove it. I 
>>> prefer not just remove a workable/questionable test, but add some 
>>> replacement for it.
>> It is possible to exclude the test (by adding it to 
>> jdk/test/ProblemList.txt) while you resolve this? At it stands then 
>> it's pointless running it.
>>
>> -Alan.
>


From michael.fang at oracle.com  Thu Oct 24 07:47:36 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Thu, 24 Oct 2013 07:47:36 -0700
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <52692188.3060103@oracle.com>
References: <52665DBC.5080100@oracle.com>
	<52675094.6020507@oracle.com>	<5267E771.7090805@oracle.com>
	<5268E09F.8040000@oracle.com>	<5268E2DC.7010109@oracle.com>
	<52690BC9.60106@oracle.com> <52691221.6050706@oracle.com>
	<52692188.3060103@oracle.com>
Message-ID: <52693308.2060205@oracle.com>

Hi Aleksej,

The proposed change is fine for me.

thanks,

-michael

On 13?10?24? 06:32 ??, Aleksej Efimov wrote:
> Alan, Masayoshi, Michael,
>
> If you agree with the proposed changes then we can proceed with 
> closing this bug. Can I ask you to sponsorship this change in such case?
> The hg patch located here: 
> http://cr.openjdk.java.net/~aefimov/8026772/8026772_jdk8.patch.
>
> Thank you,
> Aleksej
>
> On 10/24/2013 04:27 PM, Aleksej Efimov wrote:
>> Alan,
>> I have added this test to ProblemList.txt and keep the test update: 
>> http://cr.openjdk.java.net/~aefimov/8026772/webrev.01/.
>> I suppose, with such resolution we can safely close this minor bug. 
>> And we will decide this test destiny in 8025051.
>>
>> Thanks,
>> Aleksej
>>
>> On 10/24/2013 04:00 PM, Alan Bateman wrote:
>>> On 24/10/2013 10:05, Aleksej Efimov wrote:
>>>> Masayoshi,
>>>> As Michael said, the time zone names changes is not finalized yet 
>>>> and I'll add new regression test as part of 8025051 and will remove 
>>>> this one. So, I suggest to keep this test and later remove it. I 
>>>> prefer not just remove a workable/questionable test, but add some 
>>>> replacement for it.
>>> It is possible to exclude the test (by adding it to 
>>> jdk/test/ProblemList.txt) while you resolve this? At it stands then 
>>> it's pointless running it.
>>>
>>> -Alan.
>>
>

From sean.coffey at oracle.com  Thu Oct 24 07:59:46 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 24 Oct 2013 15:59:46 +0100
Subject: <i18n dev> Request for approval for 8025255: (tz) Support
	tzdata2013g
In-Reply-To: <526918F5.9000403@oracle.com>
References: <525F0151.3030008@oracle.com>	<525F8FF2.7020105@oracle.com>	<525FA404.6050907@oracle.com>	<52690DD1.20904@oracle.com>
	<526918F5.9000403@oracle.com>
Message-ID: <526935E2.5020700@oracle.com>

Good to put the test on ProblemList for short term Aleksej. Approved for 
7u-dev.

For records, I'm pasting bug ID and jdk8 changeset here again.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8025255
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60e3cdbe8cdf

regards,
Sean.

On 24/10/2013 13:56, Aleksej Efimov wrote:
> The new webrev [1] contains the fixed test (it was also added to 
> ProblemsList.txt) and the same tzdata2013g related update.
>
> -Aleksej
>
> [1] http://cr.openjdk.java.net/~aefimov/8025255/7/webrev.01/
>
> On 10/24/2013 04:08 PM, Aleksej Efimov wrote:
>> Ok,
>> The fix for failed time zone names test (JDK-8026772) is under 
>> review. Currently, there is a discussion about test - should we 
>> remove it or update, but anyway the time zone names and tzdata will 
>> remain untouched. So we can proceed with pushing this backport to 
>> 7u-dev.
>>
>> Thanks you,
>> Aleksej
>>
>> On 10/17/2013 12:47 PM, Aleksej Efimov wrote:
>>> Alan,
>>> Of course, I'll wait for few days.
>>> Also, I'll fix JDK-8026772 - the root cause is mine changes: All 
>>> time zone names translations are based on internal translation file 
>>> of globalization/translation team. I'll ask them to check this file 
>>> for correctness one more time.
>>>
>>> Thanks,
>>> Aleksej
>>>
>>> On 10/17/2013 11:21 AM, Alan Bateman wrote:
>>>> On 16/10/2013 22:12, Aleksej Efimov wrote:
>>>>> Hi,
>>>>> This is a backport of the following JDK 8 bug [1] to 7u-dev.
>>>> Would it be possible to wait a day or two to see if any issues come 
>>>> from the change pushed to jdk8/tl? There is at least one new test 
>>>> failure in jdk8/tl (see JDK-8026772) that may be caused by this 
>>>> change. It might be just a that a test was missed by the change but 
>>>> I think it would be good to be confident that there aren't any 
>>>> issues before back-porting.
>>>>
>>>> -Alan
>>>
>>
>


From michael.fang at oracle.com  Thu Oct 24 08:16:46 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Thu, 24 Oct 2013 08:16:46 -0700
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <5268E09F.8040000@oracle.com>
References: <52665DBC.5080100@oracle.com> <52675094.6020507@oracle.com>
	<5267E771.7090805@oracle.com> <5268E09F.8040000@oracle.com>
Message-ID: <526939DE.5010509@oracle.com>

Agreed. It was unnecessary, but it was the practice at that time.

thanks,

-michael

On 13?10?24? 01:55 ??, Masayoshi Okutsu wrote:
> The test detected the translation changes as regression, but that was 
> unnecessary? I prefer to remove this test rather than changing the data.
>
> Thanks,
> Masayoshi
>
> On 10/24/2013 12:12 AM, Michael Fang wrote:
>> Hi Masayoshi,
>>
>> At that time I was asked to have regression test to validate each 
>> translation changes.
>>
>> With our new translation process for TimeZoneNames and new planned 
>> regression tests from Aleksej for JDK-8025051 
>> <https://bugs.openjdk.java.net/browse/JDK-8025051>, I believe we can 
>> remove those unnecessary tests in the future (probably together with 
>> JDK-8025051 <https://bugs.openjdk.java.net/browse/JDK-8025051>).
>>
>> For now,  webrev [2] looks fine to take care of the short term 
>> regression failure.
>>
>> thanks,
>>
>> -michael
>>
>> On 13?10?22? 09:29 ??, Masayoshi Okutsu wrote:
>>> Hi Michael,
>>>
>>>   27  *@summary Test case for tzdata2005m support for 9 locales
>>>
>>> What's the purpose of this test? Do we really need to keep this one?
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 10/22/2013 8:13 PM, Aleksej Efimov wrote:
>>>> Hi,
>>>> Can I have a review for 8026772 [1] fix.
>>>> The webrev link: [2]
>>>> The timezone test is failed because of the changed TimeZone names 
>>>> introduced in 8025255 [3].
>>>> This timezone names were changed according to updated translation 
>>>> resource files introduced by 8025215 [4].
>>>>
>>>> The fix changes the hard-coded time zone names for 
>>>> "Australia/Currie" to the values specified in 8025215.
>>>>
>>>> Thanks in Advance,
>>>> Aleksej
>>>>
>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=8026772
>>>> [2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/
>>>> [3] http://bugs.sun.com/view_bug.do?bug_id=8025255
>>>> [4] http://bugs.sun.com/view_bug.do?bug_id=8025215
>>>>
>>>>
>>>
>

From masayoshi.okutsu at oracle.com  Mon Oct 28 16:51:59 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 29 Oct 2013 08:51:59 +0900
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <52693308.2060205@oracle.com>
References: <52665DBC.5080100@oracle.com>
	<52675094.6020507@oracle.com>	<5267E771.7090805@oracle.com>
	<5268E09F.8040000@oracle.com>	<5268E2DC.7010109@oracle.com>
	<52690BC9.60106@oracle.com> <52691221.6050706@oracle.com>
	<52692188.3060103@oracle.com> <52693308.2060205@oracle.com>
Message-ID: <526EF89F.4010400@oracle.com>

Looks good as a temporary solution.

Thanks,
Masayoshi

On 10/24/2013 11:47 PM, Michael Fang wrote:
> Hi Aleksej,
>
> The proposed change is fine for me.
>
> thanks,
>
> -michael
>
> On 13?10?24? 06:32 ??, Aleksej Efimov wrote:
>> Alan, Masayoshi, Michael,
>>
>> If you agree with the proposed changes then we can proceed with 
>> closing this bug. Can I ask you to sponsorship this change in such case?
>> The hg patch located here: 
>> http://cr.openjdk.java.net/~aefimov/8026772/8026772_jdk8.patch.
>>
>> Thank you,
>> Aleksej
>>
>> On 10/24/2013 04:27 PM, Aleksej Efimov wrote:
>>> Alan,
>>> I have added this test to ProblemList.txt and keep the test update: 
>>> http://cr.openjdk.java.net/~aefimov/8026772/webrev.01/.
>>> I suppose, with such resolution we can safely close this minor bug. 
>>> And we will decide this test destiny in 8025051.
>>>
>>> Thanks,
>>> Aleksej
>>>
>>> On 10/24/2013 04:00 PM, Alan Bateman wrote:
>>>> On 24/10/2013 10:05, Aleksej Efimov wrote:
>>>>> Masayoshi,
>>>>> As Michael said, the time zone names changes is not finalized yet 
>>>>> and I'll add new regression test as part of 8025051 and will 
>>>>> remove this one. So, I suggest to keep this test and later remove 
>>>>> it. I prefer not just remove a workable/questionable test, but add 
>>>>> some replacement for it.
>>>> It is possible to exclude the test (by adding it to 
>>>> jdk/test/ProblemList.txt) while you resolve this? At it stands then 
>>>> it's pointless running it.
>>>>
>>>> -Alan.
>>>
>>


From michael.fang at oracle.com  Mon Oct 28 22:02:53 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 28 Oct 2013 22:02:53 -0700
Subject: <i18n dev> [8] Request for review: 8008437: [sv] over-translation
 in java command line outputs
Message-ID: <526F417D.6040303@oracle.com>

Hello,

Please help to review the changes (1 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8008437 
<https://bugs.openjdk.java.net/browse/JDK-8008437>

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8008437/ 
<http://cr.openjdk.java.net/%7Emfang/8008437/>

The only outstanding issue in this bug is for Swedish. The issue was 
translation of "files" was missing at the end of the Usage text.
usage pattern:
      en: Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] 
[entry-point] [-C dir] files ...
      sv: Syntax: jar {ctxui}[vfm0Me] [jar fil] [manifestfil] 
[startpunkt] [-C-katalog] ...

thanks!

-michael

From michael.fang at oracle.com  Mon Oct 28 22:05:55 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 28 Oct 2013 22:05:55 -0700
Subject: <i18n dev> [8] Request for review: 8026108: [it, ja,
 zh_CN] wrong translation in jar example.
Message-ID: <526F4233.6050505@oracle.com>

Hello,

Please help to review the changes (3 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8026108

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8026108/ 
<http://cr.openjdk.java.net/%7Emfang/8026108/>

The issue was about missing a dot (or translated the dot) at the end of 
example 2.

thanks!

-michael

From michael.fang at oracle.com  Mon Oct 28 22:25:05 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 28 Oct 2013 22:25:05 -0700
Subject: <i18n dev> [8] Request for review: 8026115: [zh_CN] inproper
 translation in output of jarsigner command
Message-ID: <526F46B1.5000904@oracle.com>

Hello,

Please help to review the changes (1 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8026115

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

thanks!

-michael

From michael.fang at oracle.com  Mon Oct 28 22:47:38 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 28 Oct 2013 22:47:38 -0700
Subject: <i18n dev> [8] Request for review: 8025646: [pt_BR] overtranslation
 of option in java command line output
Message-ID: <526F4BFA.5060803@oracle.com>

Hello,

Please help to review the changes (1 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8025646

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

The change is in:

FROM -verbose:[classe|gc|jni]\n
TO -verbose:[class|gc|jni]\n

thanks!

-michael

From masayoshi.okutsu at oracle.com  Mon Oct 28 22:53:19 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 29 Oct 2013 14:53:19 +0900
Subject: <i18n dev> [8] Request for review: 8026108: [it, ja,
 zh_CN] wrong translation in jar example.
In-Reply-To: <526F4233.6050505@oracle.com>
References: <526F4233.6050505@oracle.com>
Message-ID: <526F4D4F.5090101@oracle.com>

Looks good to me.

Masayoshi

On 10/29/2013 2:05 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes (3 line fix) for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8026108
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8026108/ 
> <http://cr.openjdk.java.net/%7Emfang/8026108/>
>
> The issue was about missing a dot (or translated the dot) at the end 
> of example 2.
>
> thanks!
>
> -michael


From masayoshi.okutsu at oracle.com  Mon Oct 28 23:03:48 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 29 Oct 2013 15:03:48 +0900
Subject: <i18n dev> [8] Request for review: 8026115: [zh_CN] inproper
 translation in output of jarsigner command
In-Reply-To: <526F46B1.5000904@oracle.com>
References: <526F46B1.5000904@oracle.com>
Message-ID: <526F4FC4.9080507@oracle.com>

Should "[options]" and "alias..." in the second one be translated as well?

          {"Usage.jarsigner.options.jar.file.alias",
-                "??: jarsigner [??] jar ????"},
+                "??: jarsigner [??] jar-file ??"},
          {".jarsigner.verify.options.jar.file.alias.",
                  "       jarsigner -verify [options] jar-file [alias...]"},

In addition, <file> should be translated to <??> in the following? 
Other <file>'s are translated.

   67         {".certchain.file.name.of.alternative.certchain.file",
   68                 "[-certchain <file>]         ?? certchain ?????"},


Thanks,
Masayoshi

On 10/29/2013 2:25 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes (1 line fix) for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8026115
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8026115/
>
> thanks!
>
> -michael


From masayoshi.okutsu at oracle.com  Mon Oct 28 23:49:58 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 29 Oct 2013 15:49:58 +0900
Subject: <i18n dev> [8] Request for review: 8008437: [sv]
 over-translation in java command line outputs
In-Reply-To: <526F417D.6040303@oracle.com>
References: <526F417D.6040303@oracle.com>
Message-ID: <526F5A96.2020806@oracle.com>

Looks good to me.

Masayoshi

On 10/29/2013 2:02 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes (1 line fix) for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8008437 
> <https://bugs.openjdk.java.net/browse/JDK-8008437>
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8008437/ 
> <http://cr.openjdk.java.net/%7Emfang/8008437/>
>
> The only outstanding issue in this bug is for Swedish. The issue was 
> translation of "files" was missing at the end of the Usage text.
> usage pattern:
>      en: Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] 
> [entry-point] [-C dir] files ...
>      sv: Syntax: jar {ctxui}[vfm0Me] [jar fil] [manifestfil] 
> [startpunkt] [-C-katalog] ...
>
> thanks!
>
> -michael


From aleksej.efimov at oracle.com  Tue Oct 29 04:04:07 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 29 Oct 2013 15:04:07 +0400
Subject: <i18n dev> Request for approval for 8025255: (tz) Support
	tzdata2013g
In-Reply-To: <526935E2.5020700@oracle.com>
References: <525F0151.3030008@oracle.com>	<525F8FF2.7020105@oracle.com>	<525FA404.6050907@oracle.com>	<52690DD1.20904@oracle.com>
	<526918F5.9000403@oracle.com> <526935E2.5020700@oracle.com>
Message-ID: <526F9627.70205@oracle.com>

Hi,
Another additional information for records:
The test failure bug related to tzdata2013g update  was approved for 
jdk8 [1]. The changeset [2] contains both fixes for 8026772 and 8025255.


[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022452.html
[2] http://cr.openjdk.java.net/~aefimov/8025255/7/8025255_jdk7.patch 
<http://cr.openjdk.java.net/%7Eaefimov/8025255/7/8025255_jdk7.patch>

On 10/24/2013 06:59 PM, Se?n Coffey wrote:
> Good to put the test on ProblemList for short term Aleksej. Approved 
> for 7u-dev.
>
> For records, I'm pasting bug ID and jdk8 changeset here again.
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8025255
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60e3cdbe8cdf
>
> regards,
> Sean.
>
> On 24/10/2013 13:56, Aleksej Efimov wrote:
>> The new webrev [1] contains the fixed test (it was also added to 
>> ProblemsList.txt) and the same tzdata2013g related update.
>>
>> -Aleksej
>>
>> [1] http://cr.openjdk.java.net/~aefimov/8025255/7/webrev.01/
>>
>> On 10/24/2013 04:08 PM, Aleksej Efimov wrote:
>>> Ok,
>>> The fix for failed time zone names test (JDK-8026772) is under 
>>> review. Currently, there is a discussion about test - should we 
>>> remove it or update, but anyway the time zone names and tzdata will 
>>> remain untouched. So we can proceed with pushing this backport to 
>>> 7u-dev.
>>>
>>> Thanks you,
>>> Aleksej
>>>
>>> On 10/17/2013 12:47 PM, Aleksej Efimov wrote:
>>>> Alan,
>>>> Of course, I'll wait for few days.
>>>> Also, I'll fix JDK-8026772 - the root cause is mine changes: All 
>>>> time zone names translations are based on internal translation file 
>>>> of globalization/translation team. I'll ask them to check this file 
>>>> for correctness one more time.
>>>>
>>>> Thanks,
>>>> Aleksej
>>>>
>>>> On 10/17/2013 11:21 AM, Alan Bateman wrote:
>>>>> On 16/10/2013 22:12, Aleksej Efimov wrote:
>>>>>> Hi,
>>>>>> This is a backport of the following JDK 8 bug [1] to 7u-dev.
>>>>> Would it be possible to wait a day or two to see if any issues 
>>>>> come from the change pushed to jdk8/tl? There is at least one new 
>>>>> test failure in jdk8/tl (see JDK-8026772) that may be caused by 
>>>>> this change. It might be just a that a test was missed by the 
>>>>> change but I think it would be good to be confident that there 
>>>>> aren't any issues before back-porting.
>>>>>
>>>>> -Alan
>>>>
>>>
>>
>


From Alan.Bateman at oracle.com  Tue Oct 29 05:11:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Oct 2013 12:11:37 +0000
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <52692188.3060103@oracle.com>
References: <52665DBC.5080100@oracle.com>
	<52675094.6020507@oracle.com>	<5267E771.7090805@oracle.com>
	<5268E09F.8040000@oracle.com>	<5268E2DC.7010109@oracle.com>
	<52690BC9.60106@oracle.com> <52691221.6050706@oracle.com>
	<52692188.3060103@oracle.com>
Message-ID: <526FA5F9.4070908@oracle.com>

On 24/10/2013 14:32, Aleksej Efimov wrote:
> Alan, Masayoshi, Michael,
>
> If you agree with the proposed changes then we can proceed with 
> closing this bug. Can I ask you to sponsorship this change in such case?
> The hg patch located here: 
> http://cr.openjdk.java.net/~aefimov/8026772/8026772_jdk8.patch.
I thought the options on the table were to either fix the test or delete 
it. If I read this patch correctly then it fixes the test and also 
excludes it (which doesn't make sense).

-Alan

From aleksej.efimov at oracle.com  Tue Oct 29 05:15:30 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 29 Oct 2013 16:15:30 +0400
Subject: <i18n dev> RFR: 8026772:
 test/sun/util/resources/TimeZone/Bug6317929.java failing
In-Reply-To: <526FA5F9.4070908@oracle.com>
References: <52665DBC.5080100@oracle.com>
	<52675094.6020507@oracle.com>	<5267E771.7090805@oracle.com>
	<5268E09F.8040000@oracle.com>	<5268E2DC.7010109@oracle.com>
	<52690BC9.60106@oracle.com> <52691221.6050706@oracle.com>
	<52692188.3060103@oracle.com> <526FA5F9.4070908@oracle.com>
Message-ID: <526FA6E2.9000404@oracle.com>

Alan,
I want to keep this test until I'll came up with new regression test . 
And I might will come up with some idea on this test modifications 
instead of deletion. So thats why I put it to ProblemsList.txt instead 
of deletion - some sort put it on hold with no impact to JDK 8 release 
process. But from another point of view I don't want to keep the failing 
test in repo, even if it's not used for official testing.

Thanks,
Aleksej

On 10/29/2013 04:11 PM, Alan Bateman wrote:
> On 24/10/2013 14:32, Aleksej Efimov wrote:
>> Alan, Masayoshi, Michael,
>>
>> If you agree with the proposed changes then we can proceed with 
>> closing this bug. Can I ask you to sponsorship this change in such case?
>> The hg patch located here: 
>> http://cr.openjdk.java.net/~aefimov/8026772/8026772_jdk8.patch.
> I thought the options on the table were to either fix the test or 
> delete it. If I read this patch correctly then it fixes the test and 
> also excludes it (which doesn't make sense).
>
> -Alan


From sean.coffey at oracle.com  Tue Oct 29 07:34:51 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 29 Oct 2013 14:34:51 +0000
Subject: <i18n dev> Request for approval for 8025255: (tz) Support
	tzdata2013g
In-Reply-To: <526F9627.70205@oracle.com>
References: <525F0151.3030008@oracle.com>	<525F8FF2.7020105@oracle.com>	<525FA404.6050907@oracle.com>	<52690DD1.20904@oracle.com>
	<526918F5.9000403@oracle.com> <526935E2.5020700@oracle.com>
	<526F9627.70205@oracle.com>
Message-ID: <526FC78B.5030900@oracle.com>

Approved for jdk7u-dev.

I can push this changeset for you.

regards,
Sean.

On 29/10/2013 11:04, Aleksej Efimov wrote:
> Hi,
> Another additional information for records:
> The test failure bug related to tzdata2013g update  was approved for 
> jdk8 [1]. The changeset [2] contains both fixes for 8026772 and 8025255.
>
>
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022452.html
> [2] http://cr.openjdk.java.net/~aefimov/8025255/7/8025255_jdk7.patch 
> <http://cr.openjdk.java.net/%7Eaefimov/8025255/7/8025255_jdk7.patch>
>
> On 10/24/2013 06:59 PM, Se?n Coffey wrote:
>> Good to put the test on ProblemList for short term Aleksej. Approved 
>> for 7u-dev.
>>
>> For records, I'm pasting bug ID and jdk8 changeset here again.
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8025255
>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60e3cdbe8cdf
>>
>> regards,
>> Sean.
>>
>> On 24/10/2013 13:56, Aleksej Efimov wrote:
>>> The new webrev [1] contains the fixed test (it was also added to 
>>> ProblemsList.txt) and the same tzdata2013g related update.
>>>
>>> -Aleksej
>>>
>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/7/webrev.01/
>>>
>>> On 10/24/2013 04:08 PM, Aleksej Efimov wrote:
>>>> Ok,
>>>> The fix for failed time zone names test (JDK-8026772) is under 
>>>> review. Currently, there is a discussion about test - should we 
>>>> remove it or update, but anyway the time zone names and tzdata will 
>>>> remain untouched. So we can proceed with pushing this backport to 
>>>> 7u-dev.
>>>>
>>>> Thanks you,
>>>> Aleksej
>>>>
>>>> On 10/17/2013 12:47 PM, Aleksej Efimov wrote:
>>>>> Alan,
>>>>> Of course, I'll wait for few days.
>>>>> Also, I'll fix JDK-8026772 - the root cause is mine changes: All 
>>>>> time zone names translations are based on internal translation 
>>>>> file of globalization/translation team. I'll ask them to check 
>>>>> this file for correctness one more time.
>>>>>
>>>>> Thanks,
>>>>> Aleksej
>>>>>
>>>>> On 10/17/2013 11:21 AM, Alan Bateman wrote:
>>>>>> On 16/10/2013 22:12, Aleksej Efimov wrote:
>>>>>>> Hi,
>>>>>>> This is a backport of the following JDK 8 bug [1] to 7u-dev.
>>>>>> Would it be possible to wait a day or two to see if any issues 
>>>>>> come from the change pushed to jdk8/tl? There is at least one new 
>>>>>> test failure in jdk8/tl (see JDK-8026772) that may be caused by 
>>>>>> this change. It might be just a that a test was missed by the 
>>>>>> change but I think it would be good to be confident that there 
>>>>>> aren't any issues before back-porting.
>>>>>>
>>>>>> -Alan
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Tue Oct 29 09:12:17 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 29 Oct 2013 09:12:17 -0700
Subject: <i18n dev> [8] Request for review: 8025646: [pt_BR]
 overtranslation of option in java command line output
In-Reply-To: <526F4BFA.5060803@oracle.com>
References: <526F4BFA.5060803@oracle.com>
Message-ID: <526FDE61.6050902@oracle.com>

Looks good to me.

Naoto

On 10/28/13, 10:47 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes (1 line fix) for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8025646
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8025646/
>
> The change is in:
>
> FROM -verbose:[classe|gc|jni]\n
> TO -verbose:[class|gc|jni]\n
>
> thanks!
>
> -michael


From michael.fang at oracle.com  Tue Oct 29 11:31:31 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 29 Oct 2013 11:31:31 -0700
Subject: <i18n dev> [8] Request for review: 8026115: [zh_CN] inproper
 translation in output of jarsigner command
In-Reply-To: <526F4FC4.9080507@oracle.com>
References: <526F46B1.5000904@oracle.com> <526F4FC4.9080507@oracle.com>
Message-ID: <526FFF03.5070405@oracle.com>

Thanks Masayoshi for the review. I will work with translator to refix 
this bug.

thanks,

-michael

On 13?10?28? 11:03 ??, Masayoshi Okutsu wrote:
> Should "[options]" and "alias..." in the second one be translated as 
> well?
>
>          {"Usage.jarsigner.options.jar.file.alias",
> -                "??: jarsigner [??] jar ????"},
> +                "??: jarsigner [??] jar-file ??"},
>          {".jarsigner.verify.options.jar.file.alias.",
>                  "       jarsigner -verify [options] jar-file 
> [alias...]"},
>
> In addition, <file> should be translated to <??> in the following? 
> Other <file>'s are translated.
>
>   67         {".certchain.file.name.of.alternative.certchain.file",
>   68                 "[-certchain <file>]         ?? certchain ?? 
> ???"},
>
>
> Thanks,
> Masayoshi
>
> On 10/29/2013 2:25 PM, Michael Fang wrote:
>> Hello,
>>
>> Please help to review the changes (1 line fix) for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-8026115
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8026115/
>>
>> thanks!
>>
>> -michael
>


From francis.andre.kampbell at orange.fr  Tue Oct 29 11:51:10 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Tue, 29 Oct 2013 19:51:10 +0100
Subject: <i18n dev> [jdk8]: exception in test Bug6317929 on a French
	platform.
Message-ID: <5270039E.40407@orange.fr>

Hi

I got this exception running the Bug6317929 test on a French WXP/Cygwin/VS2010 
platform with jdk8 which I modified locally to print the getDispalyName. So I am 
a little bit puzzled... What should be the proper result?


Currie.getDisplayName=Eastern Normalzeit (Neus?dwales)
Exception in thread "main" java.lang.RuntimeException:
de: LONG, non-daylight saving name for Australia/Currie should be "?stliche 
Normalzeit (New South Wales)"
     at Bug6317929.main(Bug6317929.java:137)

Francis

From aleksej.efimov at oracle.com  Tue Oct 29 12:22:40 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 29 Oct 2013 22:22:40 +0300
Subject: <i18n dev> [jdk8]: exception in test Bug6317929 on a French
	platform.
In-Reply-To: <5270039E.40407@orange.fr>
References: <5270039E.40407@orange.fr>
Message-ID: <52700B00.10207@oracle.com>

Hello Francis,

The following test was modified [1] to address a time zone names changes 
in JDK [2]. As I can see, you have an old version of this test. And just 
FYI - this test will be removed in future.

Aleksej

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022452.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021937.html

On 29.10.2013 21:51, Francis ANDRE wrote:
> Hi
>
> I got this exception running the Bug6317929 test on a French 
> WXP/Cygwin/VS2010 platform with jdk8 which I modified locally to print 
> the getDispalyName. So I am a little bit puzzled... What should be the 
> proper result?
>
>
> Currie.getDisplayName=Eastern Normalzeit (Neus?dwales)
> Exception in thread "main" java.lang.RuntimeException:
> de: LONG, non-daylight saving name for Australia/Currie should be 
> "?stliche Normalzeit (New South Wales)"
>     at Bug6317929.main(Bug6317929.java:137)
>
> Francis


From francis.andre.kampbell at orange.fr  Tue Oct 29 12:41:10 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Tue, 29 Oct 2013 20:41:10 +0100
Subject: <i18n dev> [jdk8]: exception in test Bug6317929 on a French
	platform.
In-Reply-To: <52700B00.10207@oracle.com>
References: <5270039E.40407@orange.fr> <52700B00.10207@oracle.com>
Message-ID: <52700F56.10201@orange.fr>

Hi Aleksej

I run this command

FrancisANDRE at idefix /cygdrive/Z/JDK/jdk8/jdk
$ hg incoming
comparing with http://hg.openjdk.java.net/jdk8/jdk8/jdk
searching for changes
no changes found

and no recent changes were found... So, how do I get the latest version?

Francis


Le 29/10/2013 20:22, Aleksej Efimov a ?crit :
> Hello Francis,
>
> The following test was modified [1] to address a time zone names changes in 
> JDK [2]. As I can see, you have an old version of this test. And just FYI - 
> this test will be removed in future.
>
> Aleksej
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022452.html
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021937.html
>
> On 29.10.2013 21:51, Francis ANDRE wrote:
>> Hi
>>
>> I got this exception running the Bug6317929 test on a French 
>> WXP/Cygwin/VS2010 platform with jdk8 which I modified locally to print the 
>> getDispalyName. So I am a little bit puzzled... What should be the proper 
>> result?
>>
>>
>> Currie.getDisplayName=Eastern Normalzeit (Neus?dwales)
>> Exception in thread "main" java.lang.RuntimeException:
>> de: LONG, non-daylight saving name for Australia/Currie should be "?stliche 
>> Normalzeit (New South Wales)"
>>     at Bug6317929.main(Bug6317929.java:137)
>>
>> Francis
>
>


From aleksej.efimov at oracle.com  Tue Oct 29 13:00:01 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 29 Oct 2013 23:00:01 +0300
Subject: <i18n dev> [jdk8]: exception in test Bug6317929 on a French
	platform.
In-Reply-To: <52700F56.10201@orange.fr>
References: <5270039E.40407@orange.fr> <52700B00.10207@oracle.com>
	<52700F56.10201@orange.fr>
Message-ID: <527013C1.2040409@oracle.com>

Francis,
Actually the test is updated in tl forest: 
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d34c5e860d5f
But its still not merged to jdk8 forest. So, you can wait for a merge, 
or you can clone the tl forest and get the updated test.

Aleksej

On 29.10.2013 22:41, Francis ANDRE wrote:
> Hi Aleksej
>
> I run this command
>
> FrancisANDRE at idefix /cygdrive/Z/JDK/jdk8/jdk
> $ hg incoming
> comparing with http://hg.openjdk.java.net/jdk8/jdk8/jdk
> searching for changes
> no changes found
>
> and no recent changes were found... So, how do I get the latest version?
>
> Francis
>
>
> Le 29/10/2013 20:22, Aleksej Efimov a ?crit :
>> Hello Francis,
>>
>> The following test was modified [1] to address a time zone names 
>> changes in JDK [2]. As I can see, you have an old version of this 
>> test. And just FYI - this test will be removed in future.
>>
>> Aleksej
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022452.html
>> [2] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021937.html
>>
>> On 29.10.2013 21:51, Francis ANDRE wrote:
>>> Hi
>>>
>>> I got this exception running the Bug6317929 test on a French 
>>> WXP/Cygwin/VS2010 platform with jdk8 which I modified locally to 
>>> print the getDispalyName. So I am a little bit puzzled... What 
>>> should be the proper result?
>>>
>>>
>>> Currie.getDisplayName=Eastern Normalzeit (Neus?dwales)
>>> Exception in thread "main" java.lang.RuntimeException:
>>> de: LONG, non-daylight saving name for Australia/Currie should be 
>>> "?stliche Normalzeit (New South Wales)"
>>>     at Bug6317929.main(Bug6317929.java:137)
>>>
>>> Francis
>>
>>
>


From michael.fang at oracle.com  Tue Oct 29 14:08:46 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 29 Oct 2013 14:08:46 -0700
Subject: <i18n dev> [8] Request for review: 8008647: [es] minor cosmetic
 issues in translated java command line outputs
Message-ID: <527023DE.7010407@oracle.com>

Hello,

Please help to review the changes (1 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8008647

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

The webrev doesn't show anything. The change is only adding a space on 
usage between "-x" and "extraer" to fix the alignment issue that used to 
look like below:

% env LC_ALL=es.UTF-8 jar

Sintaxis: jar {ctxui}[vfm0Me] [archive-jar] [archive-manifiesto] [punto-entrada] [-C dir] archivos...

Opciones:

     -c  crear nuevo archivo

     -t  crear la tabla de contenido del archivo

     -x extraer el archive mencionado (o todos) del archivo

     -u  actualizar archive existente

     -v  generar salida detallada de los datos de salida est?ndar

     -f  especificar nombre de archive de almacenamiento

     -m  incluir informaci?n de manifiesto del archive de manifiesto especificado

     -e  especificar punto de entrada de la aplicaci?n para la aplicaci?n aut?noma

         que se incluye dentro de un archive jar ejecutable

     -0  s?lo almacenar; no utilizar compresi?n ZIP

     -M  no crear un archive de manifiesto para las entradas

     -i  generar informaci?n de ?ndice para los archives jar especificados

     -C  cambiar al directorio especificado e incluir el archivo siguiente
.....


thanks!

-michael


From naoto.sato at oracle.com  Tue Oct 29 14:18:06 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 29 Oct 2013 14:18:06 -0700
Subject: <i18n dev> [8] Request for review: 8008647: [es] minor cosmetic
 issues in translated java command line outputs
In-Reply-To: <527023DE.7010407@oracle.com>
References: <527023DE.7010407@oracle.com>
Message-ID: <5270260E.10508@oracle.com>

Looks good to me.

Naoto

On 10/29/13, 2:08 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes (1 line fix) for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8008647
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8008647/
>
> The webrev doesn't show anything. The change is only adding a space on
> usage between "-x" and "extraer" to fix the alignment issue that used to
> look like below:
>
> % env LC_ALL=es.UTF-8 jar
>
> Sintaxis: jar {ctxui}[vfm0Me] [archive-jar] [archive-manifiesto]
> [punto-entrada] [-C dir] archivos...
>
> Opciones:
>
>      -c  crear nuevo archivo
>
>      -t  crear la tabla de contenido del archivo
>
>      -x extraer el archive mencionado (o todos) del archivo
>
>      -u  actualizar archive existente
>
>      -v  generar salida detallada de los datos de salida est?ndar
>
>      -f  especificar nombre de archive de almacenamiento
>
>      -m  incluir informaci?n de manifiesto del archive de manifiesto
> especificado
>
>      -e  especificar punto de entrada de la aplicaci?n para la
> aplicaci?n aut?noma
>
>          que se incluye dentro de un archive jar ejecutable
>
>      -0  s?lo almacenar; no utilizar compresi?n ZIP
>
>      -M  no crear un archive de manifiesto para las entradas
>
>      -i  generar informaci?n de ?ndice para los archives jar especificados
>
>      -C  cambiar al directorio especificado e incluir el archivo siguiente
> .....
>
>
> thanks!
>
> -michael
>


From michael.fang at oracle.com  Tue Oct 29 14:32:31 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 29 Oct 2013 14:32:31 -0700
Subject: <i18n dev> [8] Request for review: 8025521: [de] mnemonic conflict
 in FileChooser for GTK Style feel&look
Message-ID: <5270296F.8090201@oracle.com>

Hello,

Please help to review the changes (1 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8025521

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

The fix has been tested in a private build.

thanks,

-michael

From naoto.sato at oracle.com  Tue Oct 29 16:31:21 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 29 Oct 2013 16:31:21 -0700
Subject: <i18n dev> [8] Request for review: 8025521: [de] mnemonic
 conflict in FileChooser for GTK Style feel&look
In-Reply-To: <5270296F.8090201@oracle.com>
References: <5270296F.8090201@oracle.com>
Message-ID: <52704549.9060605@oracle.com>

Looks good to me.

Naoto

On 10/29/13, 2:32 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes (1 line fix) for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8025521
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8025521/
>
> The fix has been tested in a private build.
>
> thanks,
>
> -michael


From michael.fang at oracle.com  Tue Oct 29 23:43:35 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 29 Oct 2013 23:43:35 -0700
Subject: <i18n dev> [8] Request for review: 6192407:  s10_70, ko, s1/dvd,
 minor misspelling under "Select Software Localizations" window
Message-ID: <5270AA97.2060307@oracle.com>

Hello,

Please help to review the changes for the following CR:
https://bugs.openjdk.java.net/browse/JDK-6192407

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

thanks,

-michael

From michael.fang at oracle.com  Tue Oct 29 23:59:59 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 29 Oct 2013 23:59:59 -0700
Subject: <i18n dev> [8] Request for review: 6931564: Incorrect display name
 of Locale for south africa
Message-ID: <5270AE6F.3070608@oracle.com>

Hello,

Please help to review the changes for the following CR:
https://bugs.openjdk.java.net/browse/JDK-6931564

The webrev is available here:
http://cr.openjdk.java.net/~mfang/6931564/
(Please ignore the part for 6192407 which shares the same regression 
test program)

The diff is not very obvious from the webrev. There was an extra space 
at the end of the line and the fix is just to remove the extra space.

% hg diff LocaleNames_sv.properties
diff -r dd0deeb04933 
src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
--- a/src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties 
Mon Oct 14 22:09:15 2013 +0100
+++ b/src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties 
Tue Oct 29 23:16:53 2013 -0700
@@ -1106,7 +1106,7 @@ WS=Samoa
  WS=Samoa
  YE=Jemen
  YT=Mayotte
-ZA=Sydafrika[space]
+ZA=Sydafrika
  ZM=Zambia
  ZW=Zimbabwe

thanks,

-michael

From yong.huang at oracle.com  Wed Oct 30 00:18:29 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Wed, 30 Oct 2013 15:18:29 +0800
Subject: <i18n dev> [8] Request for review: 6192407:  s10_70, ko, s1/dvd,
 minor misspelling under "Select Software Localizations" window
In-Reply-To: <5270AA97.2060307@oracle.com>
References: <5270AA97.2060307@oracle.com>
Message-ID: <5270B2C5.1080101@oracle.com>

It looks good to me.

thanks,
Yong

On 2013/10/30 14:43, Michael Fang wrote:
> Hello,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-6192407
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/6192407/
>
> thanks,
>
> -michael


From yong.huang at oracle.com  Wed Oct 30 00:18:55 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Wed, 30 Oct 2013 15:18:55 +0800
Subject: <i18n dev> [8] Request for review: 6931564: Incorrect display
 name of Locale for south africa
In-Reply-To: <5270AE6F.3070608@oracle.com>
References: <5270AE6F.3070608@oracle.com>
Message-ID: <5270B2DF.5060005@oracle.com>

It looks good to me.

thanks,
Yong

On 2013/10/30 14:59, Michael Fang wrote:
> Hello,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-6931564
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/6931564/
> (Please ignore the part for 6192407 which shares the same regression 
> test program)
>
> The diff is not very obvious from the webrev. There was an extra space 
> at the end of the line and the fix is just to remove the extra space.
>
> % hg diff LocaleNames_sv.properties
> diff -r dd0deeb04933 
> src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
> --- 
> a/src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties 
> Mon Oct 14 22:09:15 2013 +0100
> +++ 
> b/src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties 
> Tue Oct 29 23:16:53 2013 -0700
> @@ -1106,7 +1106,7 @@ WS=Samoa
>  WS=Samoa
>  YE=Jemen
>  YT=Mayotte
> -ZA=Sydafrika[space]
> +ZA=Sydafrika
>  ZM=Zambia
>  ZW=Zimbabwe
>
> thanks,
>
> -michael


From naoto.sato at oracle.com  Wed Oct 30 10:13:32 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 30 Oct 2013 10:13:32 -0700
Subject: <i18n dev> [8] Request for review: 6192407:  s10_70, ko, s1/dvd,
 minor misspelling under "Select Software Localizations" window
In-Reply-To: <5270AA97.2060307@oracle.com>
References: <5270AA97.2060307@oracle.com>
Message-ID: <52713E3C.1030106@oracle.com>

Looks good to me.

Naoto

On 10/29/13 11:43 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-6192407
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/6192407/
>
> thanks,
>
> -michael

From naoto.sato at oracle.com  Wed Oct 30 10:29:01 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 30 Oct 2013 10:29:01 -0700
Subject: <i18n dev> [8] Request for review: 6931564: Incorrect display
 name of Locale for south africa
In-Reply-To: <5270AE6F.3070608@oracle.com>
References: <5270AE6F.3070608@oracle.com>
Message-ID: <527141DD.2020503@oracle.com>

Hi Michael,

I just skimmed through resource files, and found other instances that 
end with spaces. IIRC, build or release team will take care of them with 
some script execution (might be wrong). So first can you check with them 
whether they will do this kind of clean up at the end? If not, can you 
fix not only this instance but all other unnecessary spaces in resource 
files?

Naoto

On 10/29/13 11:59 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-6931564
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/6931564/
> (Please ignore the part for 6192407 which shares the same regression
> test program)
>
> The diff is not very obvious from the webrev. There was an extra space
> at the end of the line and the fix is just to remove the extra space.
>
> % hg diff LocaleNames_sv.properties
> diff -r dd0deeb04933
> src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
> --- a/src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
> Mon Oct 14 22:09:15 2013 +0100
> +++ b/src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
> Tue Oct 29 23:16:53 2013 -0700
> @@ -1106,7 +1106,7 @@ WS=Samoa
> WS=Samoa
> YE=Jemen
> YT=Mayotte
> -ZA=Sydafrika[space]
> +ZA=Sydafrika
> ZM=Zambia
> ZW=Zimbabwe
>
> thanks,
>
> -michael

From michael.fang at oracle.com  Wed Oct 30 10:33:26 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Wed, 30 Oct 2013 10:33:26 -0700
Subject: <i18n dev> [8] Request for review: 6931564: Incorrect display
 name of Locale for south africa
In-Reply-To: <527141DD.2020503@oracle.com>
References: <5270AE6F.3070608@oracle.com> <527141DD.2020503@oracle.com>
Message-ID: <527142E6.3060900@oracle.com>

Hi Naoto,

Thanks for the info. Let me check about it. I will file a separate bug 
for it.

thanks,

-michael

On 13?10?30? 10:29 ??, Naoto Sato wrote:
> Hi Michael,
>
> I just skimmed through resource files, and found other instances that 
> end with spaces. IIRC, build or release team will take care of them 
> with some script execution (might be wrong). So first can you check 
> with them whether they will do this kind of clean up at the end? If 
> not, can you fix not only this instance but all other unnecessary 
> spaces in resource files?
>
> Naoto
>
> On 10/29/13 11:59 PM, Michael Fang wrote:
>> Hello,
>>
>> Please help to review the changes for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-6931564
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/6931564/
>> (Please ignore the part for 6192407 which shares the same regression
>> test program)
>>
>> The diff is not very obvious from the webrev. There was an extra space
>> at the end of the line and the fix is just to remove the extra space.
>>
>> % hg diff LocaleNames_sv.properties
>> diff -r dd0deeb04933
>> src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
>> --- a/src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
>> Mon Oct 14 22:09:15 2013 +0100
>> +++ b/src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
>> Tue Oct 29 23:16:53 2013 -0700
>> @@ -1106,7 +1106,7 @@ WS=Samoa
>> WS=Samoa
>> YE=Jemen
>> YT=Mayotte
>> -ZA=Sydafrika[space]
>> +ZA=Sydafrika
>> ZM=Zambia
>> ZW=Zimbabwe
>>
>> thanks,
>>
>> -michael


From francis.andre.kampbell at orange.fr  Thu Oct 31 10:39:37 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Thu, 31 Oct 2013 18:39:37 +0100
Subject: <i18n dev> [8]: diff patch for jdk test on a non US platform
Message-ID: <527295D9.8050907@orange.fr>

Hi

Following are a list of patch for making the jdk jtreg test suite happy with a 
WXP/Cygwin/VS2010 Franch platform. For most of them, the fix consists in adding 
Locale.setDefault(Locale.US); as the first statement in main.

diff --git a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java 
b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
--- a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
+++ b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
@@ -238,7 +238,7 @@

          public synchronized void notifyLine(String s)
          {
-            if (s != null && s.indexOf("rmid: debugExec") != -1)
+            if (s != null && s.indexOf("rmid : debugExec") != -1)
                  found = s;
          }

diff --git a/test/java/rmi/activation/checkusage/CheckUsage.java 
b/test/java/rmi/activation/checkusage/CheckUsage.java
--- a/test/java/rmi/activation/checkusage/CheckUsage.java
+++ b/test/java/rmi/activation/checkusage/CheckUsage.java
@@ -31,12 +31,20 @@
   */

  import java.io.ByteArrayOutputStream;
+import java.util.HashMap;
+import java.util.Locale;
+import java.util.Map;

  /**
   * Make sure that rmid prints out a correct usage statement when run with an
   * incorrect command line.
   */
  public class CheckUsage {
+    private static final Map<String, String> maps = new HashMap<String, String>();
+    static {
+        maps.put(Locale.ENGLISH.getDisplayLanguage(), "runtime flag");
+        maps.put(Locale.FRENCH.getDisplayLanguage(), "indicateur d'ex?cution");
+    }
      public static void main(String[] args) {
          try {
              ByteArrayOutputStream berr = new ByteArrayOutputStream();
@@ -54,8 +62,9 @@
              String usage = new String(berr.toByteArray());

              System.err.println("rmid usage: " + usage);
-
-            if (usage.indexOf("-J<runtime flag>") < 0) {
+
+            String jflag = "-J<" + 
maps.get(Locale.getDefault().getDisplayLanguage()) + ">";
+            if (usage.indexOf(jflag) < 0) {
                  TestLibrary.bomb("rmid has incorrect usage message");
              } else {
                  System.err.println("test passed");
diff --git a/test/java/util/Formattable/StockName.java 
b/test/java/util/Formattable/StockName.java
--- a/test/java/util/Formattable/StockName.java
+++ b/test/java/util/Formattable/StockName.java
@@ -33,83 +33,90 @@
  import static java.util.FormattableFlags.*;

  public class StockName implements Formattable {
-    private String symbol, companyName, frenchCompanyName;
+    private String symbol, companyName, frenchCompanyName;

-    public StockName(String symbol, String companyName,
-                     String frenchCompanyName)
-    {
-        this.symbol = symbol;
-        this.companyName = companyName;
-        this.frenchCompanyName = frenchCompanyName;
-    }
+    public StockName(String symbol, String companyName, String frenchCompanyName) {
+        this.symbol = symbol;
+        this.companyName = companyName;
+        this.frenchCompanyName = frenchCompanyName;
+    }

-    public void formatTo(Formatter fmt, int f, int width, int precision) {
-        StringBuilder sb = new StringBuilder();
+    public void formatTo(Formatter fmt, int f, int width, int precision) {
+        StringBuilder sb = new StringBuilder();

-        // decide form of name
-        String name = companyName;
-        if (fmt.locale().equals(Locale.FRANCE))
-            name = frenchCompanyName;
-        boolean alternate = (f & ALTERNATE) == ALTERNATE;
-        boolean usesymbol = alternate || (precision != -1 && precision < 10);
-        String out = (usesymbol ? symbol : name);
+        // decide form of name
+        String name = companyName;
+        if (fmt.locale().equals(Locale.FRANCE))
+            name = frenchCompanyName;
+        boolean alternate = (f & ALTERNATE) == ALTERNATE;
+        boolean usesymbol = alternate || (precision != -1 && precision < 10);
+        String out = (usesymbol ? symbol : name);

-        // apply precision
-        if (precision == -1 || out.length() < precision) {
-            // write it all
-            sb.append(out);
-        } else {
-            sb.append(out.substring(0, precision - 1)).append('*');
-        }
+        // apply precision
+        if (precision == -1 || out.length() < precision) {
+            // write it all
+            sb.append(out);
+        } else {
+            sb.append(out.substring(0, precision - 1)).append('*');
+        }

-        // apply width and justification
-        int len = sb.length();
-        if (len < width)
-            for (int i = 0; i < width - len; i++)
-                if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY)
-                    sb.append(' ');
-                else
-                    sb.insert(0, ' ');
+        // apply width and justification
+        int len = sb.length();
+        if (len < width)
+            for (int i = 0; i < width - len; i++)
+                if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY)
+                    sb.append(' ');
+                else
+                    sb.insert(0, ' ');

-        fmt.format(sb.toString());
-    }
+        fmt.format(sb.toString());
+    }

-    public String toString() {
-        return String.format("%s - %s", symbol, companyName);
-    }
+    public String toString() {
+        return String.format("%s - %s", symbol, companyName);
+    }

-    public static void main(String [] args) {
-        StockName sn = new StockName("HUGE", "Huge Fruit, Inc.",
-                                     "Fruit Titanesque, Inc.");
-        CharBuffer cb = CharBuffer.allocate(128);
-        Formatter fmt = new Formatter(cb);
+    public static void main(String[] args) {
+        StockName sn = new StockName("HUGE", "Huge Fruit, Inc.",
+                "Fruit Titanesque, Inc.");
+        CharBuffer cb = CharBuffer.allocate(128);
+        Formatter fmt = new Formatter(cb);

-        fmt.format("%s", sn);            //   -> "Huge Fruit, Inc."
-        test(cb, "Huge Fruit, Inc.");
+        if (fmt.locale().equals(Locale.FRANCE)) {
+            fmt.format("%s", sn); // -> "Fruit Titanesque, Inc."
+            test(cb, "Fruit Titanesque, Inc.");
+        } else {
+            fmt.format("%s", sn); // -> "Huge Fruit, Inc."
+            test(cb, "Huge Fruit, Inc.");
+        }
+        fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc."
+        test(cb, "HUGE - Huge Fruit, Inc.");

-        fmt.format("%s", sn.toString()); //   -> "HUGE - Huge Fruit, Inc."
-        test(cb, "HUGE - Huge Fruit, Inc.");
+        fmt.format("%#s", sn); // -> "HUGE"
+        test(cb, "HUGE");

-        fmt.format("%#s", sn);           //   -> "HUGE"
-        test(cb, "HUGE");
+        fmt.format("%-10.8s", sn); // -> "HUGE      "
+        test(cb, "HUGE      ");

-        fmt.format("%-10.8s", sn);       //   -> "HUGE      "
-        test(cb, "HUGE      ");
+        if (fmt.locale().equals(Locale.FRANCE)) {
+            fmt.format("%.12s", sn); // -> "Fruit Titan*"
+            test(cb, "Fruit Titan*");
+        } else {
+            fmt.format("%.12s", sn); // -> "Huge Fruit,*"
+            test(cb, "Huge Fruit,*");
+        }

-        fmt.format("%.12s", sn);         //   -> "Huge Fruit,*"
-        test(cb, "Huge Fruit,*");
+        fmt.format(Locale.FRANCE, "%25s", sn);
+        // -> "   Fruit Titanesque, Inc."
+        test(cb, "   Fruit Titanesque, Inc.");
+    }

-        fmt.format(Locale.FRANCE, "%25s", sn);
-                                         //   -> "   Fruit Titanesque, Inc."
-        test(cb, "   Fruit Titanesque, Inc.");
-    }
-
-    private static void test(CharBuffer cb, String exp) {
-        cb.limit(cb.position());
-        cb.rewind();
-        if (!cb.toString().equals(exp))
-            throw new RuntimeException("expect: '" + exp + "'; got: '"
-                                       + cb.toString() + "'");
-        cb.clear();
-    }
+    private static void test(CharBuffer cb, String exp) {
+        cb.limit(cb.position());
+        cb.rewind();
+        if (!cb.toString().equals(exp))
+            throw new RuntimeException("expect: '" + exp + "'; got: '"
+                    + cb.toString() + "'");
+        cb.clear();
+    }
  }
diff --git a/test/java/util/ResourceBundle/ResourceBundleTest.java 
b/test/java/util/ResourceBundle/ResourceBundleTest.java
--- a/test/java/util/ResourceBundle/ResourceBundleTest.java
+++ b/test/java/util/ResourceBundle/ResourceBundleTest.java
@@ -67,6 +67,7 @@

  public class ResourceBundleTest extends RBTestFmwk {
      public static void main(String[] args) throws Exception {
+        Locale.setDefault(Locale.US);
          new ResourceBundleTest().run(args);
      }

diff --git 
a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java 
b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
--- a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
+++ b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
@@ -45,6 +45,7 @@
      }

      public static void main(String... args) throws Exception {
+        Locale.setDefault(Locale.US);

          Locale defaultLocale = Locale.getDefault();
          System.out.println("Default locale is: " + defaultLocale);
diff --git a/test/java/util/logging/LocalizedLevelName.java 
b/test/java/util/logging/LocalizedLevelName.java
--- a/test/java/util/logging/LocalizedLevelName.java
+++ b/test/java/util/logging/LocalizedLevelName.java
@@ -49,6 +49,7 @@
      };

      public static void main(String args[]) throws Exception {
+        Locale.setDefault(Locale.US);
          Locale defaultLocale = Locale.getDefault();
          for (int i=0; i<namesMap.length; i += 4) {
              final String key = (String) namesMap[i];
diff --git a/test/java/util/logging/SimpleFormatterFormat.java 
b/test/java/util/logging/SimpleFormatterFormat.java
--- a/test/java/util/logging/SimpleFormatterFormat.java
+++ b/test/java/util/logging/SimpleFormatterFormat.java
@@ -30,6 +30,7 @@
   */

  import java.io.*;
+import java.util.Locale;
  import java.util.logging.*;
  import java.util.regex.*;

@@ -38,7 +39,8 @@
      private static final String origFormat = System.getProperty(key);
      private static final PrintStream err = System.err;
      public static void main(String[] args) throws Exception {
-        try {
+       Locale.setDefault(Locale.US);
+       try {
              File dir = new File(System.getProperty("user.dir", "."));
              File log = new File(dir, "simpleformat.txt");
              java.nio.file.Files.deleteIfExists(log.toPath());
diff --git a/test/sun/util/logging/SourceClassName.java 
b/test/sun/util/logging/SourceClassName.java
--- a/test/sun/util/logging/SourceClassName.java
+++ b/test/sun/util/logging/SourceClassName.java
@@ -31,12 +31,14 @@
   * @run main/othervm SourceClassName
   */

+import java.util.Locale;
  import java.util.logging.*;
  import java.io.*;
  import sun.util.logging.PlatformLogger;

  public class SourceClassName {
      public static void main(String[] args) throws Exception {
+        Locale.setDefault(Locale.US);
          File dir = new File(System.getProperty("user.dir", "."));
          File log = new File(dir, "testlog.txt");
          PrintStream logps = new PrintStream(log);


From stuart.marks at oracle.com  Thu Oct 31 14:27:15 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 31 Oct 2013 14:27:15 -0700
Subject: <i18n dev> [8]: diff patch for jdk test on a non US platform
In-Reply-To: <52729A53.1010201@oracle.com>
References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com>
Message-ID: <5272CB33.8090501@oracle.com>

Hi Francis,

Alan Bateman directed me to this patch since it includes changes to the RMI 
tests, which I maintain. I have a few comments on the changes to these tests.

> From: 	Francis ANDRE <francis.andre.kampbell at orange.fr>
>
> Following are a list of patch for making the jdk jtreg test suite happy with a
> WXP/Cygwin/VS2010 Franch platform. For most of them, the fix consists in adding
> Locale.setDefault(Locale.US); as the first statement in main.
>
> diff --git a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
> b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
> --- a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
> +++ b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
> @@ -238,7 +238,7 @@
>
>           public synchronized void notifyLine(String s)
>           {
> -            if (s != null && s.indexOf("rmid: debugExec") != -1)
> +            if (s != null && s.indexOf("rmid : debugExec") != -1)
>                   found = s;
>           }
>

This is somewhat odd. This section of the test is capturing the output of rmid 
and is scanning it for a particular string. Why would adding a space be 
necessary? It turns out that the debugExec lines emitted by rmid are localized:


$ cd jdk/src/share/classes/sun/rmi/server/resources
$ grep rmid.exec.command *_*.properties
rmid_de.properties:rmid.exec.command=rmid: debugExec: "{0}" wird ausgef\u00FChrt
rmid_es.properties:rmid.exec.command=rmid: debugExec: en ejecuci\u00F3n "{0}"
rmid_fr.properties:rmid.exec.command=rmid : debugExec : ex\u00E9cution de "{0}"
rmid_it.properties:rmid.exec.command=rmid: debugExec: esecuzione di "{0}" in corso
rmid_ja.properties:rmid.exec.command=rmid: debugExec: "{0}"\u3092\u5B9F\u884C\u4E2D
rmid_ko.properties:rmid.exec.command=rmid: debugExec: "{0}" \uC2E4\uD589 \uC911
rmid_pt_BR.properties:rmid.exec.command=rmid: debugExec: executando "{0}"
rmid_sv.properties:rmid.exec.command=rmid: debugExec: k\u00F6r "{0}"
rmid_zh_CN.properties:rmid.exec.command=rmid: debugExec: 
\u6B63\u5728\u8FD0\u884C "{0}"
rmid_zh_TW.properties:rmid.exec.command=rmid: debugExec: \u57F7\u884C "{0}"
$ grep -B 0 -A 1 rmid.exec.command rmid.properties
rmid.exec.command=\
	rmid: debugExec: running "{0}"


All locales except the French have no space between "rmid" and the trailing 
colon (":"). It appears that having the space before the colon is proper French 
usage (at least, the other French localizations all appear similar). But adding 
the space to the search string will fix the French locale but will break all the 
other locales.

Forcing the test to run in the US locale seems preferable to adding logic to 
deal with different localizations. Since these tests fork JVMs in subprocesses, 
it's probably necessary to do something special to make sure the sub-JVMs are in 
the US locale. This probably involves setting an environment variable or a 
system property. I'm sure others on this list can provide advice.


> diff --git a/test/java/rmi/activation/checkusage/CheckUsage.java
> b/test/java/rmi/activation/checkusage/CheckUsage.java
> --- a/test/java/rmi/activation/checkusage/CheckUsage.java
> +++ b/test/java/rmi/activation/checkusage/CheckUsage.java
> @@ -31,12 +31,20 @@
>    */
>
>   import java.io.ByteArrayOutputStream;
> +import java.util.HashMap;
> +import java.util.Locale;
> +import java.util.Map;
>
>   /**
>    * Make sure that rmid prints out a correct usage statement when run with an
>    * incorrect command line.
>    */
>   public class CheckUsage {
> +    private static final Map<String, String> maps = new HashMap<String, String>();
> +    static {
> +        maps.put(Locale.ENGLISH.getDisplayLanguage(), "runtime flag");
> +        maps.put(Locale.FRENCH.getDisplayLanguage(), "indicateur d'ex?cution");
> +    }
>       public static void main(String[] args) {
>           try {
>               ByteArrayOutputStream berr = new ByteArrayOutputStream();
> @@ -54,8 +62,9 @@
>               String usage = new String(berr.toByteArray());
>
>               System.err.println("rmid usage: " + usage);
> -
> -            if (usage.indexOf("-J<runtime flag>") < 0) {
> +
> +            String jflag = "-J<" +
> maps.get(Locale.getDefault().getDisplayLanguage()) + ">";
> +            if (usage.indexOf(jflag) < 0) {
>                   TestLibrary.bomb("rmid has incorrect usage message");
>               } else {
>                   System.err.println("test passed");


This change looks like the start of a map that includes localized usage messages 
from various locales. If we were to expand this to other locales, eventually 
we'd end up duplicating all the localized usage messages into the test code. 
That seems pretty fragile.

As above, this is capturing the output of a subprocess, so it would seem better 
if the subprocess were forced into the US locale.

(In fact, this is kind of a stupid test anyway; all it does is make sure that a 
usage message gets emitted if an erroneous command-line option is provided. I've 
been thinking of removing it. It's certainly not worth adding extra logic to 
handle multiple locales.)

--

Do we even support running the test suite in different locales? We test on 
several platforms as it is; I don't think we'll want to have separate test runs 
for all eleven (or however many) different localizations.

I can see adding code (or test configuration properties or environment 
variables) to ensure that tests are run in the US locale, unless this is 
specifically overridden by the test. It doesn't seem appropriate to add 
locale-specific logic or data structures to the tests, though.

s'marks


> diff --git a/test/java/util/Formattable/StockName.java
> b/test/java/util/Formattable/StockName.java
> --- a/test/java/util/Formattable/StockName.java
> +++ b/test/java/util/Formattable/StockName.java
> @@ -33,83 +33,90 @@
>   import static java.util.FormattableFlags.*;
>
>   public class StockName implements Formattable {
> -    private String symbol, companyName, frenchCompanyName;
> +    private String symbol, companyName, frenchCompanyName;
>
> -    public StockName(String symbol, String companyName,
> -                     String frenchCompanyName)
> -    {
> -        this.symbol = symbol;
> -        this.companyName = companyName;
> -        this.frenchCompanyName = frenchCompanyName;
> -    }
> +    public StockName(String symbol, String companyName, String frenchCompanyName) {
> +        this.symbol = symbol;
> +        this.companyName = companyName;
> +        this.frenchCompanyName = frenchCompanyName;
> +    }
>
> -    public void formatTo(Formatter fmt, int f, int width, int precision){
> -        StringBuilder sb = new StringBuilder();
> +    public void formatTo(Formatter fmt, int f, int width, int precision){
> +        StringBuilder sb = new StringBuilder();
>
> -        // decide form of name
> -        String name = companyName;
> -        if (fmt.locale().equals(Locale.FRANCE))
> -            name = frenchCompanyName;
> -        boolean alternate = (f & ALTERNATE) == ALTERNATE;
> -        boolean usesymbol = alternate || (precision != -1 && precision < 10);
> -        String out = (usesymbol ? symbol : name);
> +        // decide form of name
> +        String name = companyName;
> +        if (fmt.locale().equals(Locale.FRANCE))
> +            name = frenchCompanyName;
> +        boolean alternate = (f & ALTERNATE) == ALTERNATE;
> +        boolean usesymbol = alternate || (precision != -1 && precision < 10);
> +        String out = (usesymbol ? symbol : name);
>
> -        // apply precision
> -        if (precision == -1 || out.length() < precision) {
> -            // write it all
> -            sb.append(out);
> -        } else {
> -            sb.append(out.substring(0, precision - 1)).append('*');
> -        }
> +        // apply precision
> +        if (precision == -1 || out.length() < precision) {
> +            // write it all
> +            sb.append(out);
> +        } else {
> +            sb.append(out.substring(0, precision - 1)).append('*');
> +        }
>
> -        // apply width and justification
> -        int len = sb.length();
> -        if (len < width)
> -            for (int i = 0; i < width - len; i++)
> -                if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY)
> -                    sb.append(' ');
> -                else
> -                    sb.insert(0, ' ');
> +        // apply width and justification
> +        int len = sb.length();
> +        if (len < width)
> +            for (int i = 0; i < width - len; i++)
> +                if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY)
> +                    sb.append(' ');
> +                else
> +                    sb.insert(0, ' ');
>
> -        fmt.format(sb.toString());
> -    }
> +        fmt.format(sb.toString());
> +    }
>
> -    public String toString() {
> -        return String.format("%s - %s", symbol, companyName);
> -    }
> +    public String toString() {
> +        return String.format("%s - %s", symbol, companyName);
> +    }
>
> -    public static void main(String [] args) {
> -        StockName sn = new StockName("HUGE", "Huge Fruit, Inc.",
> -                                     "Fruit Titanesque, Inc.");
> -        CharBuffer cb = CharBuffer.allocate(128);
> -        Formatter fmt = new Formatter(cb);
> +    public static void main(String[] args) {
> +        StockName sn = new StockName("HUGE", "Huge Fruit, Inc.",
> +                "Fruit Titanesque, Inc.");
> +        CharBuffer cb = CharBuffer.allocate(128);
> +        Formatter fmt = new Formatter(cb);
>
> -        fmt.format("%s", sn);            //   -> "Huge Fruit, Inc."
> -        test(cb, "Huge Fruit, Inc.");
> +        if (fmt.locale().equals(Locale.FRANCE)) {
> +            fmt.format("%s", sn); // -> "Fruit Titanesque, Inc."
> +            test(cb, "Fruit Titanesque, Inc.");
> +        } else {
> +            fmt.format("%s", sn); // -> "Huge Fruit, Inc."
> +            test(cb, "Huge Fruit, Inc.");
> +        }
> +        fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc."
> +        test(cb, "HUGE - Huge Fruit, Inc.");
>
> -        fmt.format("%s", sn.toString()); //   -> "HUGE - Huge Fruit, Inc."
> -        test(cb, "HUGE - Huge Fruit, Inc.");
> +        fmt.format("%#s", sn); // -> "HUGE"
> +        test(cb, "HUGE");
>
> -        fmt.format("%#s", sn);           //   -> "HUGE"
> -        test(cb, "HUGE");
> +        fmt.format("%-10.8s", sn); // -> "HUGE      "
> +        test(cb, "HUGE      ");
>
> -        fmt.format("%-10.8s", sn);       //   -> "HUGE      "
> -        test(cb, "HUGE      ");
> +        if (fmt.locale().equals(Locale.FRANCE)) {
> +            fmt.format("%.12s", sn); // -> "Fruit Titan*"
> +            test(cb, "Fruit Titan*");
> +        } else {
> +            fmt.format("%.12s", sn); // -> "Huge Fruit,*"
> +            test(cb, "Huge Fruit,*");
> +        }
>
> -        fmt.format("%.12s", sn);         //   -> "Huge Fruit,*"
> -        test(cb, "Huge Fruit,*");
> +        fmt.format(Locale.FRANCE, "%25s", sn);
> +        // -> "   Fruit Titanesque, Inc."
> +        test(cb, "   Fruit Titanesque, Inc.");
> +    }
>
> -        fmt.format(Locale.FRANCE, "%25s", sn);
> -                                         //   -> "   Fruit Titanesque, Inc."
> -        test(cb, "   Fruit Titanesque, Inc.");
> -    }
> -
> -    private static void test(CharBuffer cb, String exp) {
> -        cb.limit(cb.position());
> -        cb.rewind();
> -        if (!cb.toString().equals(exp))
> -            throw new RuntimeException("expect: '" + exp + "'; got: '"
> -                                       + cb.toString() + "'");
> -        cb.clear();
> -    }
> +    private static void test(CharBuffer cb, String exp) {
> +        cb.limit(cb.position());
> +        cb.rewind();
> +        if (!cb.toString().equals(exp))
> +            throw new RuntimeException("expect: '" + exp + "'; got: '"
> +                    + cb.toString() + "'");
> +        cb.clear();
> +    }
>   }
> diff --git a/test/java/util/ResourceBundle/ResourceBundleTest.java
> b/test/java/util/ResourceBundle/ResourceBundleTest.java
> --- a/test/java/util/ResourceBundle/ResourceBundleTest.java
> +++ b/test/java/util/ResourceBundle/ResourceBundleTest.java
> @@ -67,6 +67,7 @@
>
>   public class ResourceBundleTest extends RBTestFmwk {
>       public static void main(String[] args) throws Exception {
> +        Locale.setDefault(Locale.US);
>           new ResourceBundleTest().run(args);
>       }
>
> diff --git
> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
> --- a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
> +++ b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
> @@ -45,6 +45,7 @@
>       }
>
>       public static void main(String... args) throws Exception {
> +        Locale.setDefault(Locale.US);
>
>           Locale defaultLocale = Locale.getDefault();
>           System.out.println("Default locale is: " + defaultLocale);
> diff --git a/test/java/util/logging/LocalizedLevelName.java
> b/test/java/util/logging/LocalizedLevelName.java
> --- a/test/java/util/logging/LocalizedLevelName.java
> +++ b/test/java/util/logging/LocalizedLevelName.java
> @@ -49,6 +49,7 @@
>       };
>
>       public static void main(String args[]) throws Exception {
> +        Locale.setDefault(Locale.US);
>           Locale defaultLocale = Locale.getDefault();
>           for (int i=0; i<namesMap.length; i += 4) {
>               final String key = (String) namesMap[i];
> diff --git a/test/java/util/logging/SimpleFormatterFormat.java
> b/test/java/util/logging/SimpleFormatterFormat.java
> --- a/test/java/util/logging/SimpleFormatterFormat.java
> +++ b/test/java/util/logging/SimpleFormatterFormat.java
> @@ -30,6 +30,7 @@
>    */
>
>   import java.io.*;
> +import java.util.Locale;
>   import java.util.logging.*;
>   import java.util.regex.*;
>
> @@ -38,7 +39,8 @@
>       private static final String origFormat = System.getProperty(key);
>       private static final PrintStream err = System.err;
>       public static void main(String[] args) throws Exception {
> -        try {
> +       Locale.setDefault(Locale.US);
> +       try {
>               File dir = new File(System.getProperty("user.dir", "."));
>               File log = new File(dir, "simpleformat.txt");
>               java.nio.file.Files.deleteIfExists(log.toPath());
> diff --git a/test/sun/util/logging/SourceClassName.java
> b/test/sun/util/logging/SourceClassName.java
> --- a/test/sun/util/logging/SourceClassName.java
> +++ b/test/sun/util/logging/SourceClassName.java
> @@ -31,12 +31,14 @@
>    * @run main/othervm SourceClassName
>    */
>
> +import java.util.Locale;
>   import java.util.logging.*;
>   import java.io.*;
>   import sun.util.logging.PlatformLogger;
>
>   public class SourceClassName {
>       public static void main(String[] args) throws Exception {
> +        Locale.setDefault(Locale.US);
>           File dir = new File(System.getProperty("user.dir", "."));
>           File log = new File(dir, "testlog.txt");
>           PrintStream logps = new PrintStream(log);
>

From francis.andre.kampbell at orange.fr  Thu Oct 31 21:44:30 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Fri, 01 Nov 2013 05:44:30 +0100
Subject: <i18n dev> [8]: diff patch for jdk test on a non US platform
In-Reply-To: <5272CB33.8090501@oracle.com>
References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com>
	<5272CB33.8090501@oracle.com>
Message-ID: <527331AE.9080001@orange.fr>

Hi Stuart

Please see my comments through the mail
Le 31/10/2013 22:27, Stuart Marks a ?crit :
> Hi Francis,
>
> Alan Bateman directed me to this patch since it includes changes to the RMI 
> tests, which I maintain. I have a few comments on the changes to these tests.
>
>> From:     Francis ANDRE <francis.andre.kampbell at orange.fr>
>>
>> Following are a list of patch for making the jdk jtreg test suite happy with a
>> WXP/Cygwin/VS2010 Franch platform. For most of them, the fix consists in adding
>> Locale.setDefault(Locale.US); as the first statement in main.
>>
>> diff --git a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
>> b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
>> --- a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
>> +++ b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
>> @@ -238,7 +238,7 @@
>>
>>           public synchronized void notifyLine(String s)
>>           {
>> -            if (s != null && s.indexOf("rmid: debugExec") != -1)
>> +            if (s != null && s.indexOf("rmid : debugExec") != -1)
>>                   found = s;
>>           }
>>
>
> This is somewhat odd. This section of the test is capturing the output of rmid 
> and is scanning it for a particular string. Why would adding a space be 
> necessary? It turns out that the debugExec lines emitted by rmid are localized:
If the lines emitted by rmid are localized, then your test "s.indexOf("rmid: 
debugExec") != -1" should be also localized or did I miss something?
>
>
> $ cd jdk/src/share/classes/sun/rmi/server/resources
> $ grep rmid.exec.command *_*.properties
> rmid_de.properties:rmid.exec.command=rmid: debugExec: "{0}" wird ausgef\u00FChrt
> rmid_es.properties:rmid.exec.command=rmid: debugExec: en ejecuci\u00F3n "{0}"
> rmid_fr.properties:rmid.exec.command=rmid : debugExec : ex\u00E9cution de "{0}"
> rmid_it.properties:rmid.exec.command=rmid: debugExec: esecuzione di "{0}" in 
> corso
> rmid_ja.properties:rmid.exec.command=rmid: debugExec: 
> "{0}"\u3092\u5B9F\u884C\u4E2D
> rmid_ko.properties:rmid.exec.command=rmid: debugExec: "{0}" \uC2E4\uD589 \uC911
> rmid_pt_BR.properties:rmid.exec.command=rmid: debugExec: executando "{0}"
> rmid_sv.properties:rmid.exec.command=rmid: debugExec: k\u00F6r "{0}"
> rmid_zh_CN.properties:rmid.exec.command=rmid: debugExec: 
> \u6B63\u5728\u8FD0\u884C "{0}"
> rmid_zh_TW.properties:rmid.exec.command=rmid: debugExec: \u57F7\u884C "{0}"
> $ grep -B 0 -A 1 rmid.exec.command rmid.properties
> rmid.exec.command=\
>     rmid: debugExec: running "{0}"
>
>
> All locales except the French have no space between "rmid" and the trailing 
> colon (":"). It appears that having the space before the colon is proper 
> French usage (at least, the other French localizations all appear similar). 
> But adding the space to the search string will fix the French locale but will 
> break all the other locales.
 From my French perspective -- ie, my mother's language -- , I would not add a 
space between rmid and the colon...
>
> Forcing the test to run in the US locale seems preferable to adding logic to 
> deal with different localizations. Since these tests fork JVMs in 
> subprocesses, it's probably necessary to do something special to make sure the 
> sub-JVMs are in the US locale. This probably involves setting an environment 
> variable or a system property. I'm sure others on this list can provide advice.
I think that the best thing to do is removing the space " " before the colon ":" 
so that your code will work in any localisation. If it is not possible to remove 
this space, then you have to fix the test, taking care the localisation you 
mention in the rmid_fr.properties. Here the report of the test

RMID: starting rmid on port #3882...
ACTIVATION_LIBRARY: Activation System available after 0 milliseconds
RMID: finished starting rmid.
rmid : debugExec : ex?cution de 
"Z:\JDK\jdk8\build\WINDOW~1\images\J2SDK-~1\jre\bin\java 
-Djava.security.manager=default 
-Djava.security.policy=Z:\JDK\jdk8\jdk\test\java\rmi\activation\CommandEnvironment\group.security.policy 
-Dtest.src=Z:\JDK\jdk8\jdk\test\java\rmi\activation\CommandEnvironment 
-Dtest.classes=Z:\JDK\jdk8\build\windows-x86-normal-server-release\testoutput\jdk_rmi\JTwork\classes\0\java\rmi\activation\CommandEnvironment 
-Djava.rmi.server.useCodebaseOnly=false sun.rmi.server.ActivationGroupInit"
Tue Oct 29 08:15:08 CET 2013:ExecGroup-0:out:Doctor constructed and exported
Tue Oct 29 08:15:08 CET 2013:ExecGroup-0:out:Doctor will see you now
TEST FAILED: rmid subprocess produced no recognizable debugExec line

>
>
>> diff --git a/test/java/rmi/activation/checkusage/CheckUsage.java
>> b/test/java/rmi/activation/checkusage/CheckUsage.java
>> --- a/test/java/rmi/activation/checkusage/CheckUsage.java
>> +++ b/test/java/rmi/activation/checkusage/CheckUsage.java
>> @@ -31,12 +31,20 @@
>>    */
>>
>>   import java.io.ByteArrayOutputStream;
>> +import java.util.HashMap;
>> +import java.util.Locale;
>> +import java.util.Map;
>>
>>   /**
>>    * Make sure that rmid prints out a correct usage statement when run with an
>>    * incorrect command line.
>>    */
>>   public class CheckUsage {
>> +    private static final Map<String, String> maps = new HashMap<String, 
>> String>();
>> +    static {
>> +        maps.put(Locale.ENGLISH.getDisplayLanguage(), "runtime flag");
>> +        maps.put(Locale.FRENCH.getDisplayLanguage(), "indicateur d'ex?cution");
>> +    }
>>       public static void main(String[] args) {
>>           try {
>>               ByteArrayOutputStream berr = new ByteArrayOutputStream();
>> @@ -54,8 +62,9 @@
>>               String usage = new String(berr.toByteArray());
>>
>>               System.err.println("rmid usage: " + usage);
>> -
>> -            if (usage.indexOf("-J<runtime flag>") < 0) {
>> +
>> +            String jflag = "-J<" +
>> maps.get(Locale.getDefault().getDisplayLanguage()) + ">";
>> +            if (usage.indexOf(jflag) < 0) {
>>                   TestLibrary.bomb("rmid has incorrect usage message");
>>               } else {
>>                   System.err.println("test passed");
>
>
> This change looks like the start of a map that includes localized usage 
> messages from various locales. If we were to expand this to other locales, 
> eventually we'd end up duplicating all the localized usage messages into the 
> test code. That seems pretty fragile.
>
> As above, this is capturing the output of a subprocess, so it would seem 
> better if the subprocess were forced into the US locale.
>
> (In fact, this is kind of a stupid test anyway; all it does is make sure that 
> a usage message gets emitted if an erroneous command-line option is provided. 
> I've been thinking of removing it. It's certainly not worth adding extra logic 
> to handle multiple locales.)
>
> -- 
>
> Do we even support running the test suite in different locales? 
Your test is about the usage message in a localized language, so IMHO, it should 
take care of the localization message otherwise I do not understand this code: 
TestLibrary.bomb("rmid has incorrect usage message");
> We test on several platforms as it is; I don't think we'll want to have 
> separate test runs for all eleven (or however many) different localizations.
>
> I can see adding code (or test configuration properties or environment 
> variables) to ensure that tests are run in the US locale, unless this is 
> specifically overridden by the test. It doesn't seem appropriate to add 
> locale-specific logic or data structures to the tests, though.
If purpose of the test is to check the localization message, you would have no 
other choice to use properties like the previous rmid test.

Francis
>
> s'marks
>
>
>> diff --git a/test/java/util/Formattable/StockName.java
>> b/test/java/util/Formattable/StockName.java
>> --- a/test/java/util/Formattable/StockName.java
>> +++ b/test/java/util/Formattable/StockName.java
>> @@ -33,83 +33,90 @@
>>   import static java.util.FormattableFlags.*;
>>
>>   public class StockName implements Formattable {
>> -    private String symbol, companyName, frenchCompanyName;
>> +    private String symbol, companyName, frenchCompanyName;
>>
>> -    public StockName(String symbol, String companyName,
>> -                     String frenchCompanyName)
>> -    {
>> -        this.symbol = symbol;
>> -        this.companyName = companyName;
>> -        this.frenchCompanyName = frenchCompanyName;
>> -    }
>> +    public StockName(String symbol, String companyName, String 
>> frenchCompanyName) {
>> +        this.symbol = symbol;
>> +        this.companyName = companyName;
>> +        this.frenchCompanyName = frenchCompanyName;
>> +    }
>>
>> -    public void formatTo(Formatter fmt, int f, int width, int precision){
>> -        StringBuilder sb = new StringBuilder();
>> +    public void formatTo(Formatter fmt, int f, int width, int precision){
>> +        StringBuilder sb = new StringBuilder();
>>
>> -        // decide form of name
>> -        String name = companyName;
>> -        if (fmt.locale().equals(Locale.FRANCE))
>> -            name = frenchCompanyName;
>> -        boolean alternate = (f & ALTERNATE) == ALTERNATE;
>> -        boolean usesymbol = alternate || (precision != -1 && precision < 10);
>> -        String out = (usesymbol ? symbol : name);
>> +        // decide form of name
>> +        String name = companyName;
>> +        if (fmt.locale().equals(Locale.FRANCE))
>> +            name = frenchCompanyName;
>> +        boolean alternate = (f & ALTERNATE) == ALTERNATE;
>> +        boolean usesymbol = alternate || (precision != -1 && precision < 10);
>> +        String out = (usesymbol ? symbol : name);
>>
>> -        // apply precision
>> -        if (precision == -1 || out.length() < precision) {
>> -            // write it all
>> -            sb.append(out);
>> -        } else {
>> -            sb.append(out.substring(0, precision - 1)).append('*');
>> -        }
>> +        // apply precision
>> +        if (precision == -1 || out.length() < precision) {
>> +            // write it all
>> +            sb.append(out);
>> +        } else {
>> +            sb.append(out.substring(0, precision - 1)).append('*');
>> +        }
>>
>> -        // apply width and justification
>> -        int len = sb.length();
>> -        if (len < width)
>> -            for (int i = 0; i < width - len; i++)
>> -                if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY)
>> -                    sb.append(' ');
>> -                else
>> -                    sb.insert(0, ' ');
>> +        // apply width and justification
>> +        int len = sb.length();
>> +        if (len < width)
>> +            for (int i = 0; i < width - len; i++)
>> +                if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY)
>> +                    sb.append(' ');
>> +                else
>> +                    sb.insert(0, ' ');
>>
>> -        fmt.format(sb.toString());
>> -    }
>> +        fmt.format(sb.toString());
>> +    }
>>
>> -    public String toString() {
>> -        return String.format("%s - %s", symbol, companyName);
>> -    }
>> +    public String toString() {
>> +        return String.format("%s - %s", symbol, companyName);
>> +    }
>>
>> -    public static void main(String [] args) {
>> -        StockName sn = new StockName("HUGE", "Huge Fruit, Inc.",
>> -                                     "Fruit Titanesque, Inc.");
>> -        CharBuffer cb = CharBuffer.allocate(128);
>> -        Formatter fmt = new Formatter(cb);
>> +    public static void main(String[] args) {
>> +        StockName sn = new StockName("HUGE", "Huge Fruit, Inc.",
>> +                "Fruit Titanesque, Inc.");
>> +        CharBuffer cb = CharBuffer.allocate(128);
>> +        Formatter fmt = new Formatter(cb);
>>
>> -        fmt.format("%s", sn);            //   -> "Huge Fruit, Inc."
>> -        test(cb, "Huge Fruit, Inc.");
>> +        if (fmt.locale().equals(Locale.FRANCE)) {
>> +            fmt.format("%s", sn); // -> "Fruit Titanesque, Inc."
>> +            test(cb, "Fruit Titanesque, Inc.");
>> +        } else {
>> +            fmt.format("%s", sn); // -> "Huge Fruit, Inc."
>> +            test(cb, "Huge Fruit, Inc.");
>> +        }
>> +        fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc."
>> +        test(cb, "HUGE - Huge Fruit, Inc.");
>>
>> -        fmt.format("%s", sn.toString()); //   -> "HUGE - Huge Fruit, Inc."
>> -        test(cb, "HUGE - Huge Fruit, Inc.");
>> +        fmt.format("%#s", sn); // -> "HUGE"
>> +        test(cb, "HUGE");
>>
>> -        fmt.format("%#s", sn);           //   -> "HUGE"
>> -        test(cb, "HUGE");
>> +        fmt.format("%-10.8s", sn); // -> "HUGE      "
>> +        test(cb, "HUGE      ");
>>
>> -        fmt.format("%-10.8s", sn);       //   -> "HUGE "
>> -        test(cb, "HUGE      ");
>> +        if (fmt.locale().equals(Locale.FRANCE)) {
>> +            fmt.format("%.12s", sn); // -> "Fruit Titan*"
>> +            test(cb, "Fruit Titan*");
>> +        } else {
>> +            fmt.format("%.12s", sn); // -> "Huge Fruit,*"
>> +            test(cb, "Huge Fruit,*");
>> +        }
>>
>> -        fmt.format("%.12s", sn);         //   -> "Huge Fruit,*"
>> -        test(cb, "Huge Fruit,*");
>> +        fmt.format(Locale.FRANCE, "%25s", sn);
>> +        // -> "   Fruit Titanesque, Inc."
>> +        test(cb, "   Fruit Titanesque, Inc.");
>> +    }
>>
>> -        fmt.format(Locale.FRANCE, "%25s", sn);
>> -                                         //   -> "   Fruit Titanesque, Inc."
>> -        test(cb, "   Fruit Titanesque, Inc.");
>> -    }
>> -
>> -    private static void test(CharBuffer cb, String exp) {
>> -        cb.limit(cb.position());
>> -        cb.rewind();
>> -        if (!cb.toString().equals(exp))
>> -            throw new RuntimeException("expect: '" + exp + "'; got: '"
>> -                                       + cb.toString() + "'");
>> -        cb.clear();
>> -    }
>> +    private static void test(CharBuffer cb, String exp) {
>> +        cb.limit(cb.position());
>> +        cb.rewind();
>> +        if (!cb.toString().equals(exp))
>> +            throw new RuntimeException("expect: '" + exp + "'; got: '"
>> +                    + cb.toString() + "'");
>> +        cb.clear();
>> +    }
>>   }
>> diff --git a/test/java/util/ResourceBundle/ResourceBundleTest.java
>> b/test/java/util/ResourceBundle/ResourceBundleTest.java
>> --- a/test/java/util/ResourceBundle/ResourceBundleTest.java
>> +++ b/test/java/util/ResourceBundle/ResourceBundleTest.java
>> @@ -67,6 +67,7 @@
>>
>>   public class ResourceBundleTest extends RBTestFmwk {
>>       public static void main(String[] args) throws Exception {
>> +        Locale.setDefault(Locale.US);
>>           new ResourceBundleTest().run(args);
>>       }
>>
>> diff --git
>> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
>> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
>> --- a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
>> +++ b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
>> @@ -45,6 +45,7 @@
>>       }
>>
>>       public static void main(String... args) throws Exception {
>> +        Locale.setDefault(Locale.US);
>>
>>           Locale defaultLocale = Locale.getDefault();
>>           System.out.println("Default locale is: " + defaultLocale);
>> diff --git a/test/java/util/logging/LocalizedLevelName.java
>> b/test/java/util/logging/LocalizedLevelName.java
>> --- a/test/java/util/logging/LocalizedLevelName.java
>> +++ b/test/java/util/logging/LocalizedLevelName.java
>> @@ -49,6 +49,7 @@
>>       };
>>
>>       public static void main(String args[]) throws Exception {
>> +        Locale.setDefault(Locale.US);
>>           Locale defaultLocale = Locale.getDefault();
>>           for (int i=0; i<namesMap.length; i += 4) {
>>               final String key = (String) namesMap[i];
>> diff --git a/test/java/util/logging/SimpleFormatterFormat.java
>> b/test/java/util/logging/SimpleFormatterFormat.java
>> --- a/test/java/util/logging/SimpleFormatterFormat.java
>> +++ b/test/java/util/logging/SimpleFormatterFormat.java
>> @@ -30,6 +30,7 @@
>>    */
>>
>>   import java.io.*;
>> +import java.util.Locale;
>>   import java.util.logging.*;
>>   import java.util.regex.*;
>>
>> @@ -38,7 +39,8 @@
>>       private static final String origFormat = System.getProperty(key);
>>       private static final PrintStream err = System.err;
>>       public static void main(String[] args) throws Exception {
>> -        try {
>> +       Locale.setDefault(Locale.US);
>> +       try {
>>               File dir = new File(System.getProperty("user.dir", "."));
>>               File log = new File(dir, "simpleformat.txt");
>>               java.nio.file.Files.deleteIfExists(log.toPath());
>> diff --git a/test/sun/util/logging/SourceClassName.java
>> b/test/sun/util/logging/SourceClassName.java
>> --- a/test/sun/util/logging/SourceClassName.java
>> +++ b/test/sun/util/logging/SourceClassName.java
>> @@ -31,12 +31,14 @@
>>    * @run main/othervm SourceClassName
>>    */
>>
>> +import java.util.Locale;
>>   import java.util.logging.*;
>>   import java.io.*;
>>   import sun.util.logging.PlatformLogger;
>>
>>   public class SourceClassName {
>>       public static void main(String[] args) throws Exception {
>> +        Locale.setDefault(Locale.US);
>>           File dir = new File(System.getProperty("user.dir", "."));
>>           File log = new File(dir, "testlog.txt");
>>           PrintStream logps = new PrintStream(log);
>>
>