From masayoshi.okutsu at oracle.com  Mon Nov  2 02:04:34 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 2 Nov 2015 11:04:34 +0900
Subject: <i18n dev> [9] RFR: 8062006: Add a new locale data name
 "COMPAT" for java.locale.providers system property to reduce ambiguity
In-Reply-To: <5633BE58.80705@oracle.com>
References: <5633BE58.80705@oracle.com>
Message-ID: <5636C4B2.1080308@oracle.com>

Looks good to me.

Masayoshi

On 10/31/2015 4:00 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8062006
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8062006/webrev.00/
>
> Naoto


From ramanand.patil at oracle.com  Mon Nov 16 13:38:29 2015
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 16 Nov 2015 05:38:29 -0800 (PST)
Subject: <i18n dev> Code Review for JDK-8141243: Unexpected timezone
 returned after parsing a date
Message-ID: <a5a0b89f-d066-4276-a9ef-33e655becf7f@default>

Hi all,

 

Please review a fix for Bug Id - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8141243"JDK-8141243.

<https://bugs.openjdk.java.net/browse/JDK-8141243>

 

Issue - When parsing the virtual timezone "UTC" with java.text.SimpleDateFormat, the timezone is set to the first timezone that matches an actual timezone in the UTC group, which is Antarctica/Troll. When comparing this timezone with the result of TimeZone.getTimeZone("UTC"), we fail.

 

Webrev - http://cr.openjdk.java.net/~aefimov/8141243/webrev.00/

 

 

Regards,

Ramanand.

 

From masayoshi.okutsu at oracle.com  Tue Nov 17 08:54:21 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 17 Nov 2015 17:54:21 +0900
Subject: <i18n dev> Code Review for JDK-8141243: Unexpected timezone
 returned after parsing a date
In-Reply-To: <a5a0b89f-d066-4276-a9ef-33e655becf7f@default>
References: <a5a0b89f-d066-4276-a9ef-33e655becf7f@default>
Message-ID: <564AEB3D.3040609@oracle.com>

Hi Ramanand,

I don't think this fix is correct. This change mixes up time zone IDs 
and display names. SimpleDateFomat should parse only display names.

There's no perfect solution on the issue because the short display names 
(abbreviations) can't be unique. So, I'd suggest that the UTC display 
names in all resource bundles (all TimeZoneNames*.java under 
sun.util.resources) move up to the compatibility group.

BTW, the symptom is reproducible in JDK 9 with the legacy time zone 
names (run java with -Djava.locale.providers=COMPAT). So, the fix should 
be done in JDK 9 first.

Thanks,
Masayoshi

On 11/16/2015 10:38 PM, Ramanand Patil wrote:
> Hi all,
>
>   
>
> Please review a fix for Bug Id - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8141243"JDK-8141243.
>
> <https://bugs.openjdk.java.net/browse/JDK-8141243>
>
>   
>
> Issue - When parsing the virtual timezone "UTC" with java.text.SimpleDateFormat, the timezone is set to the first timezone that matches an actual timezone in the UTC group, which is Antarctica/Troll. When comparing this timezone with the result of TimeZone.getTimeZone("UTC"), we fail.
>
>   
>
> Webrev - http://cr.openjdk.java.net/~aefimov/8141243/webrev.00/
>
>   
>
>   
>
> Regards,
>
> Ramanand.
>
>   


From ramanand.patil at oracle.com  Tue Nov 17 16:09:19 2015
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 17 Nov 2015 08:09:19 -0800 (PST)
Subject: <i18n dev> Code Review for JDK-8141243: Unexpected timezone
 returned after parsing a date
In-Reply-To: <564AEB3D.3040609@oracle.com>
References: <a5a0b89f-d066-4276-a9ef-33e655becf7f@default>
	<564AEB3D.3040609@oracle.com>
Message-ID: <b083dd3f-a6a1-41ba-b751-22d61d0aa067@default>

Hi Masayoshi,

Thank you for your feedback and suggestion.

As you said, I understood that There's no perfect solution on the issue because the short display names(abbreviations) can't be unique.

I was trying to apply the workaround by considering the cases where the short display names are same as the Zone IDs. Anyways if the issue is reproducible in JDK 9 with the legacy time zone names I will dig more into it and try to find the correct fix.

Sorry, if I am asking very simple question(I am new to this group/process and want to understand correctly),
I didn't understand what is meant by your suggestion of moving UTC display names in all resource bundles (all TimeZoneNames*.java under sun.util.resources) up to the compatibility group.


Thank you for your help.

Regards,
Ramanand.



-----Original Message-----
From: Masayoshi Okutsu 
Sent: Tuesday, November 17, 2015 2:24 PM
To: Ramanand Patil; i18n-dev; core-libs-dev; jdk8u-dev
Subject: Re: <i18n dev> Code Review for JDK-8141243: Unexpected timezone returned after parsing a date

Hi Ramanand,

I don't think this fix is correct. This change mixes up time zone IDs and display names. SimpleDateFomat should parse only display names.

There's no perfect solution on the issue because the short display names
(abbreviations) can't be unique. So, I'd suggest that the UTC display names in all resource bundles (all TimeZoneNames*.java under
sun.util.resources) move up to the compatibility group.

BTW, the symptom is reproducible in JDK 9 with the legacy time zone names (run java with -Djava.locale.providers=COMPAT). So, the fix should be done in JDK 9 first.

Thanks,
Masayoshi

On 11/16/2015 10:38 PM, Ramanand Patil wrote:
> Hi all,
>
>   
>
> Please review a fix for Bug Id - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8141243"JDK-8141243.
>
> <https://bugs.openjdk.java.net/browse/JDK-8141243>
>
>   
>
> Issue - When parsing the virtual timezone "UTC" with java.text.SimpleDateFormat, the timezone is set to the first timezone that matches an actual timezone in the UTC group, which is Antarctica/Troll. When comparing this timezone with the result of TimeZone.getTimeZone("UTC"), we fail.
>
>   
>
> Webrev - http://cr.openjdk.java.net/~aefimov/8141243/webrev.00/
>
>   
>
>   
>
> Regards,
>
> Ramanand.
>
>   


From naveen.ah.kumar at oracle.com  Thu Nov 19 19:31:33 2015
From: naveen.ah.kumar at oracle.com (Naveen Kumar)
Date: Fri, 20 Nov 2015 01:01:33 +0530
Subject: <i18n dev> Review Request: JDK-8073211 javadoc of Format
 parseObject methods should specify NullPointerExceptions
Message-ID: <564E2395.8060003@oracle.com>

Hi All,
           Please review the following fix in API doc for jdk9

Bug:             https://bugs.openjdk.java.net/browse/JDK-8073211
webrev: http://cr.openjdk.java.net/~naoto/naveen/8073211/webrev.00/

Issue:

The 2 parseObject methods in java.text.Format throw a 
NullPointerException if the parameter "source" is null. However, this is 
not specified in the javadoc. Please note that this should also be 
checked & corrected in all subclasses of java.text.Format

Fix:
       Documentations of /java.text.Format.parseObject(java.lang.String, 
java.text.ParsePosition)/, 
/java.text.Format.parseObject(java.lang.String)/, 
/java.text.MessageFormat.parseObject(java.lang.String, 
java.text.ParsePosition)/, 
/java.text.DateFormat.parseObject(java.lang.String, 
java.text.ParsePosition)/, 
/java.text.NumberFormat.parseObject(java.lang.String, 
java.text.ParsePosition)/ are updated with the following addition:

* @throws NullPointerException if {@code source} is null.


regards
Naveen Kumar

From naoto.sato at oracle.com  Thu Nov 19 20:58:27 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 19 Nov 2015 12:58:27 -0800
Subject: <i18n dev> Review Request: JDK-8073211 javadoc of Format
 parseObject methods should specify NullPointerExceptions
In-Reply-To: <564E2395.8060003@oracle.com>
References: <564E2395.8060003@oracle.com>
Message-ID: <564E37F3.9020809@oracle.com>

Looks good to me.

Naoto

On 11/19/15 11:31 AM, Naveen Kumar wrote:
> Hi All,
>            Please review the following fix in API doc for jdk9
>
> Bug:             https://bugs.openjdk.java.net/browse/JDK-8073211
> webrev: http://cr.openjdk.java.net/~naoto/naveen/8073211/webrev.00/
>
> Issue:
>
> The 2 parseObject methods in java.text.Format throw a
> NullPointerException if the parameter "source" is null. However, this is
> not specified in the javadoc. Please note that this should also be
> checked & corrected in all subclasses of java.text.Format
>
> Fix:
>        Documentations of /java.text.Format.parseObject(java.lang.String,
> java.text.ParsePosition)/,
> /java.text.Format.parseObject(java.lang.String)/,
> /java.text.MessageFormat.parseObject(java.lang.String,
> java.text.ParsePosition)/,
> /java.text.DateFormat.parseObject(java.lang.String,
> java.text.ParsePosition)/,
> /java.text.NumberFormat.parseObject(java.lang.String,
> java.text.ParsePosition)/ are updated with the following addition:
>
> * @throws NullPointerException if {@code source} is null.
>
>
> regards
> Naveen Kumar

From masayoshi.okutsu at oracle.com  Fri Nov 20 08:24:12 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 20 Nov 2015 17:24:12 +0900
Subject: <i18n dev> [9] RFR: 8141243: Unexpected timezone returned after
	parsing a date
Message-ID: <564ED8AC.3050309@oracle.com>

Hello,

This is a follow up of the fix for JDK-8141243 done by Ramanand. I've 
changed resources so that time zone ID "UTC" is picked up by 
SimpleDateFormat before Antarctica/Troll.

issue: https://bugs.openjdk.java.net/browse/JDK-8141243

webrev: http://cr.openjdk.java.net/~okutsu/9/8141243/webrev.00/

Thanks,
Masayoshi


From naveen.ah.kumar at oracle.com  Fri Nov 20 10:13:06 2015
From: naveen.ah.kumar at oracle.com (Naveen Kumar)
Date: Fri, 20 Nov 2015 15:43:06 +0530
Subject: <i18n dev> Review Request: JDK-8073211 javadoc of Format
 parseObject methods should specify NullPointerExceptions
In-Reply-To: <564E37F3.9020809@oracle.com>
References: <564E2395.8060003@oracle.com> <564E37F3.9020809@oracle.com>
Message-ID: <564EF232.5070607@oracle.com>

Hi,
      Please consider this updated webrev.01 for the review of bug 
JDK-8073211

Bug:            https://bugs.openjdk.java.net/browse/JDK-8073211
webrev: http://cr.openjdk.java.net/~okutsu/naveen/8073211/webrev.01/

updates in fix:
                           Masayoshi pointed out that there was already 
a NullPointerException for pos. So I have merged both of them like this:

* @throws NullPointerException if {@code source} or {@code pos} is null. 
regards Naveen



On 11/20/2015 2:28 AM, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 11/19/15 11:31 AM, Naveen Kumar wrote:
>> Hi All,
>>            Please review the following fix in API doc for jdk9
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073211
>> webrev: http://cr.openjdk.java.net/~naoto/naveen/8073211/webrev.00/
>>
>> Issue:
>>
>> The 2 parseObject methods in java.text.Format throw a
>> NullPointerException if the parameter "source" is null. However, this is
>> not specified in the javadoc. Please note that this should also be
>> checked & corrected in all subclasses of java.text.Format
>>
>> Fix:
>>        Documentations of /java.text.Format.parseObject(java.lang.String,
>> java.text.ParsePosition)/,
>> /java.text.Format.parseObject(java.lang.String)/,
>> /java.text.MessageFormat.parseObject(java.lang.String,
>> java.text.ParsePosition)/,
>> /java.text.DateFormat.parseObject(java.lang.String,
>> java.text.ParsePosition)/,
>> /java.text.NumberFormat.parseObject(java.lang.String,
>> java.text.ParsePosition)/ are updated with the following addition:
>>
>> * @throws NullPointerException if {@code source} is null.
>>
>>
>> regards
>> Naveen Kumar


From naveen.ah.kumar at oracle.com  Fri Nov 20 10:20:56 2015
From: naveen.ah.kumar at oracle.com (Naveen Kumar)
Date: Fri, 20 Nov 2015 15:50:56 +0530
Subject: <i18n dev> Review Request: JDK-8073211 javadoc of Format
 parseObject methods should specify NullPointerExceptions
In-Reply-To: <564EF232.5070607@oracle.com>
References: <564E2395.8060003@oracle.com> <564E37F3.9020809@oracle.com>
	<564EF232.5070607@oracle.com>
Message-ID: <564EF408.7030600@oracle.com>

Hi,
      Please consider this updated webrev.01 for the review of bug 
JDK-8073211

Bug:            https://bugs.openjdk.java.net/browse/JDK-8073211
webrev: http://cr.openjdk.java.net/~okutsu/naveen/8073211/webrev.01/

updates in fix:
                           Masayoshi pointed out that there was already 
a NullPointerException for pos. So I have merged both of them like this:

* @throws NullPointerException if {@code source} or {@code pos} is null.


Sorry for posting it multiple times.


regards
Naveen

On 11/20/2015 3:43 PM, Naveen Kumar wrote:
> Hi,
>      Please consider this updated webrev.01 for the review of bug 
> JDK-8073211
>
> Bug:            https://bugs.openjdk.java.net/browse/JDK-8073211
> webrev: http://cr.openjdk.java.net/~okutsu/naveen/8073211/webrev.01/
>
> updates in fix:
>                           Masayoshi pointed out that there was already 
> a NullPointerException for pos. So I have merged both of them like this:
>
> * @throws NullPointerException if {@code source} or {@code pos} is 
> null. regards Naveen
>
>
>
> On 11/20/2015 2:28 AM, Naoto Sato wrote:
>> Looks good to me.
>>
>> Naoto
>>
>> On 11/19/15 11:31 AM, Naveen Kumar wrote:
>>> Hi All,
>>>            Please review the following fix in API doc for jdk9
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073211
>>> webrev: http://cr.openjdk.java.net/~naoto/naveen/8073211/webrev.00/
>>>
>>> Issue:
>>>
>>> The 2 parseObject methods in java.text.Format throw a
>>> NullPointerException if the parameter "source" is null. However, 
>>> this is
>>> not specified in the javadoc. Please note that this should also be
>>> checked & corrected in all subclasses of java.text.Format
>>>
>>> Fix:
>>>        Documentations of 
>>> /java.text.Format.parseObject(java.lang.String,
>>> java.text.ParsePosition)/,
>>> /java.text.Format.parseObject(java.lang.String)/,
>>> /java.text.MessageFormat.parseObject(java.lang.String,
>>> java.text.ParsePosition)/,
>>> /java.text.DateFormat.parseObject(java.lang.String,
>>> java.text.ParsePosition)/,
>>> /java.text.NumberFormat.parseObject(java.lang.String,
>>> java.text.ParsePosition)/ are updated with the following addition:
>>>
>>> * @throws NullPointerException if {@code source} is null.
>>>
>>>
>>> regards
>>> Naveen Kumar
>


From yuka.kamiya at oracle.com  Fri Nov 20 10:42:33 2015
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 20 Nov 2015 19:42:33 +0900
Subject: <i18n dev> [9] RFR: 8141243: Unexpected timezone returned after
 parsing a date
In-Reply-To: <564ED8AC.3050309@oracle.com>
References: <564ED8AC.3050309@oracle.com>
Message-ID: <564EF919.4040901@oracle.com>

Hi,

The fix looks good to me.

Thanks,
--
Yuka

On 2015/11/20 17:24, Masayoshi Okutsu wrote:
> Hello,
>
> This is a follow up of the fix for JDK-8141243 done by Ramanand. I've 
> changed resources so that time zone ID "UTC" is picked up by 
> SimpleDateFormat before Antarctica/Troll.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8141243
>
> webrev: http://cr.openjdk.java.net/~okutsu/9/8141243/webrev.00/
>
> Thanks,
> Masayoshi
>


From yuka.kamiya at oracle.com  Fri Nov 20 10:43:24 2015
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 20 Nov 2015 19:43:24 +0900
Subject: <i18n dev> Review Request: JDK-8073211 javadoc of Format
 parseObject methods should specify NullPointerExceptions
In-Reply-To: <564EF408.7030600@oracle.com>
References: <564E2395.8060003@oracle.com> <564E37F3.9020809@oracle.com>
	<564EF232.5070607@oracle.com> <564EF408.7030600@oracle.com>
Message-ID: <564EF94C.8060709@oracle.com>

Hi,

The fix looks good to me.

Thanks,
--
Yuka


On 2015/11/20 19:20, Naveen Kumar wrote:
> Hi,
>      Please consider this updated webrev.01 for the review of bug 
> JDK-8073211
>
> Bug:            https://bugs.openjdk.java.net/browse/JDK-8073211
> webrev: http://cr.openjdk.java.net/~okutsu/naveen/8073211/webrev.01/
>
> updates in fix:
>                           Masayoshi pointed out that there was already 
> a NullPointerException for pos. So I have merged both of them like this:
>
> * @throws NullPointerException if {@code source} or {@code pos} is null.
>
>
> Sorry for posting it multiple times.
>
>
> regards
> Naveen
>
> On 11/20/2015 3:43 PM, Naveen Kumar wrote:
>> Hi,
>>      Please consider this updated webrev.01 for the review of bug 
>> JDK-8073211
>>
>> Bug:            https://bugs.openjdk.java.net/browse/JDK-8073211
>> webrev: http://cr.openjdk.java.net/~okutsu/naveen/8073211/webrev.01/
>>
>> updates in fix:
>>                           Masayoshi pointed out that there was 
>> already a NullPointerException for pos. So I have merged both of them 
>> like this:
>>
>> * @throws NullPointerException if {@code source} or {@code pos} is 
>> null. regards Naveen
>>
>>
>>
>> On 11/20/2015 2:28 AM, Naoto Sato wrote:
>>> Looks good to me.
>>>
>>> Naoto
>>>
>>> On 11/19/15 11:31 AM, Naveen Kumar wrote:
>>>> Hi All,
>>>>            Please review the following fix in API doc for jdk9
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073211
>>>> webrev: http://cr.openjdk.java.net/~naoto/naveen/8073211/webrev.00/
>>>>
>>>> Issue:
>>>>
>>>> The 2 parseObject methods in java.text.Format throw a
>>>> NullPointerException if the parameter "source" is null. However, 
>>>> this is
>>>> not specified in the javadoc. Please note that this should also be
>>>> checked & corrected in all subclasses of java.text.Format
>>>>
>>>> Fix:
>>>>        Documentations of 
>>>> /java.text.Format.parseObject(java.lang.String,
>>>> java.text.ParsePosition)/,
>>>> /java.text.Format.parseObject(java.lang.String)/,
>>>> /java.text.MessageFormat.parseObject(java.lang.String,
>>>> java.text.ParsePosition)/,
>>>> /java.text.DateFormat.parseObject(java.lang.String,
>>>> java.text.ParsePosition)/,
>>>> /java.text.NumberFormat.parseObject(java.lang.String,
>>>> java.text.ParsePosition)/ are updated with the following addition:
>>>>
>>>> * @throws NullPointerException if {@code source} is null.
>>>>
>>>>
>>>> regards
>>>> Naveen Kumar
>>
>


From rachna.goel at oracle.com  Fri Nov 20 10:56:55 2015
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 20 Nov 2015 16:26:55 +0530
Subject: <i18n dev> Review request :JDK-7011840:TEST_BUG
 java/util/Locale/LocaleEnhanceTest.java
Message-ID: <564EFC77.703@oracle.com>

Hi all,

Please review a simple fix to JDK-7011840. Extra information is 
outputted to report if Serialized test case data is not found.

issue: https://bugs.openjdk.java.net/browse/JDK-7011840 
<https://bugs.openjdk.java.net/browse/JDK-7011840>

webrev: http://cr.openjdk.java.net/~rgoel/7011840/webrev.00/

Thanks,
Rachna



From masayoshi.okutsu at oracle.com  Fri Nov 20 14:49:23 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 20 Nov 2015 23:49:23 +0900
Subject: <i18n dev> Review Request: JDK-8073211 javadoc of Format
 parseObject methods should specify NullPointerExceptions
In-Reply-To: <564EF408.7030600@oracle.com>
References: <564E2395.8060003@oracle.com> <564E37F3.9020809@oracle.com>
	<564EF232.5070607@oracle.com> <564EF408.7030600@oracle.com>
Message-ID: <564F32F3.1060608@oracle.com>

Looks good.

Masayoshi

On 11/20/2015 7:20 PM, Naveen Kumar wrote:
> Hi,
>      Please consider this updated webrev.01 for the review of bug 
> JDK-8073211
>
> Bug:            https://bugs.openjdk.java.net/browse/JDK-8073211
> webrev: http://cr.openjdk.java.net/~okutsu/naveen/8073211/webrev.01/
>
> updates in fix:
>                           Masayoshi pointed out that there was already 
> a NullPointerException for pos. So I have merged both of them like this:
>
> * @throws NullPointerException if {@code source} or {@code pos} is null.
>
>
> Sorry for posting it multiple times.
>
>
> regards
> Naveen
>
> On 11/20/2015 3:43 PM, Naveen Kumar wrote:
>> Hi,
>>      Please consider this updated webrev.01 for the review of bug 
>> JDK-8073211
>>
>> Bug:            https://bugs.openjdk.java.net/browse/JDK-8073211
>> webrev: http://cr.openjdk.java.net/~okutsu/naveen/8073211/webrev.01/
>>
>> updates in fix:
>>                           Masayoshi pointed out that there was 
>> already a NullPointerException for pos. So I have merged both of them 
>> like this:
>>
>> * @throws NullPointerException if {@code source} or {@code pos} is 
>> null. regards Naveen
>>
>>
>>
>> On 11/20/2015 2:28 AM, Naoto Sato wrote:
>>> Looks good to me.
>>>
>>> Naoto
>>>
>>> On 11/19/15 11:31 AM, Naveen Kumar wrote:
>>>> Hi All,
>>>>            Please review the following fix in API doc for jdk9
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073211
>>>> webrev: http://cr.openjdk.java.net/~naoto/naveen/8073211/webrev.00/
>>>>
>>>> Issue:
>>>>
>>>> The 2 parseObject methods in java.text.Format throw a
>>>> NullPointerException if the parameter "source" is null. However, 
>>>> this is
>>>> not specified in the javadoc. Please note that this should also be
>>>> checked & corrected in all subclasses of java.text.Format
>>>>
>>>> Fix:
>>>>        Documentations of 
>>>> /java.text.Format.parseObject(java.lang.String,
>>>> java.text.ParsePosition)/,
>>>> /java.text.Format.parseObject(java.lang.String)/,
>>>> /java.text.MessageFormat.parseObject(java.lang.String,
>>>> java.text.ParsePosition)/,
>>>> /java.text.DateFormat.parseObject(java.lang.String,
>>>> java.text.ParsePosition)/,
>>>> /java.text.NumberFormat.parseObject(java.lang.String,
>>>> java.text.ParsePosition)/ are updated with the following addition:
>>>>
>>>> * @throws NullPointerException if {@code source} is null.
>>>>
>>>>
>>>> regards
>>>> Naveen Kumar
>>
>


From naoto.sato at oracle.com  Fri Nov 20 17:57:25 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Nov 2015 09:57:25 -0800
Subject: <i18n dev> [9] RFR: 8141243: Unexpected timezone returned after
 parsing a date
In-Reply-To: <564ED8AC.3050309@oracle.com>
References: <564ED8AC.3050309@oracle.com>
Message-ID: <564F5F05.1010704@oracle.com>

In ResourceBundleGenerator.java, if we move "UTC" into the preferred 
names list, should we also treat it when we create the preferred ordered 
map? In other words, should we do the same for "UTC" at the line 140?

Naoto

On 11/20/15 12:24 AM, Masayoshi Okutsu wrote:
> Hello,
>
> This is a follow up of the fix for JDK-8141243 done by Ramanand. I've
> changed resources so that time zone ID "UTC" is picked up by
> SimpleDateFormat before Antarctica/Troll.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8141243
>
> webrev: http://cr.openjdk.java.net/~okutsu/9/8141243/webrev.00/
>
> Thanks,
> Masayoshi
>

From naoto.sato at oracle.com  Fri Nov 20 18:56:30 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Nov 2015 10:56:30 -0800
Subject: <i18n dev> Review request :JDK-7011840:TEST_BUG
 java/util/Locale/LocaleEnhanceTest.java
In-Reply-To: <564EFC77.703@oracle.com>
References: <564EFC77.703@oracle.com>
Message-ID: <564F6CDE.6020003@oracle.com>

Looks good to me.

Naoto

On 11/20/15 2:56 AM, Rachna Goel wrote:
> Hi all,
>
> Please review a simple fix to JDK-7011840. Extra information is
> outputted to report if Serialized test case data is not found.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-7011840
> <https://bugs.openjdk.java.net/browse/JDK-7011840>
>
> webrev: http://cr.openjdk.java.net/~rgoel/7011840/webrev.00/
>
> Thanks,
> Rachna
>
>

From masayoshi.okutsu at oracle.com  Mon Nov 23 03:45:16 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 23 Nov 2015 12:45:16 +0900
Subject: <i18n dev> [9] RFR: 8141243: Unexpected timezone returned after
 parsing a date
In-Reply-To: <564F5F05.1010704@oracle.com>
References: <564ED8AC.3050309@oracle.com> <564F5F05.1010704@oracle.com>
Message-ID: <56528BCC.6080102@oracle.com>

That part doesn't seem to affect UTC because it comes from the legacy 
JRE locale data.

Masayoshi

On 11/21/2015 2:57 AM, Naoto Sato wrote:
> In ResourceBundleGenerator.java, if we move "UTC" into the preferred 
> names list, should we also treat it when we create the preferred 
> ordered map? In other words, should we do the same for "UTC" at the 
> line 140?
>
> Naoto
>
> On 11/20/15 12:24 AM, Masayoshi Okutsu wrote:
>> Hello,
>>
>> This is a follow up of the fix for JDK-8141243 done by Ramanand. I've
>> changed resources so that time zone ID "UTC" is picked up by
>> SimpleDateFormat before Antarctica/Troll.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8141243
>>
>> webrev: http://cr.openjdk.java.net/~okutsu/9/8141243/webrev.00/
>>
>> Thanks,
>> Masayoshi
>>


From yuka.kamiya at oracle.com  Tue Nov 24 07:35:09 2015
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Tue, 24 Nov 2015 16:35:09 +0900
Subject: <i18n dev> Review request :JDK-7011840:TEST_BUG
 java/util/Locale/LocaleEnhanceTest.java
In-Reply-To: <564EFC77.703@oracle.com>
References: <564EFC77.703@oracle.com>
Message-ID: <5654132D.3010702@oracle.com>

Hi Rachna,

The fix looks good to me.

Thanks,
--
Yuka

On 2015/11/20 19:56, Rachna Goel wrote:
> Hi all,
>
> Please review a simple fix to JDK-7011840. Extra information is 
> outputted to report if Serialized test case data is not found.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-7011840 
> <https://bugs.openjdk.java.net/browse/JDK-7011840>
>
> webrev: http://cr.openjdk.java.net/~rgoel/7011840/webrev.00/
>
> Thanks,
> Rachna
>
>


From naveen.ah.kumar at oracle.com  Tue Nov 24 13:00:07 2015
From: naveen.ah.kumar at oracle.com (Naveen Kumar)
Date: Tue, 24 Nov 2015 18:30:07 +0530
Subject: <i18n dev> Review Request: remove @ignore 6876961 from
 test/java/util/ResourceBundle/Test4300693.java
Message-ID: <56545F57.4030307@oracle.com>

Hi All,
            Please review the following fix in (jtreg) test for jdk9

Bug:    https://bugs.openjdk.java.net/browse/JDK-7047633
webrev: http://cr.openjdk.java.net/~okutsu/naveen/7047633/webrev.00/

issue description:
Since 6876961 is now fixed, @ignore 6876961 should be removed from the test.


Fix:
Removed @ignore 6876961 from test/java/util/ResourceBundle/Test4300693.java

regards
Naveen

From naveen.ah.kumar at oracle.com  Tue Nov 24 13:01:50 2015
From: naveen.ah.kumar at oracle.com (Naveen Kumar)
Date: Tue, 24 Nov 2015 18:31:50 +0530
Subject: <i18n dev> Review Request: JDK-7047633 remove @ignore 6876961 from
 test/java/util/ResourceBundle/Test4300693.java
Message-ID: <56545FBE.3030809@oracle.com>

Hi All,
            Please review the following fix in (jtreg) test for jdk9

Bug: https://bugs.openjdk.java.net/browse/JDK-7047633
webrev: http://cr.openjdk.java.net/~okutsu/naveen/7047633/webrev.00/

issue description:
Since 6876961 is now fixed, @ignore 6876961 should be removed from the 
test.


Fix:
Removed @ignore 6876961 from test/java/util/ResourceBundle/Test4300693.java


Please ignore the last mail.

regards
Naveen

From masayoshi.okutsu at oracle.com  Tue Nov 24 13:06:19 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 24 Nov 2015 22:06:19 +0900
Subject: <i18n dev> Review Request: JDK-7047633 remove @ignore 6876961
 from test/java/util/ResourceBundle/Test4300693.java
In-Reply-To: <56545FBE.3030809@oracle.com>
References: <56545FBE.3030809@oracle.com>
Message-ID: <565460CB.6050705@oracle.com>

Looks good to me.

Masayoshi

On 11/24/2015 10:01 PM, Naveen Kumar wrote:
> Hi All,
>            Please review the following fix in (jtreg) test for jdk9
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7047633
> webrev: http://cr.openjdk.java.net/~okutsu/naveen/7047633/webrev.00/
>
> issue description:
> Since 6876961 is now fixed, @ignore 6876961 should be removed from the 
> test.
>
>
> Fix:
> Removed @ignore 6876961 from 
> test/java/util/ResourceBundle/Test4300693.java
>
>
> Please ignore the last mail.
>
> regards
> Naveen


From yuka.kamiya at oracle.com  Tue Nov 24 23:19:05 2015
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 25 Nov 2015 08:19:05 +0900
Subject: <i18n dev> Review Request: JDK-7047633 remove @ignore 6876961
 from test/java/util/ResourceBundle/Test4300693.java
In-Reply-To: <56545FBE.3030809@oracle.com>
References: <56545FBE.3030809@oracle.com>
Message-ID: <5654F069.6030502@oracle.com>

Hi Naveen,

Your fix looks good to me.

Thanks,
--
Yuka

On 2015/11/24 22:01, Naveen Kumar wrote:
> Hi All,
>            Please review the following fix in (jtreg) test for jdk9
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7047633
> webrev: http://cr.openjdk.java.net/~okutsu/naveen/7047633/webrev.00/
>
> issue description:
> Since 6876961 is now fixed, @ignore 6876961 should be removed from the 
> test.
>
>
> Fix:
> Removed @ignore 6876961 from 
> test/java/util/ResourceBundle/Test4300693.java
>
>
> Please ignore the last mail.
>
> regards
> Naveen