From takiguc at linux.vnet.ibm.com  Tue Oct  2 16:30:29 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 03 Oct 2018 01:30:29 +0900
Subject: <i18n dev> RFR[12]: 8211393 Memory leak issue on awt_InputMethod.c
In-Reply-To: <5d0494712cee97fcf0e310d0ec330b46@linux.vnet.ibm.com>
References: <e568e8afdb224c03de6d21a1f8814b00@linux.vnet.ibm.com>
 <e40d54b4-6eca-caa6-219c-5c802fe27863@oracle.com>
 <eec2e84fff7ef747cb4e80eadbcebedb@linux.vnet.ibm.com>
 <5d0494712cee97fcf0e310d0ec330b46@linux.vnet.ibm.com>
Message-ID: <3e29ed931f1f2752838edfbc0a9d5d15@linux.vnet.ibm.com>

Hello.
Could you review memory leak fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8211393
Change: https://cr.openjdk.java.net/~itakiguchi/8211393/webrev.00/

I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-07-23 21:24, Ichiroh Takiguchi wrote:
> Hello.
> 
> I'd like to change target to "JDK12".
> I'd like to obtain a sponsor for this patch.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-06-28 22:13, Ichiroh Takiguchi wrote:
>> Hello.
>> In my investigation, this issue only happens on 64 bit build only...
>> 
>> On 2018-06-28 06:06, Phil Race wrote:
>>> On 06/27/2018 06:45 AM, Ichiroh Takiguchi wrote:
>>>> Hello,
>>>> 
>>>> I should post this mail before starting JDK11 RDP1.
>>> 
>>> Already too too late for that, but although this looks like a bug -
>>> and the correct fix -
>>> the bug has been there forever .. since JDK 1.2  in 1998 !
>>> That makes it a 20 year old bug, so I don't think we need to treat it 
>>> as urgent
>>> for JDK 11.
>>> 
>>> -phil.
>>> 
>>>> 
>>>> I found memory leak issue on awt_InputMethod.c.
>>>> 
>>>> See src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.
>>>> On line 1117, memory area was allocated by malloc(), but free() is 
>>>> missing
>>>> ===========================================
>>>>   1099          if (text->feedback != NULL) {
>>>>   1100              int cnt;
>>>>   1101              jint *tmpstyle;
>>>>   1102
>>>>   1103              style = (*env)->NewIntArray(env, text->length);
>>>>   1104              if (JNU_IsNull(env, style)) {
>>>>   1105                  (*env)->ExceptionClear(env);
>>>>   1106                  THROW_OUT_OF_MEMORY_ERROR();
>>>>   1107                  goto finally;
>>>>   1108              }
>>>>   1109
>>>>   1110              if (sizeof(XIMFeedback) == sizeof(jint)) {
>>>>   1111                  /*
>>>>   1112                   * Optimization to avoid copying the array
>>>>   1113                   */
>>>>   1114                  (*env)->SetIntArrayRegion(env, style, 0,
>>>>   1115                                            text->length, 
>>>> (jint *)text->feedback);
>>>>   1116              } else {
>>>>   1117                  tmpstyle  = (jint 
>>>> *)malloc(sizeof(jint)*(text->length));
>>>>   1118                  if (tmpstyle == (jint *) NULL) {
>>>>   1119                      THROW_OUT_OF_MEMORY_ERROR();
>>>>   1120                      goto finally;
>>>>   1121                  }
>>>>   1122                  for (cnt = 0; cnt < (int)text->length; 
>>>> cnt++)
>>>>   1123                          tmpstyle[cnt] = text->feedback[cnt];
>>>>   1124                  (*env)->SetIntArrayRegion(env, style, 0,
>>>>   1125                                            text->length, 
>>>> (jint *)tmpstyle);
>>>>   1126              }
>>>>   1127          }
>>>> ===========================================
>>>> In my investigation, malloc() was called on RHEL7 x86_64 with 
>>>> Japanese Input Method.
>>>> 
>>>> I'd like to obtain a sponsor for this patch.
>>>> --------
>>>> --- 
>>>> old/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
>>>> 2018-06-27 02:03:48.134991703 +0900
>>>> +++ 
>>>> new/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
>>>> 2018-06-27 02:03:47.493005265 +0900
>>>> @@ -1148,6 +1148,7 @@
>>>>                          tmpstyle[cnt] = text->feedback[cnt];
>>>>                  (*env)->SetIntArrayRegion(env, style, 0,
>>>>                                            text->length, (jint 
>>>> *)tmpstyle);
>>>> +                free(tmpstyle);
>>>>              }
>>>>          }
>>>>      }
>>>> --- 
>>>> old/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c  
>>>> 2018-06-27 02:03:49.040972563 +0900
>>>> +++ 
>>>> new/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c  
>>>> 2018-06-27 02:03:48.391986274 +0900
>>>> @@ -1123,6 +1123,7 @@
>>>>                          tmpstyle[cnt] = text->feedback[cnt];
>>>>                  (*env)->SetIntArrayRegion(env, style, 0,
>>>>                                            text->length, (jint 
>>>> *)tmpstyle);
>>>> +                free(tmpstyle);
>>>>              }
>>>>          }
>>>>      }
>>>> --------
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> IBM Japan, Ltd.
>>>> 


From naoto.sato at oracle.com  Tue Oct  2 22:26:49 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 2 Oct 2018 15:26:49 -0700
Subject: <i18n dev> RFR[12]: 8211393 Memory leak issue on
 awt_InputMethod.c
In-Reply-To: <3e29ed931f1f2752838edfbc0a9d5d15@linux.vnet.ibm.com>
References: <e568e8afdb224c03de6d21a1f8814b00@linux.vnet.ibm.com>
 <e40d54b4-6eca-caa6-219c-5c802fe27863@oracle.com>
 <eec2e84fff7ef747cb4e80eadbcebedb@linux.vnet.ibm.com>
 <5d0494712cee97fcf0e310d0ec330b46@linux.vnet.ibm.com>
 <3e29ed931f1f2752838edfbc0a9d5d15@linux.vnet.ibm.com>
Message-ID: <08501c32-a33a-08ef-6fb0-7211b744c5a4@oracle.com>

Looks good to me.

Naoto

On 10/2/18 9:30 AM, Ichiroh Takiguchi wrote:
> Hello.
> Could you review memory leak fix ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211393
> Change: https://cr.openjdk.java.net/~itakiguchi/8211393/webrev.00/
> 
> I'd like to obtain a sponsor for this issue.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-07-23 21:24, Ichiroh Takiguchi wrote:
>> Hello.
>>
>> I'd like to change target to "JDK12".
>> I'd like to obtain a sponsor for this patch.
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>>
>> On 2018-06-28 22:13, Ichiroh Takiguchi wrote:
>>> Hello.
>>> In my investigation, this issue only happens on 64 bit build only...
>>>
>>> On 2018-06-28 06:06, Phil Race wrote:
>>>> On 06/27/2018 06:45 AM, Ichiroh Takiguchi wrote:
>>>>> Hello,
>>>>>
>>>>> I should post this mail before starting JDK11 RDP1.
>>>>
>>>> Already too too late for that, but although this looks like a bug -
>>>> and the correct fix -
>>>> the bug has been there forever .. since JDK 1.2? in 1998 !
>>>> That makes it a 20 year old bug, so I don't think we need to treat 
>>>> it as urgent
>>>> for JDK 11.
>>>>
>>>> -phil.
>>>>
>>>>>
>>>>> I found memory leak issue on awt_InputMethod.c.
>>>>>
>>>>> See src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.
>>>>> On line 1117, memory area was allocated by malloc(), but free() is 
>>>>> missing
>>>>> ===========================================
>>>>> ? 1099????????? if (text->feedback != NULL) {
>>>>> ? 1100????????????? int cnt;
>>>>> ? 1101????????????? jint *tmpstyle;
>>>>> ? 1102
>>>>> ? 1103????????????? style = (*env)->NewIntArray(env, text->length);
>>>>> ? 1104????????????? if (JNU_IsNull(env, style)) {
>>>>> ? 1105????????????????? (*env)->ExceptionClear(env);
>>>>> ? 1106????????????????? THROW_OUT_OF_MEMORY_ERROR();
>>>>> ? 1107????????????????? goto finally;
>>>>> ? 1108????????????? }
>>>>> ? 1109
>>>>> ? 1110????????????? if (sizeof(XIMFeedback) == sizeof(jint)) {
>>>>> ? 1111????????????????? /*
>>>>> ? 1112?????????????????? * Optimization to avoid copying the array
>>>>> ? 1113?????????????????? */
>>>>> ? 1114????????????????? (*env)->SetIntArrayRegion(env, style, 0,
>>>>> ? 1115??????????????????????????????????????????? text->length, 
>>>>> (jint *)text->feedback);
>>>>> ? 1116????????????? } else {
>>>>> ? 1117????????????????? tmpstyle? = (jint 
>>>>> *)malloc(sizeof(jint)*(text->length));
>>>>> ? 1118????????????????? if (tmpstyle == (jint *) NULL) {
>>>>> ? 1119????????????????????? THROW_OUT_OF_MEMORY_ERROR();
>>>>> ? 1120????????????????????? goto finally;
>>>>> ? 1121????????????????? }
>>>>> ? 1122????????????????? for (cnt = 0; cnt < (int)text->length; cnt++)
>>>>> ? 1123????????????????????????? tmpstyle[cnt] = text->feedback[cnt];
>>>>> ? 1124????????????????? (*env)->SetIntArrayRegion(env, style, 0,
>>>>> ? 1125??????????????????????????????????????????? text->length, 
>>>>> (jint *)tmpstyle);
>>>>> ? 1126????????????? }
>>>>> ? 1127????????? }
>>>>> ===========================================
>>>>> In my investigation, malloc() was called on RHEL7 x86_64 with 
>>>>> Japanese Input Method.
>>>>>
>>>>> I'd like to obtain a sponsor for this patch.
>>>>> --------
>>>>> --- 
>>>>> old/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
>>>>> 2018-06-27 02:03:48.134991703 +0900
>>>>> +++ 
>>>>> new/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
>>>>> 2018-06-27 02:03:47.493005265 +0900
>>>>> @@ -1148,6 +1148,7 @@
>>>>> ???????????????????????? tmpstyle[cnt] = text->feedback[cnt];
>>>>> ???????????????? (*env)->SetIntArrayRegion(env, style, 0,
>>>>> ?????????????????????????????????????????? text->length, (jint 
>>>>> *)tmpstyle);
>>>>> +??????????????? free(tmpstyle);
>>>>> ???????????? }
>>>>> ???????? }
>>>>> ???? }
>>>>> --- 
>>>>> old/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c 
>>>>> 2018-06-27 02:03:49.040972563 +0900
>>>>> +++ 
>>>>> new/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c 
>>>>> 2018-06-27 02:03:48.391986274 +0900
>>>>> @@ -1123,6 +1123,7 @@
>>>>> ???????????????????????? tmpstyle[cnt] = text->feedback[cnt];
>>>>> ???????????????? (*env)->SetIntArrayRegion(env, style, 0,
>>>>> ?????????????????????????????????????????? text->length, (jint 
>>>>> *)tmpstyle);
>>>>> +??????????????? free(tmpstyle);
>>>>> ???????????? }
>>>>> ???????? }
>>>>> ???? }
>>>>> --------
>>>>>
>>>>> Thanks,
>>>>> Ichiroh Takiguchi
>>>>> IBM Japan, Ltd.
>>>>>
> 

From naoto.sato at oracle.com  Thu Oct  4 20:30:46 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 4 Oct 2018 13:30:46 -0700
Subject: <i18n dev> [12] RFR: 8211398: Square character support for the
	Japanese new era
Message-ID: <b3aa1914-56f9-ea9e-8de8-d9280e0411bd@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

This change is to allow the code point (U+32FF) which will designate the 
square character for the Japanese new era.

Naoto

From christoph.langer at sap.com  Mon Oct  8 06:20:39 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 8 Oct 2018 06:20:39 +0000
Subject: <i18n dev> RFR[12]: 8211393 Memory leak issue on
 awt_InputMethod.c
In-Reply-To: <3e29ed931f1f2752838edfbc0a9d5d15@linux.vnet.ibm.com>
References: <e568e8afdb224c03de6d21a1f8814b00@linux.vnet.ibm.com>
 <e40d54b4-6eca-caa6-219c-5c802fe27863@oracle.com>
 <eec2e84fff7ef747cb4e80eadbcebedb@linux.vnet.ibm.com>
 <5d0494712cee97fcf0e310d0ec330b46@linux.vnet.ibm.com>
 <3e29ed931f1f2752838edfbc0a9d5d15@linux.vnet.ibm.com>
Message-ID: <31866126d16c4d10a15ced749212dabd@sap.com>

+1

> -----Original Message-----
> From: i18n-dev <i18n-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh
> Takiguchi
> Sent: Dienstag, 2. Oktober 2018 18:30
> To: awt-dev at openjdk.java.net; i18n-dev at openjdk.java.net
> Subject: <i18n dev> RFR[12]: 8211393 Memory leak issue on
> awt_InputMethod.c
> 
> Hello.
> Could you review memory leak fix ?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8211393
> Change: https://cr.openjdk.java.net/~itakiguchi/8211393/webrev.00/
> 
> I'd like to obtain a sponsor for this issue.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-07-23 21:24, Ichiroh Takiguchi wrote:
> > Hello.
> >
> > I'd like to change target to "JDK12".
> > I'd like to obtain a sponsor for this patch.
> >
> > Thanks,
> > Ichiroh Takiguchi
> > IBM Japan, Ltd.
> >
> > On 2018-06-28 22:13, Ichiroh Takiguchi wrote:
> >> Hello.
> >> In my investigation, this issue only happens on 64 bit build only...
> >>
> >> On 2018-06-28 06:06, Phil Race wrote:
> >>> On 06/27/2018 06:45 AM, Ichiroh Takiguchi wrote:
> >>>> Hello,
> >>>>
> >>>> I should post this mail before starting JDK11 RDP1.
> >>>
> >>> Already too too late for that, but although this looks like a bug -
> >>> and the correct fix -
> >>> the bug has been there forever .. since JDK 1.2  in 1998 !
> >>> That makes it a 20 year old bug, so I don't think we need to treat it
> >>> as urgent
> >>> for JDK 11.
> >>>
> >>> -phil.
> >>>
> >>>>
> >>>> I found memory leak issue on awt_InputMethod.c.
> >>>>
> >>>> See
> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.
> >>>> On line 1117, memory area was allocated by malloc(), but free() is
> >>>> missing
> >>>> ===========================================
> >>>>   1099          if (text->feedback != NULL) {
> >>>>   1100              int cnt;
> >>>>   1101              jint *tmpstyle;
> >>>>   1102
> >>>>   1103              style = (*env)->NewIntArray(env, text->length);
> >>>>   1104              if (JNU_IsNull(env, style)) {
> >>>>   1105                  (*env)->ExceptionClear(env);
> >>>>   1106                  THROW_OUT_OF_MEMORY_ERROR();
> >>>>   1107                  goto finally;
> >>>>   1108              }
> >>>>   1109
> >>>>   1110              if (sizeof(XIMFeedback) == sizeof(jint)) {
> >>>>   1111                  /*
> >>>>   1112                   * Optimization to avoid copying the array
> >>>>   1113                   */
> >>>>   1114                  (*env)->SetIntArrayRegion(env, style, 0,
> >>>>   1115                                            text->length,
> >>>> (jint *)text->feedback);
> >>>>   1116              } else {
> >>>>   1117                  tmpstyle  = (jint
> >>>> *)malloc(sizeof(jint)*(text->length));
> >>>>   1118                  if (tmpstyle == (jint *) NULL) {
> >>>>   1119                      THROW_OUT_OF_MEMORY_ERROR();
> >>>>   1120                      goto finally;
> >>>>   1121                  }
> >>>>   1122                  for (cnt = 0; cnt < (int)text->length;
> >>>> cnt++)
> >>>>   1123                          tmpstyle[cnt] = text->feedback[cnt];
> >>>>   1124                  (*env)->SetIntArrayRegion(env, style, 0,
> >>>>   1125                                            text->length,
> >>>> (jint *)tmpstyle);
> >>>>   1126              }
> >>>>   1127          }
> >>>> ===========================================
> >>>> In my investigation, malloc() was called on RHEL7 x86_64 with
> >>>> Japanese Input Method.
> >>>>
> >>>> I'd like to obtain a sponsor for this patch.
> >>>> --------
> >>>> ---
> >>>> old/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c
> >>>> 2018-06-27 02:03:48.134991703 +0900
> >>>> +++
> >>>>
> new/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c
> >>>> 2018-06-27 02:03:47.493005265 +0900
> >>>> @@ -1148,6 +1148,7 @@
> >>>>                          tmpstyle[cnt] = text->feedback[cnt];
> >>>>                  (*env)->SetIntArrayRegion(env, style, 0,
> >>>>                                            text->length, (jint
> >>>> *)tmpstyle);
> >>>> +                free(tmpstyle);
> >>>>              }
> >>>>          }
> >>>>      }
> >>>> ---
> >>>>
> old/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
> >>>> 2018-06-27 02:03:49.040972563 +0900
> >>>> +++
> >>>>
> new/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
> >>>> 2018-06-27 02:03:48.391986274 +0900
> >>>> @@ -1123,6 +1123,7 @@
> >>>>                          tmpstyle[cnt] = text->feedback[cnt];
> >>>>                  (*env)->SetIntArrayRegion(env, style, 0,
> >>>>                                            text->length, (jint
> >>>> *)tmpstyle);
> >>>> +                free(tmpstyle);
> >>>>              }
> >>>>          }
> >>>>      }
> >>>> --------
> >>>>
> >>>> Thanks,
> >>>> Ichiroh Takiguchi
> >>>> IBM Japan, Ltd.
> >>>>


From ying.z.zhou at oracle.com  Wed Oct 10 06:19:41 2018
From: ying.z.zhou at oracle.com (Ying Zhou)
Date: Wed, 10 Oct 2018 14:19:41 +0800
Subject: <i18n dev> [12]RFR of JDK-8210403:Refactor java.util.Locale:i18n
 shell tests to plain java tests
Message-ID: <46debed1-8c0f-962b-f266-2aef25aa35d6@oracle.com>

Hello,

test/java/util/Locale/LocaleCategory.sh
test/java/util/Locale/LocaleProviders.sh

Please review this patch to refactor above shell script tests to java.

bug: https://bugs.openjdk.java.net/browse/JDK-8210403

webrev: http://cr.openjdk.java.net/~dzhou/8210403/webrev.00/ 
<http://cr.openjdk.java.net/%7Edzhou/8210403/webrev.00/>

Thanks,

Daisy


From naoto.sato at oracle.com  Wed Oct 10 16:50:15 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 10 Oct 2018 09:50:15 -0700
Subject: <i18n dev> [12]RFR of JDK-8210403:Refactor
 java.util.Locale:i18n shell tests to plain java tests
In-Reply-To: <46debed1-8c0f-962b-f266-2aef25aa35d6@oracle.com>
References: <46debed1-8c0f-962b-f266-2aef25aa35d6@oracle.com>
Message-ID: <9a25ed50-207f-9347-b791-445c990da445@oracle.com>

Looks OK to me.

Naoto

On 10/9/18 11:19 PM, Ying Zhou wrote:
> Hello,
> 
> test/java/util/Locale/LocaleCategory.sh
> test/java/util/Locale/LocaleProviders.sh
> 
> Please review this patch to refactor above shell script tests to java.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8210403
> 
> webrev: http://cr.openjdk.java.net/~dzhou/8210403/webrev.00/ 
> <http://cr.openjdk.java.net/%7Edzhou/8210403/webrev.00/>
> 
> Thanks,
> 
> Daisy
> 

From naoto.sato at oracle.com  Fri Oct 12 21:38:33 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 12 Oct 2018 14:38:33 -0700
Subject: <i18n dev> [12] RFR: 8211961: Broken link in java.util.Locale
Message-ID: <71a413c2-9efc-3d11-f72f-dc250944c805@oracle.com>

Hi,

Please review this simple doc fix to the following issue:

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

The proposed changeset is located at:

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

Although @link is preferred in the javadoc, it is currently not working 
for @serialField (JDK-6344777). Instead, "java.base" module name is 
prepended in the href as a workaround.

Naoto

From mandy.chung at oracle.com  Fri Oct 12 22:26:43 2018
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 Oct 2018 15:26:43 -0700
Subject: <i18n dev> [12] RFR: 8211961: Broken link in java.util.Locale
In-Reply-To: <71a413c2-9efc-3d11-f72f-dc250944c805@oracle.com>
References: <71a413c2-9efc-3d11-f72f-dc250944c805@oracle.com>
Message-ID: <7dcc3f70-b142-5bbe-4bbb-32bef7ed98a3@oracle.com>

+1

Mandy

On 10/12/18 2:38 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review this simple doc fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8211961
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8211961/webrev.01/
>
> Although @link is preferred in the javadoc, it is currently not 
> working for @serialField (JDK-6344777). Instead, "java.base" module 
> name is prepended in the href as a workaround.
>
> Naoto


From dan.z.zhou at oracle.com  Wed Oct 17 03:01:24 2018
From: dan.z.zhou at oracle.com (Dora Zhou)
Date: Wed, 17 Oct 2018 11:01:24 +0800
Subject: <i18n dev> [12]RFR 8210406: Refactor java.util.PluggableLocale:i18n
 shell tests to plain java tests
Message-ID: <7e8a5036-8d76-1dbf-2bee-b564229fc68b@oracle.com>

Hello,

Please help review the fix for refactor java.util.PluggableLocale:i18n 
shell tests to plain java tests. Thank you.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210406

webrev: http://cr.openjdk.java.net/~dzhou/8210406/webrev.02/

Regards,
Dora

From naoto.sato at oracle.com  Wed Oct 17 17:58:51 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 17 Oct 2018 10:58:51 -0700
Subject: <i18n dev> [12]RFR 8210406: Refactor
 java.util.PluggableLocale:i18n shell tests to plain java tests
In-Reply-To: <7e8a5036-8d76-1dbf-2bee-b564229fc68b@oracle.com>
References: <7e8a5036-8d76-1dbf-2bee-b564229fc68b@oracle.com>
Message-ID: <79e489b4-39ad-0325-2814-7f35c054fab8@oracle.com>

Looks good.

Naoto

On 10/16/18 8:01 PM, Dora Zhou wrote:
> Hello,
> 
> Please help review the fix for refactor java.util.PluggableLocale:i18n 
> shell tests to plain java tests. Thank you.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210406
> 
> webrev: http://cr.openjdk.java.net/~dzhou/8210406/webrev.02/
> 
> Regards,
> Dora

From ying.z.zhou at oracle.com  Tue Oct 23 06:16:06 2018
From: ying.z.zhou at oracle.com (Ying Zhou)
Date: Tue, 23 Oct 2018 14:16:06 +0800
Subject: <i18n dev> [12]RFR of JDK-8210407:Refactor java.util.Calendar:i18n
 shell tests to plain java tests
Message-ID: <acfad12b-86c8-d4ad-fede-d84059b06ed0@oracle.com>

Hello,

test/java/util/Calendar/SupplementalJapaneseEraTest.sh
test/java/util/Calendar/GenericTimeZoneNamesTest.sh
test/java/util/Calendar/NarrowNamesTest.sh

Please review this patch to refactor above shell script tests to java.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210407

Webrev: http://cr.openjdk.java.net/~dzhou/8210407/webrev.00/ 
<http://cr.openjdk.java.net/%7Edzhou/8210407/webrev.00/>

Thanks,

Daisy


From naoto.sato at oracle.com  Tue Oct 23 15:32:32 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 23 Oct 2018 08:32:32 -0700
Subject: <i18n dev> [12]RFR of JDK-8210407:Refactor
 java.util.Calendar:i18n shell tests to plain java tests
In-Reply-To: <acfad12b-86c8-d4ad-fede-d84059b06ed0@oracle.com>
References: <acfad12b-86c8-d4ad-fede-d84059b06ed0@oracle.com>
Message-ID: <45e6c7bf-9d1a-581a-b209-c5f6d739fa07@oracle.com>

Hi Daisy,

Looks good to me. Please add noreg-self label to the issue.

Naoto

On 10/22/18 11:16 PM, Ying Zhou wrote:
> Hello,
> 
> test/java/util/Calendar/SupplementalJapaneseEraTest.sh
> test/java/util/Calendar/GenericTimeZoneNamesTest.sh
> test/java/util/Calendar/NarrowNamesTest.sh
> 
> Please review this patch to refactor above shell script tests to java.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210407
> 
> Webrev: http://cr.openjdk.java.net/~dzhou/8210407/webrev.00/ 
> <http://cr.openjdk.java.net/%7Edzhou/8210407/webrev.00/>
> 
> Thanks,
> 
> Daisy
> 

From ramanand.patil at oracle.com  Fri Oct 26 18:30:02 2018
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Fri, 26 Oct 2018 11:30:02 -0700 (PDT)
Subject: <i18n dev> RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f
Message-ID: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default>

Hi all,
Please review the latest TZDATA integration (tzdata2018f) into JDK12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8213016
Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/

All the TimeZone related tests are passed after integration.

Note:
The used tzdata files are from the rearguard version of the tzdata2018f release with the patch applied given by the IANA maintainers[1].
This is done to avoid the value "25:00" from the Japanese ZoneRule. But, as proposed by Stephen[2], a fix from JDK side is also required which will be tracked via a new bug [3].

[1] https://mm.icann.org/pipermail/tz/2018-October/027032.html
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056167.html
[3] https://bugs.openjdk.java.net/browse/JDK-8212970


Regards,
Ramanand.

From martinrb at google.com  Fri Oct 26 19:38:49 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 26 Oct 2018 12:38:49 -0700
Subject: <i18n dev> RFR: 8213016: (tz) Upgrade time-zone data to
	tzdata2018f
In-Reply-To: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default>
References: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default>
Message-ID: <CA+kOe0_gBewead25DF=Yy0YzhstNtOFOrD7BuDtgAYq0Q=3SUQ@mail.gmail.com>

Looks good to me.

On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil <ramanand.patil at oracle.com>
wrote:

> Hi all,
> Please review the latest TZDATA integration (tzdata2018f) into JDK12.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213016
> Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/
>
> All the TimeZone related tests are passed after integration.
>
> Note:
> The used tzdata files are from the rearguard version of the tzdata2018f
> release with the patch applied given by the IANA maintainers[1].
> This is done to avoid the value "25:00" from the Japanese ZoneRule. But,
> as proposed by Stephen[2], a fix from JDK side is also required which will
> be tracked via a new bug [3].
>
> [1] https://mm.icann.org/pipermail/tz/2018-October/027032.html
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
> October/056167.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8212970
>
>
> Regards,
> Ramanand.
>

From naoto.sato at oracle.com  Fri Oct 26 20:10:56 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 26 Oct 2018 13:10:56 -0700
Subject: <i18n dev> RFR: 8213016: (tz) Upgrade time-zone data to
 tzdata2018f
In-Reply-To: <CA+kOe0_gBewead25DF=Yy0YzhstNtOFOrD7BuDtgAYq0Q=3SUQ@mail.gmail.com>
References: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default>
 <CA+kOe0_gBewead25DF=Yy0YzhstNtOFOrD7BuDtgAYq0Q=3SUQ@mail.gmail.com>
Message-ID: <aff401f8-1491-e16d-44d5-939fcf139130@oracle.com>

+1

Naoto

On 10/26/18 12:38 PM, Martin Buchholz wrote:
> Looks good to me.
> 
> On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil <ramanand.patil at oracle.com>
> wrote:
> 
>> Hi all,
>> Please review the latest TZDATA integration (tzdata2018f) into JDK12.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213016
>> Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/
>>
>> All the TimeZone related tests are passed after integration.
>>
>> Note:
>> The used tzdata files are from the rearguard version of the tzdata2018f
>> release with the patch applied given by the IANA maintainers[1].
>> This is done to avoid the value "25:00" from the Japanese ZoneRule. But,
>> as proposed by Stephen[2], a fix from JDK side is also required which will
>> be tracked via a new bug [3].
>>
>> [1] https://mm.icann.org/pipermail/tz/2018-October/027032.html
>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
>> October/056167.html
>> [3] https://bugs.openjdk.java.net/browse/JDK-8212970
>>
>>
>> Regards,
>> Ramanand.
>>

From naoto.sato at oracle.com  Fri Oct 26 21:00:12 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 26 Oct 2018 14:00:12 -0700
Subject: <i18n dev> [12] RFR: 8212941: Loosen the range of JapaneseEra
Message-ID: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed fix and CSR (not approved yet) are located at:

http://cr.openjdk.java.net/~naoto/8212941/webrev.02/
https://bugs.openjdk.java.net/browse/JDK-8212942

This change is intended to loosen the spec of JapaneseEra so that later 
era additions won't require unnecessary spec changes. This is 
particularly important for the maintenance releases.

Naoto

From joe.darcy at oracle.com  Fri Oct 26 22:00:14 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 26 Oct 2018 15:00:14 -0700
Subject: <i18n dev> [12] RFR: 8212941: Loosen the range of JapaneseEra
In-Reply-To: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com>
References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com>
Message-ID: <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com>

Hi Naoto,

I'd like to see a bit some discussion up front about the expected 
evolution of this class.

For example, "once an era is defined, subsequent versions of the API 
will add a constant for it. etc. Eras are expected to have consecutive 
integers associated with them, etc. "

Once a formal name is added for the new era, will that value be serial 
equivalent to the current new era value being used in the class? 
Basically, is the name or the int value the basis of the serial identity 
of a JapaneseEra object?

Thanks,

-Joe


On 10/26/2018 2:00 PM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8212941
>
> The proposed fix and CSR (not approved yet) are located at:
>
> http://cr.openjdk.java.net/~naoto/8212941/webrev.02/
> https://bugs.openjdk.java.net/browse/JDK-8212942
>
> This change is intended to loosen the spec of JapaneseEra so that 
> later era additions won't require unnecessary spec changes. This is 
> particularly important for the maintenance releases.
>
> Naoto


From naoto.sato at oracle.com  Fri Oct 26 22:47:02 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 26 Oct 2018 15:47:02 -0700
Subject: <i18n dev> [12] RFR: 8212941: Loosen the range of JapaneseEra
In-Reply-To: <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com>
References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com>
 <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com>
Message-ID: <f2f77499-6acf-ccea-462d-008573afcf50@oracle.com>

Hi Joe,

On 10/26/18 3:00 PM, joe darcy wrote:
> Hi Naoto,
> 
> I'd like to see a bit some discussion up front about the expected 
> evolution of this class.
> 
> For example, "once an era is defined, subsequent versions of the API 
> will add a constant for it. etc. Eras are expected to have consecutive 
> integers associated with them, etc. "

Thanks. Those will clarify the intention of the change more. Will 
incorporate them.

> 
> Once a formal name is added for the new era, will that value be serial 
> equivalent to the current new era value being used in the class? 
> Basically, is the name or the int value the basis of the serial identity 
> of a JapaneseEra object?

Yes to the former question. The "NewEra" era should be equivalent to 
what's coming after the name is decided. Thus the int value should be 
the sole identity for the designated era. This will ensure the 
maintenance releases which cannot backport public singleton instances 
work without spec change.

Naoto

> 
> Thanks,
> 
> -Joe
> 
> 
> On 10/26/2018 2:00 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8212941
>>
>> The proposed fix and CSR (not approved yet) are located at:
>>
>> http://cr.openjdk.java.net/~naoto/8212941/webrev.02/
>> https://bugs.openjdk.java.net/browse/JDK-8212942
>>
>> This change is intended to loosen the spec of JapaneseEra so that 
>> later era additions won't require unnecessary spec changes. This is 
>> particularly important for the maintenance releases.
>>
>> Naoto
> 

From ying.z.zhou at oracle.com  Mon Oct 29 06:55:37 2018
From: ying.z.zhou at oracle.com (Ying Zhou)
Date: Mon, 29 Oct 2018 14:55:37 +0800
Subject: <i18n dev> [12]RFR of JDK-8210409:Refactor java.util.TimeZone:i18n
 shell tests to plain java tests
Message-ID: <48e78d51-dfd6-229f-5ee9-f020d6e11d20@oracle.com>

Hello,

test/jdk/java/util/TimeZone/OldIDMappingTest.sh
test/jdk/java/util/TimeZone/Bug8066652.sh
test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheck.sh

Please review this patch to refactor above shell script tests to java.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210409

Webrev: http://cr.openjdk.java.net/~dzhou/8210409/webrev.00/ 
<http://cr.openjdk.java.net/%7Edzhou/8210409/webrev.00/>

Thanks,

Daisy



From ramanand.patil at oracle.com  Mon Oct 29 08:13:03 2018
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 29 Oct 2018 01:13:03 -0700 (PDT)
Subject: <i18n dev> RFR: 8213016: (tz) Upgrade time-zone data to
 tzdata2018f
In-Reply-To: <aff401f8-1491-e16d-44d5-939fcf139130@oracle.com>
References: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default>
 <CA+kOe0_gBewead25DF=Yy0YzhstNtOFOrD7BuDtgAYq0Q=3SUQ@mail.gmail.com>
 <aff401f8-1491-e16d-44d5-939fcf139130@oracle.com>
Message-ID: <305200cf-33ec-47dc-9882-0020f518199a@default>

Thank you Martin and Naoto for your reviews.
Unfortunately, I have to discard this review and start a new review for tzdata2018g, since 2018g is already released now.

Regards,
Ramanand.

> -----Original Message-----
> From: Naoto Sato
> Sent: Saturday, October 27, 2018 1:41 AM
> To: Martin Buchholz <martinrb at google.com>; Ramanand Patil
> <ramanand.patil at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev <i18n-
> dev at openjdk.java.net>
> Subject: Re: <i18n dev> RFR: 8213016: (tz) Upgrade time-zone data to
> tzdata2018f
> 
> +1
> 
> Naoto
> 
> On 10/26/18 12:38 PM, Martin Buchholz wrote:
> > Looks good to me.
> >
> > On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil
> > <ramanand.patil at oracle.com>
> > wrote:
> >
> >> Hi all,
> >> Please review the latest TZDATA integration (tzdata2018f) into JDK12.
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213016
> >> Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/
> >>
> >> All the TimeZone related tests are passed after integration.
> >>
> >> Note:
> >> The used tzdata files are from the rearguard version of the
> >> tzdata2018f release with the patch applied given by the IANA
> maintainers[1].
> >> This is done to avoid the value "25:00" from the Japanese ZoneRule.
> >> But, as proposed by Stephen[2], a fix from JDK side is also required
> >> which will be tracked via a new bug [3].
> >>
> >> [1] https://mm.icann.org/pipermail/tz/2018-October/027032.html
> >> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
> >> October/056167.html
> >> [3] https://bugs.openjdk.java.net/browse/JDK-8212970
> >>
> >>
> >> Regards,
> >> Ramanand.
> >>

From ramanand.patil at oracle.com  Mon Oct 29 15:19:07 2018
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 29 Oct 2018 08:19:07 -0700 (PDT)
Subject: <i18n dev> RFR: 8213085: (tz) Upgrade time-zone data to tzdata2018g
Message-ID: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default>

Hi all,
Please review the latest TZDATA integration (tzdata2018g) into JDK12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8213085
Webrev: http://cr.openjdk.java.net/~rpatil/8213085/webrev.00/

All the TimeZone related tests are passed after integration.


Regards,
Ramanand.

From martinrb at google.com  Mon Oct 29 15:58:44 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Oct 2018 08:58:44 -0700
Subject: <i18n dev> RFR: 8213085: (tz) Upgrade time-zone data to
	tzdata2018g
In-Reply-To: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default>
References: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default>
Message-ID: <CA+kOe08GSx-9NhUBs1x0qy1DQX7k8LVbCEm9dhoJoFij2k0v-A@mail.gmail.com>

LGTM.

On Mon, Oct 29, 2018 at 8:19 AM, Ramanand Patil <ramanand.patil at oracle.com>
wrote:

> Hi all,
> Please review the latest TZDATA integration (tzdata2018g) into JDK12.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213085
> Webrev: http://cr.openjdk.java.net/~rpatil/8213085/webrev.00/
>
> All the TimeZone related tests are passed after integration.
>
>
> Regards,
> Ramanand.
>

From naoto.sato at oracle.com  Mon Oct 29 17:10:55 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 29 Oct 2018 10:10:55 -0700
Subject: <i18n dev> RFR: 8213085: (tz) Upgrade time-zone data to
 tzdata2018g
In-Reply-To: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default>
References: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default>
Message-ID: <c4a4b5ec-21e6-8b29-e68f-ad206271d6df@oracle.com>

Looks good. Thanks for catching up with it quickly.

Naoto

On 10/29/18 8:19 AM, Ramanand Patil wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2018g) into JDK12.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213085
> Webrev: http://cr.openjdk.java.net/~rpatil/8213085/webrev.00/
> 
> All the TimeZone related tests are passed after integration.
> 
> 
> Regards,
> Ramanand.
> 

From naoto.sato at oracle.com  Mon Oct 29 17:12:40 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 29 Oct 2018 10:12:40 -0700
Subject: <i18n dev> [12]RFR of JDK-8210409:Refactor
 java.util.TimeZone:i18n shell tests to plain java tests
In-Reply-To: <48e78d51-dfd6-229f-5ee9-f020d6e11d20@oracle.com>
References: <48e78d51-dfd6-229f-5ee9-f020d6e11d20@oracle.com>
Message-ID: <291fdd4d-f7b4-3cdb-67ec-65448da763e3@oracle.com>

Looks good.

Naoto

On 10/28/18 11:55 PM, Ying Zhou wrote:
> Hello,
> 
> test/jdk/java/util/TimeZone/OldIDMappingTest.sh
> test/jdk/java/util/TimeZone/Bug8066652.sh
> test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheck.sh
> 
> Please review this patch to refactor above shell script tests to java.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210409
> 
> Webrev: http://cr.openjdk.java.net/~dzhou/8210409/webrev.00/ 
> <http://cr.openjdk.java.net/%7Edzhou/8210409/webrev.00/>
> 
> Thanks,
> 
> Daisy
> 
> 

From naoto.sato at oracle.com  Tue Oct 30 16:29:03 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 30 Oct 2018 09:29:03 -0700
Subject: <i18n dev> [12] RFR: 8212941: Loosen the range of JapaneseEra
In-Reply-To: <f2f77499-6acf-ccea-462d-008573afcf50@oracle.com>
References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com>
 <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com>
 <f2f77499-6acf-ccea-462d-008573afcf50@oracle.com>
Message-ID: <fbe19035-7806-16c7-462d-e3af794c88df@oracle.com>

Updated the webrev. Please review.

http://cr.openjdk.java.net/~naoto/8212941/webrev.03/

Naoto

On 10/26/18 3:47 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
> 
> On 10/26/18 3:00 PM, joe darcy wrote:
>> Hi Naoto,
>>
>> I'd like to see a bit some discussion up front about the expected 
>> evolution of this class.
>>
>> For example, "once an era is defined, subsequent versions of the API 
>> will add a constant for it. etc. Eras are expected to have consecutive 
>> integers associated with them, etc. "
> 
> Thanks. Those will clarify the intention of the change more. Will 
> incorporate them.
> 
>>
>> Once a formal name is added for the new era, will that value be serial 
>> equivalent to the current new era value being used in the class? 
>> Basically, is the name or the int value the basis of the serial 
>> identity of a JapaneseEra object?
> 
> Yes to the former question. The "NewEra" era should be equivalent to 
> what's coming after the name is decided. Thus the int value should be 
> the sole identity for the designated era. This will ensure the 
> maintenance releases which cannot backport public singleton instances 
> work without spec change.
> 
> Naoto
> 
>>
>> Thanks,
>>
>> -Joe
>>
>>
>> On 10/26/2018 2:00 PM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8212941
>>>
>>> The proposed fix and CSR (not approved yet) are located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8212941/webrev.02/
>>> https://bugs.openjdk.java.net/browse/JDK-8212942
>>>
>>> This change is intended to loosen the spec of JapaneseEra so that 
>>> later era additions won't require unnecessary spec changes. This is 
>>> particularly important for the maintenance releases.
>>>
>>> Naoto
>>