From nishit.jain at oracle.com  Fri Dec  1 08:17:16 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 1 Dec 2017 13:47:16 +0530
Subject: <i18n dev> [10] RFR 8187551: MessageFormat.setFormat(int,
 Format) AIOOBE not thrown when documented
Message-ID: <53f445ff-a4b3-5029-77f0-45125514a662@oracle.com>

Hi,

Please review the fix for JDK-8187551.

Bug: https://bugs.openjdk.java.net/browse/JDK-8187551
Webrev: http://cr.openjdk.java.net/~nishjain/8187551/webrev.02/

Fix: As documented, updated MessageFormat.setFormat() to throw AIOOBE 
with invalid format element index.

Thanks Martin Buchholz for filing the issue and suggesting the fix.

Regards,
Nishit Jain

From nishit.jain at oracle.com  Mon Dec  4 06:36:11 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 4 Dec 2017 12:06:11 +0530
Subject: <i18n dev> [10] RFR 8187551: MessageFormat.setFormat(int,
 Format) AIOOBE not thrown when documented
In-Reply-To: <da9b20cb-0df7-f3b4-516b-1fab3c5f9b5f@Oracle.com>
References: <53f445ff-a4b3-5029-77f0-45125514a662@oracle.com>
 <da9b20cb-0df7-f3b4-516b-1fab3c5f9b5f@Oracle.com>
Message-ID: <f053d917-a309-433c-64f8-332f2d886252@oracle.com>

Thanks Roger,

Updated the webrevto add the new test case in MessageRegression.java

http://cr.openjdk.java.net/~nishjain/8187551/webrev.03/

Regards,
Nishit Jain
On 01-12-2017 20:40, Roger Riggs wrote:
> Hi Nishit,
>
> Please add the new test to 
> test/jdk/java/text/Format/MessageFormat/MessageRegression.java instead
> of creating a new test.
>
> Also the convention for test names should be a functional description 
> of the test; bug numbers are uninformative.
>
> (I'm a bit surprised there are few/no regression tests for setFormat).
>
> Thanks, Roger
>
>
> On 12/1/2017 3:17 AM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8187551.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187551
>> Webrev: http://cr.openjdk.java.net/~nishjain/8187551/webrev.02/
>>
>> Fix: As documented, updated MessageFormat.setFormat() to throw AIOOBE 
>> with invalid format element index.
>>
>> Thanks Martin Buchholz for filing the issue and suggesting the fix.
>>
>> Regards,
>> Nishit Jain
>


From Roger.Riggs at Oracle.com  Mon Dec  4 14:57:33 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 4 Dec 2017 09:57:33 -0500
Subject: <i18n dev> [10] RFR 8187551: MessageFormat.setFormat(int,
 Format) AIOOBE not thrown when documented
In-Reply-To: <f053d917-a309-433c-64f8-332f2d886252@oracle.com>
References: <53f445ff-a4b3-5029-77f0-45125514a662@oracle.com>
 <da9b20cb-0df7-f3b4-516b-1fab3c5f9b5f@Oracle.com>
 <f053d917-a309-433c-64f8-332f2d886252@oracle.com>
Message-ID: <8b4c1d9b-95e2-a8ac-1879-e3352a668107@Oracle.com>

Hi Nishit,

Looks good,

Thanks, Roger

On 12/4/2017 1:36 AM, Nishit Jain wrote:
> Thanks Roger,
>
> Updated the webrevto add the new test case in MessageRegression.java
>
> http://cr.openjdk.java.net/~nishjain/8187551/webrev.03/
>
> Regards,
> Nishit Jain
> On 01-12-2017 20:40, Roger Riggs wrote:
>> Hi Nishit,
>>
>> Please add the new test to 
>> test/jdk/java/text/Format/MessageFormat/MessageRegression.java instead
>> of creating a new test.
>>
>> Also the convention for test names should be a functional description 
>> of the test; bug numbers are uninformative.
>>
>> (I'm a bit surprised there are few/no regression tests for setFormat).
>>
>> Thanks, Roger
>>
>>
>> On 12/1/2017 3:17 AM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8187551.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187551
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8187551/webrev.02/
>>>
>>> Fix: As documented, updated MessageFormat.setFormat() to throw 
>>> AIOOBE with invalid format element index.
>>>
>>> Thanks Martin Buchholz for filing the issue and suggesting the fix.
>>>
>>> Regards,
>>> Nishit Jain
>>
>


From naoto.sato at oracle.com  Mon Dec  4 17:06:36 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 4 Dec 2017 09:06:36 -0800
Subject: <i18n dev> [10] RFR 8187551: MessageFormat.setFormat(int,
 Format) AIOOBE not thrown when documented
In-Reply-To: <f053d917-a309-433c-64f8-332f2d886252@oracle.com>
References: <53f445ff-a4b3-5029-77f0-45125514a662@oracle.com>
 <da9b20cb-0df7-f3b4-516b-1fab3c5f9b5f@Oracle.com>
 <f053d917-a309-433c-64f8-332f2d886252@oracle.com>
Message-ID: <7dde3e8f-cfe2-5776-16e7-d4da9d676620@oracle.com>

+1

Naoto

On 12/3/17 10:36 PM, Nishit Jain wrote:
> Thanks Roger,
> 
> Updated the webrevto add the new test case in MessageRegression.java
> 
> http://cr.openjdk.java.net/~nishjain/8187551/webrev.03/
> 
> Regards,
> Nishit Jain
> On 01-12-2017 20:40, Roger Riggs wrote:
>> Hi Nishit,
>>
>> Please add the new test to 
>> test/jdk/java/text/Format/MessageFormat/MessageRegression.java instead
>> of creating a new test.
>>
>> Also the convention for test names should be a functional description 
>> of the test; bug numbers are uninformative.
>>
>> (I'm a bit surprised there are few/no regression tests for setFormat).
>>
>> Thanks, Roger
>>
>>
>> On 12/1/2017 3:17 AM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8187551.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187551
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8187551/webrev.02/
>>>
>>> Fix: As documented, updated MessageFormat.setFormat() to throw AIOOBE 
>>> with invalid format element index.
>>>
>>> Thanks Martin Buchholz for filing the issue and suggesting the fix.
>>>
>>> Regards,
>>> Nishit Jain
>>
> 

From peter.levart at gmail.com  Wed Dec  6 14:10:04 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 6 Dec 2017 15:10:04 +0100
Subject: <i18n dev> RFR 8191216: SimpleTimeZone.clone() has a data race
 on cache fields
In-Reply-To: <9dbdf9bc-e93a-6ac4-d3ae-5168fd365403@oracle.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
 <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
 <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>
 <017c44ce-a3e2-a03d-d437-98e08655a6a1@gmail.com>
 <d86e99d1-75c9-8c6e-d5ac-57b4cbff8431@oracle.com>
 <fc40bb10-c28c-70db-6496-11eab8b0c449@gmail.com>
 <3bf0ce49-cb3d-f70b-717d-03680b001d3b@oracle.com>
 <9dbdf9bc-e93a-6ac4-d3ae-5168fd365403@oracle.com>
Message-ID: <c394ad4d-c9b8-ccc1-bd84-cc0700c1d48e@gmail.com>

Hi,

On 12/06/2017 02:30 PM, Alan Bateman wrote:
> I think this class is normally maintained on i18n-dev but I think 
> introducing the Cache object looks good and making this much easier to 
> understand.
>
> -Alan 

Thanks Alan, I'm forwarding to i18n-dev to see if maintainers of that 
part of JDK have any comments...

This is an official request for reviewing a patch for fixing a data race 
between cloning a SimpleTimeZone object and lazily initializing its 3 
cache fields which may produce a clone with inconsistent cache state. 
Here's Jira issue with details:

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

Venkat has proposed to simply call invalidateCache() on the clone before 
returning it from SimpleTimeZone.clone() method:

 ??? public Object clone()
 ??? {
 ??????? SimpleTimeZone clone = (SimpleTimeZone) super.clone();
 ??????? clone.invalidateCache();
 ??????? return clone;
 ??? }

This fixes the issue and for the case of TimeZone.getDefault() which is 
called from ZoneId.systemDefault() even elides synchronization in 
clone.invalidateCache() and allocation of the clone, so JITed 
ZoneId.systemDefault() is unaffected by the patch. Initially I was 
satisfied with the fix, but then I tested something. Suppose someone 
sets default zone to SimpleTimeZone:

 ??????? TimeZone.setDefault(
 ??????????? new SimpleTimeZone(3600000,
 ?????????????????????????????? "Europe/Paris",
 ?????????????????????????????? Calendar.MARCH, -1, Calendar.SUNDAY,
 ?????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
 ?????????????????????????????? Calendar.OCTOBER, -1, Calendar.SUNDAY,
 ?????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
 ?????????????????????????????? 3600000)
 ??????? );

And then calls some methods that initialize the cache of the internal 
shared TimeZone.defaultTimeZone instance:

 ??? new Date().toString();

The code which after that tries to obtain default time zone and 
calculate the offset from UTC at some current point in time, for example:

 ??? TimeZone.getDefault().getOffset(now)

can't use the cached state because it has been invalidated in the 
returned clone. Such code has to re-compute the offset every time it 
gets new clone. I measured this with a JMH benchmark and got the 
following result:

Default:

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op

Venkat's patch - invalidateCache():

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 179,476 ? 1,942? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,538 ? 0,073? ns/op

We see that ZoneId.systemDefault() is unaffected, but 
TimeZone.getDefault().getOffset(now) becomes 3x slower.

This is not good, so I tried an alternative fix for the issue - simply 
making the SimpleTimeZone.clone() synchronized. Access to cache fields 
is already synchronized, so this should fix the race. Here's the JMH result:

Default:

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op

Synchronized clone():

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 58,103 ? 0,936? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 4,154 ? 0,034? ns/op

We see that caching works again, but synchronization has some overhead 
which is not big for single-threaded access, but might get bigger when 
multiple threads try to get default zone concurrently.

So I created a 3rd variant of the fix which I'm presenting here and 
requesting a review for:

http://cr.openjdk.java.net/~plevart/jdk10-dev/8191216_SimpleTimeZone_clone_race/webrev.01/

The JMH benchmark shows this:

Default:

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op

Cache object:

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 42,860 ? 0,274? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,545 ? 0,057? ns/op

Not only does the fix not affect ZoneId.systemDefault() which is not 
surprising, but it also speeds-up cache lookup in single-threaded 
benchmark and certainly eliminates possible contention among threads 
looking up the shared instance.

I have run the test/jdk/java/util/TimeZone and 
test/jdk/java/util/Calendar jtreg tests and there were 7 failures caused 
by compilation errors (package sun.util.locale.provider is not visible), 
while 59 other tests pass.

So, what do you think?

Regards, Peter


Venkateswara R Chintala je 21. 11. 2017 ob 10:14?napisal:
> Thanks Peter for sponsoring this patch. Is there anything else that 
> needs to be done from my end for this patch to be integrated? Please 
> let me know.
>
> -Venkat
>
>
> On 14/11/17 8:46 PM, Peter Levart wrote:
>> Hi Venkat,
>>
>> I created the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191216
>>
>> I can also sponsor this patch and push it for JDK 10.
>>
>> The patch that you are proposing looks good to me. Does anybody have 
>> anything else to say?
>>
>> Regards, Peter
>>
>>
>> On 11/13/2017 11:28 AM, Venkateswara R Chintala wrote:
>>> Thanks David, Peter for your review and comments. As I am new to the 
>>> community, can you please help me to open a bug and integrate the 
>>> changes into code base?
>>>
>>> -Venkat
>>>
>>> On 12/11/17 2:19 AM, Peter Levart wrote:
>>>> Hi David, Venkat,
>>>>
>>>> On 11/11/17 21:15, Peter Levart wrote:
>>>>> For example, take the following method:
>>>>>
>>>>> String defaultTZID() {
>>>>> ??? return TimeZone.getDefault().getID();
>>>>> }
>>>>>
>>>>> When JIT compiles it and inlines invocations to other methods 
>>>>> within it, it can prove that cloned TimeZone instance never 
>>>>> escapes the call to defaultTZID() and can therefore skip 
>>>>> allocating the instance on heap.
>>>>>
>>>>> But this is fragile. If code in invoked methods changes, they may 
>>>>> not get inlined or EA may not be able to prove that the cloned 
>>>>> instance can't escape and allocation may be introduced. 
>>>>> ZoneId.systemDefault() is a hot method and it would be nice if we 
>>>>> manage to keep it allocation free.
>>>>
>>>> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>>>>
>>>> ??? public Object clone()
>>>> ??? {
>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>> ??????? // like tz.invalidateCache() but without holding a lock on 
>>>> clone
>>>> ??????? tz.cacheYear = tz.startYear - 1;
>>>> ??????? tz.cacheStart = tz.cacheEnd = 0;
>>>> ??????? return tz;
>>>> ??? }
>>>>
>>>>
>>>> ...and the JMH benchmark with gc profiling shows that 
>>>> ZoneId.systemDefault() still manages to get JIT-compiled without 
>>>> introducing allocation.
>>>>
>>>> Even the following (original Venkat's) patch:
>>>>
>>>> ??? public Object clone()
>>>> ??? {
>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>> ??????? tz.invalidateCache();
>>>> ??????? return tz;
>>>> ??? }
>>>>
>>>> ...does the same and the locking in invalidateCache() is elided 
>>>> too. Allocation and lock-elision go hand-in-hand. When object 
>>>> doesn't escape, allocation on heap may be eliminated and locks on 
>>>> that instance elided.
>>>>
>>>> So this is better than synchronizing on the original instance 
>>>> during .clone() execution as it has potential to avoid locking 
>>>> overhead.
>>>>
>>>> So Venkat, go ahead. My fear was unjustified.
>>>>
>>>> Regards, Peter
>>>>
>>>
>>
>>
>

From naoto.sato at oracle.com  Wed Dec  6 19:41:41 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 6 Dec 2017 11:41:41 -0800
Subject: <i18n dev> RFR 8191216: SimpleTimeZone.clone() has a data race
 on cache fields
In-Reply-To: <c394ad4d-c9b8-ccc1-bd84-cc0700c1d48e@gmail.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
 <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
 <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>
 <017c44ce-a3e2-a03d-d437-98e08655a6a1@gmail.com>
 <d86e99d1-75c9-8c6e-d5ac-57b4cbff8431@oracle.com>
 <fc40bb10-c28c-70db-6496-11eab8b0c449@gmail.com>
 <3bf0ce49-cb3d-f70b-717d-03680b001d3b@oracle.com>
 <9dbdf9bc-e93a-6ac4-d3ae-5168fd365403@oracle.com>
 <c394ad4d-c9b8-ccc1-bd84-cc0700c1d48e@gmail.com>
Message-ID: <86b95ce3-2acd-8fda-77cf-222f957ac687@oracle.com>

Hi Peter, Venkat,

Thank you for the fix. It looks good to me. Improved performance is a 
nice bonus! Would you be able to provide with a regression test?

Naoto

On 12/6/17 6:10 AM, Peter Levart wrote:
> Hi,
> 
> On 12/06/2017 02:30 PM, Alan Bateman wrote:
>> I think this class is normally maintained on i18n-dev but I think 
>> introducing the Cache object looks good and making this much easier to 
>> understand.
>>
>> -Alan 
> 
> Thanks Alan, I'm forwarding to i18n-dev to see if maintainers of that 
> part of JDK have any comments...
> 
> This is an official request for reviewing a patch for fixing a data race 
> between cloning a SimpleTimeZone object and lazily initializing its 3 
> cache fields which may produce a clone with inconsistent cache state. 
> Here's Jira issue with details:
> 
> https://bugs.openjdk.java.net/browse/JDK-8191216
> 
> Venkat has proposed to simply call invalidateCache() on the clone before 
> returning it from SimpleTimeZone.clone() method:
> 
>  ??? public Object clone()
>  ??? {
>  ??????? SimpleTimeZone clone = (SimpleTimeZone) super.clone();
>  ??????? clone.invalidateCache();
>  ??????? return clone;
>  ??? }
> 
> This fixes the issue and for the case of TimeZone.getDefault() which is 
> called from ZoneId.systemDefault() even elides synchronization in 
> clone.invalidateCache() and allocation of the clone, so JITed 
> ZoneId.systemDefault() is unaffected by the patch. Initially I was 
> satisfied with the fix, but then I tested something. Suppose someone 
> sets default zone to SimpleTimeZone:
> 
>  ??????? TimeZone.setDefault(
>  ??????????? new SimpleTimeZone(3600000,
>  ?????????????????????????????? "Europe/Paris",
>  ?????????????????????????????? Calendar.MARCH, -1, Calendar.SUNDAY,
>  ?????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
>  ?????????????????????????????? Calendar.OCTOBER, -1, Calendar.SUNDAY,
>  ?????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
>  ?????????????????????????????? 3600000)
>  ??????? );
> 
> And then calls some methods that initialize the cache of the internal 
> shared TimeZone.defaultTimeZone instance:
> 
>  ??? new Date().toString();
> 
> The code which after that tries to obtain default time zone and 
> calculate the offset from UTC at some current point in time, for example:
> 
>  ??? TimeZone.getDefault().getOffset(now)
> 
> can't use the cached state because it has been invalidated in the 
> returned clone. Such code has to re-compute the offset every time it 
> gets new clone. I measured this with a JMH benchmark and got the 
> following result:
> 
> Default:
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op
> 
> Venkat's patch - invalidateCache():
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 179,476 ? 1,942? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,538 ? 0,073? ns/op
> 
> We see that ZoneId.systemDefault() is unaffected, but 
> TimeZone.getDefault().getOffset(now) becomes 3x slower.
> 
> This is not good, so I tried an alternative fix for the issue - simply 
> making the SimpleTimeZone.clone() synchronized. Access to cache fields 
> is already synchronized, so this should fix the race. Here's the JMH 
> result:
> 
> Default:
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op
> 
> Synchronized clone():
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 58,103 ? 0,936? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 4,154 ? 0,034? ns/op
> 
> We see that caching works again, but synchronization has some overhead 
> which is not big for single-threaded access, but might get bigger when 
> multiple threads try to get default zone concurrently.
> 
> So I created a 3rd variant of the fix which I'm presenting here and 
> requesting a review for:
> 
> http://cr.openjdk.java.net/~plevart/jdk10-dev/8191216_SimpleTimeZone_clone_race/webrev.01/ 
> 
> 
> The JMH benchmark shows this:
> 
> Default:
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op
> 
> Cache object:
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 42,860 ? 0,274? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,545 ? 0,057? ns/op
> 
> Not only does the fix not affect ZoneId.systemDefault() which is not 
> surprising, but it also speeds-up cache lookup in single-threaded 
> benchmark and certainly eliminates possible contention among threads 
> looking up the shared instance.
> 
> I have run the test/jdk/java/util/TimeZone and 
> test/jdk/java/util/Calendar jtreg tests and there were 7 failures caused 
> by compilation errors (package sun.util.locale.provider is not visible), 
> while 59 other tests pass.
> 
> So, what do you think?
> 
> Regards, Peter
> 
> 
> Venkateswara R Chintala je 21. 11. 2017 ob 10:14?napisal:
>> Thanks Peter for sponsoring this patch. Is there anything else that 
>> needs to be done from my end for this patch to be integrated? Please 
>> let me know.
>>
>> -Venkat
>>
>>
>> On 14/11/17 8:46 PM, Peter Levart wrote:
>>> Hi Venkat,
>>>
>>> I created the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8191216
>>>
>>> I can also sponsor this patch and push it for JDK 10.
>>>
>>> The patch that you are proposing looks good to me. Does anybody have 
>>> anything else to say?
>>>
>>> Regards, Peter
>>>
>>>
>>> On 11/13/2017 11:28 AM, Venkateswara R Chintala wrote:
>>>> Thanks David, Peter for your review and comments. As I am new to the 
>>>> community, can you please help me to open a bug and integrate the 
>>>> changes into code base?
>>>>
>>>> -Venkat
>>>>
>>>> On 12/11/17 2:19 AM, Peter Levart wrote:
>>>>> Hi David, Venkat,
>>>>>
>>>>> On 11/11/17 21:15, Peter Levart wrote:
>>>>>> For example, take the following method:
>>>>>>
>>>>>> String defaultTZID() {
>>>>>> ??? return TimeZone.getDefault().getID();
>>>>>> }
>>>>>>
>>>>>> When JIT compiles it and inlines invocations to other methods 
>>>>>> within it, it can prove that cloned TimeZone instance never 
>>>>>> escapes the call to defaultTZID() and can therefore skip 
>>>>>> allocating the instance on heap.
>>>>>>
>>>>>> But this is fragile. If code in invoked methods changes, they may 
>>>>>> not get inlined or EA may not be able to prove that the cloned 
>>>>>> instance can't escape and allocation may be introduced. 
>>>>>> ZoneId.systemDefault() is a hot method and it would be nice if we 
>>>>>> manage to keep it allocation free.
>>>>>
>>>>> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>>>>>
>>>>> ??? public Object clone()
>>>>> ??? {
>>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>>> ??????? // like tz.invalidateCache() but without holding a lock on 
>>>>> clone
>>>>> ??????? tz.cacheYear = tz.startYear - 1;
>>>>> ??????? tz.cacheStart = tz.cacheEnd = 0;
>>>>> ??????? return tz;
>>>>> ??? }
>>>>>
>>>>>
>>>>> ...and the JMH benchmark with gc profiling shows that 
>>>>> ZoneId.systemDefault() still manages to get JIT-compiled without 
>>>>> introducing allocation.
>>>>>
>>>>> Even the following (original Venkat's) patch:
>>>>>
>>>>> ??? public Object clone()
>>>>> ??? {
>>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>>> ??????? tz.invalidateCache();
>>>>> ??????? return tz;
>>>>> ??? }
>>>>>
>>>>> ...does the same and the locking in invalidateCache() is elided 
>>>>> too. Allocation and lock-elision go hand-in-hand. When object 
>>>>> doesn't escape, allocation on heap may be eliminated and locks on 
>>>>> that instance elided.
>>>>>
>>>>> So this is better than synchronizing on the original instance 
>>>>> during .clone() execution as it has potential to avoid locking 
>>>>> overhead.
>>>>>
>>>>> So Venkat, go ahead. My fear was unjustified.
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>
>>>
>>>
>>

From peter.levart at gmail.com  Sat Dec  9 22:33:04 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 9 Dec 2017 23:33:04 +0100
Subject: <i18n dev> RFR 8191216: SimpleTimeZone.clone() has a data race
 on cache fields
In-Reply-To: <86b95ce3-2acd-8fda-77cf-222f957ac687@oracle.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
 <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
 <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>
 <017c44ce-a3e2-a03d-d437-98e08655a6a1@gmail.com>
 <d86e99d1-75c9-8c6e-d5ac-57b4cbff8431@oracle.com>
 <fc40bb10-c28c-70db-6496-11eab8b0c449@gmail.com>
 <3bf0ce49-cb3d-f70b-717d-03680b001d3b@oracle.com>
 <9dbdf9bc-e93a-6ac4-d3ae-5168fd365403@oracle.com>
 <c394ad4d-c9b8-ccc1-bd84-cc0700c1d48e@gmail.com>
 <86b95ce3-2acd-8fda-77cf-222f957ac687@oracle.com>
Message-ID: <03df6d4c-2392-642f-7e9f-048459bd7cf8@gmail.com>

Hi Naoto,

Thank you for reviewing.

Naoto Sato je 06. 12. 2017 ob 20:41?napisal:
> Hi Peter, Venkat,
>
> Thank you for the fix. It looks good to me. Improved performance is a 
> nice bonus! Would you be able to provide with a regression test?

Sure, here it is:

http://cr.openjdk.java.net/~plevart/jdk10-dev/8191216_SimpleTimeZone_clone_race/webrev.02/


The test reliably detects several races in 2 seconds of runtime which 
cause incorrect offset calculations in JDK 9:

shared TZ: 7363986 correct, 0 incorrect calculations
cloned TZ: 3960264 correct, 1180 incorrect calculations
Exception in thread "main" java.lang.AssertionError: 1180 fatal data 
races detected
 ??? at 
SimpleTimeZoneCloneRaceTest.main(SimpleTimeZoneCloneRaceTest.java:86)

With patch applied, there are no failures of course.

Can this go into JDK 10 ?

Regards, Peter

>
> Naoto
>
> On 12/6/17 6:10 AM, Peter Levart wrote:
>> Hi,
>>
>> On 12/06/2017 02:30 PM, Alan Bateman wrote:
>>> I think this class is normally maintained on i18n-dev but I think 
>>> introducing the Cache object looks good and making this much easier 
>>> to understand.
>>>
>>> -Alan 
>>
>> Thanks Alan, I'm forwarding to i18n-dev to see if maintainers of that 
>> part of JDK have any comments...
>>
>> This is an official request for reviewing a patch for fixing a data 
>> race between cloning a SimpleTimeZone object and lazily initializing 
>> its 3 cache fields which may produce a clone with inconsistent cache 
>> state. Here's Jira issue with details:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191216
>>
>> Venkat has proposed to simply call invalidateCache() on the clone 
>> before returning it from SimpleTimeZone.clone() method:
>>
>> ???? public Object clone()
>> ???? {
>> ???????? SimpleTimeZone clone = (SimpleTimeZone) super.clone();
>> ???????? clone.invalidateCache();
>> ???????? return clone;
>> ???? }
>>
>> This fixes the issue and for the case of TimeZone.getDefault() which 
>> is called from ZoneId.systemDefault() even elides synchronization in 
>> clone.invalidateCache() and allocation of the clone, so JITed 
>> ZoneId.systemDefault() is unaffected by the patch. Initially I was 
>> satisfied with the fix, but then I tested something. Suppose someone 
>> sets default zone to SimpleTimeZone:
>>
>> ???????? TimeZone.setDefault(
>> ???????????? new SimpleTimeZone(3600000,
>> ??????????????????????????????? "Europe/Paris",
>> ??????????????????????????????? Calendar.MARCH, -1, Calendar.SUNDAY,
>> ??????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
>> ??????????????????????????????? Calendar.OCTOBER, -1, Calendar.SUNDAY,
>> ??????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
>> ??????????????????????????????? 3600000)
>> ???????? );
>>
>> And then calls some methods that initialize the cache of the internal 
>> shared TimeZone.defaultTimeZone instance:
>>
>> ???? new Date().toString();
>>
>> The code which after that tries to obtain default time zone and 
>> calculate the offset from UTC at some current point in time, for 
>> example:
>>
>> ???? TimeZone.getDefault().getOffset(now)
>>
>> can't use the cached state because it has been invalidated in the 
>> returned clone. Such code has to re-compute the offset every time it 
>> gets new clone. I measured this with a JMH benchmark and got the 
>> following result:
>>
>> Default:
>>
>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? 
>> ns/op
>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? 
>> ns/op
>>
>> Venkat's patch - invalidateCache():
>>
>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 179,476 ? 1,942? 
>> ns/op
>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,538 ? 0,073? 
>> ns/op
>>
>> We see that ZoneId.systemDefault() is unaffected, but 
>> TimeZone.getDefault().getOffset(now) becomes 3x slower.
>>
>> This is not good, so I tried an alternative fix for the issue - 
>> simply making the SimpleTimeZone.clone() synchronized. Access to 
>> cache fields is already synchronized, so this should fix the race. 
>> Here's the JMH result:
>>
>> Default:
>>
>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? 
>> ns/op
>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? 
>> ns/op
>>
>> Synchronized clone():
>>
>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 58,103 ? 0,936? 
>> ns/op
>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 4,154 ? 0,034? 
>> ns/op
>>
>> We see that caching works again, but synchronization has some 
>> overhead which is not big for single-threaded access, but might get 
>> bigger when multiple threads try to get default zone concurrently.
>>
>> So I created a 3rd variant of the fix which I'm presenting here and 
>> requesting a review for:
>>
>> http://cr.openjdk.java.net/~plevart/jdk10-dev/8191216_SimpleTimeZone_clone_race/webrev.01/ 
>>
>>
>> The JMH benchmark shows this:
>>
>> Default:
>>
>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? 
>> ns/op
>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? 
>> ns/op
>>
>> Cache object:
>>
>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 42,860 ? 0,274? 
>> ns/op
>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,545 ? 0,057? 
>> ns/op
>>
>> Not only does the fix not affect ZoneId.systemDefault() which is not 
>> surprising, but it also speeds-up cache lookup in single-threaded 
>> benchmark and certainly eliminates possible contention among threads 
>> looking up the shared instance.
>>
>> I have run the test/jdk/java/util/TimeZone and 
>> test/jdk/java/util/Calendar jtreg tests and there were 7 failures 
>> caused by compilation errors (package sun.util.locale.provider is not 
>> visible), while 59 other tests pass.
>>
>> So, what do you think?
>>
>> Regards, Peter
>>
>>
>> Venkateswara R Chintala je 21. 11. 2017 ob 10:14?napisal:
>>> Thanks Peter for sponsoring this patch. Is there anything else that 
>>> needs to be done from my end for this patch to be integrated? Please 
>>> let me know.
>>>
>>> -Venkat
>>>
>>>
>>> On 14/11/17 8:46 PM, Peter Levart wrote:
>>>> Hi Venkat,
>>>>
>>>> I created the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8191216
>>>>
>>>> I can also sponsor this patch and push it for JDK 10.
>>>>
>>>> The patch that you are proposing looks good to me. Does anybody 
>>>> have anything else to say?
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>> On 11/13/2017 11:28 AM, Venkateswara R Chintala wrote:
>>>>> Thanks David, Peter for your review and comments. As I am new to 
>>>>> the community, can you please help me to open a bug and integrate 
>>>>> the changes into code base?
>>>>>
>>>>> -Venkat
>>>>>
>>>>> On 12/11/17 2:19 AM, Peter Levart wrote:
>>>>>> Hi David, Venkat,
>>>>>>
>>>>>> On 11/11/17 21:15, Peter Levart wrote:
>>>>>>> For example, take the following method:
>>>>>>>
>>>>>>> String defaultTZID() {
>>>>>>> ??? return TimeZone.getDefault().getID();
>>>>>>> }
>>>>>>>
>>>>>>> When JIT compiles it and inlines invocations to other methods 
>>>>>>> within it, it can prove that cloned TimeZone instance never 
>>>>>>> escapes the call to defaultTZID() and can therefore skip 
>>>>>>> allocating the instance on heap.
>>>>>>>
>>>>>>> But this is fragile. If code in invoked methods changes, they 
>>>>>>> may not get inlined or EA may not be able to prove that the 
>>>>>>> cloned instance can't escape and allocation may be introduced. 
>>>>>>> ZoneId.systemDefault() is a hot method and it would be nice if 
>>>>>>> we manage to keep it allocation free.
>>>>>>
>>>>>> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>>>>>>
>>>>>> ??? public Object clone()
>>>>>> ??? {
>>>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>>>> ??????? // like tz.invalidateCache() but without holding a lock 
>>>>>> on clone
>>>>>> ??????? tz.cacheYear = tz.startYear - 1;
>>>>>> ??????? tz.cacheStart = tz.cacheEnd = 0;
>>>>>> ??????? return tz;
>>>>>> ??? }
>>>>>>
>>>>>>
>>>>>> ...and the JMH benchmark with gc profiling shows that 
>>>>>> ZoneId.systemDefault() still manages to get JIT-compiled without 
>>>>>> introducing allocation.
>>>>>>
>>>>>> Even the following (original Venkat's) patch:
>>>>>>
>>>>>> ??? public Object clone()
>>>>>> ??? {
>>>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>>>> ??????? tz.invalidateCache();
>>>>>> ??????? return tz;
>>>>>> ??? }
>>>>>>
>>>>>> ...does the same and the locking in invalidateCache() is elided 
>>>>>> too. Allocation and lock-elision go hand-in-hand. When object 
>>>>>> doesn't escape, allocation on heap may be eliminated and locks on 
>>>>>> that instance elided.
>>>>>>
>>>>>> So this is better than synchronizing on the original instance 
>>>>>> during .clone() execution as it has potential to avoid locking 
>>>>>> overhead.
>>>>>>
>>>>>> So Venkat, go ahead. My fear was unjustified.
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>
>>>>
>>>>
>>>


From nishit.jain at oracle.com  Mon Dec 11 09:04:32 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 11 Dec 2017 14:34:32 +0530
Subject: <i18n dev> [10]RFR 8190278: ClassCastException is thrown by
 java.util.Scanner when a NumberFormatProvider is used.
Message-ID: <04d2ca68-7cb8-e255-6fb1-51cb157e17f5@oracle.com>

Hi,

Please review the fix for JDK-8190278

Bug: https://bugs.openjdk.java.net/browse/JDK-8190278
Webrev: http://cr.openjdk.java.net/~nishjain/8190278/webrev.03/

Fix: Modified the code to check whether the object returned by 
NumberFormat#getNumberInstance(Locale) is a DecimalFormat object, if not,
 ? ?? then use the DecimalFormat constructor way to create its object, 
where SPI provider implementation is ignored.

Regards,
Nishit Jain


From naoto.sato at oracle.com  Mon Dec 11 18:41:03 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 11 Dec 2017 10:41:03 -0800
Subject: <i18n dev> RFR 8191216: SimpleTimeZone.clone() has a data race
 on cache fields
In-Reply-To: <03df6d4c-2392-642f-7e9f-048459bd7cf8@gmail.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
 <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
 <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>
 <017c44ce-a3e2-a03d-d437-98e08655a6a1@gmail.com>
 <d86e99d1-75c9-8c6e-d5ac-57b4cbff8431@oracle.com>
 <fc40bb10-c28c-70db-6496-11eab8b0c449@gmail.com>
 <3bf0ce49-cb3d-f70b-717d-03680b001d3b@oracle.com>
 <9dbdf9bc-e93a-6ac4-d3ae-5168fd365403@oracle.com>
 <c394ad4d-c9b8-ccc1-bd84-cc0700c1d48e@gmail.com>
 <86b95ce3-2acd-8fda-77cf-222f957ac687@oracle.com>
 <03df6d4c-2392-642f-7e9f-048459bd7cf8@gmail.com>
Message-ID: <dbc694cc-d305-6501-ab28-4f0b3d7f886e@oracle.com>

Hi Peter,

Thanks for the tests. Looks good to me.

One nit: it should throw an Exception instead of AssertionError when the 
test fails. No further review is needed.

 > Can this go into JDK 10 ?

You can push it before the JDK 10 fork.

Naoto

On 12/9/17 2:33 PM, Peter Levart wrote:
> Hi Naoto,
> 
> Thank you for reviewing.
> 
> Naoto Sato je 06. 12. 2017 ob 20:41?napisal:
>> Hi Peter, Venkat,
>>
>> Thank you for the fix. It looks good to me. Improved performance is a 
>> nice bonus! Would you be able to provide with a regression test?
> 
> Sure, here it is:
> 
> http://cr.openjdk.java.net/~plevart/jdk10-dev/8191216_SimpleTimeZone_clone_race/webrev.02/
> 
> 
> The test reliably detects several races in 2 seconds of runtime which 
> cause incorrect offset calculations in JDK 9:
> 
> shared TZ: 7363986 correct, 0 incorrect calculations
> cloned TZ: 3960264 correct, 1180 incorrect calculations
> Exception in thread "main" java.lang.AssertionError: 1180 fatal data 
> races detected
>  ??? at 
> SimpleTimeZoneCloneRaceTest.main(SimpleTimeZoneCloneRaceTest.java:86)
> 
> With patch applied, there are no failures of course.
> 
> Can this go into JDK 10 ?
> 
> Regards, Peter
> 
>>
>> Naoto
>>
>> On 12/6/17 6:10 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> On 12/06/2017 02:30 PM, Alan Bateman wrote:
>>>> I think this class is normally maintained on i18n-dev but I think 
>>>> introducing the Cache object looks good and making this much easier 
>>>> to understand.
>>>>
>>>> -Alan 
>>>
>>> Thanks Alan, I'm forwarding to i18n-dev to see if maintainers of that 
>>> part of JDK have any comments...
>>>
>>> This is an official request for reviewing a patch for fixing a data 
>>> race between cloning a SimpleTimeZone object and lazily initializing 
>>> its 3 cache fields which may produce a clone with inconsistent cache 
>>> state. Here's Jira issue with details:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8191216
>>>
>>> Venkat has proposed to simply call invalidateCache() on the clone 
>>> before returning it from SimpleTimeZone.clone() method:
>>>
>>> ???? public Object clone()
>>> ???? {
>>> ???????? SimpleTimeZone clone = (SimpleTimeZone) super.clone();
>>> ???????? clone.invalidateCache();
>>> ???????? return clone;
>>> ???? }
>>>
>>> This fixes the issue and for the case of TimeZone.getDefault() which 
>>> is called from ZoneId.systemDefault() even elides synchronization in 
>>> clone.invalidateCache() and allocation of the clone, so JITed 
>>> ZoneId.systemDefault() is unaffected by the patch. Initially I was 
>>> satisfied with the fix, but then I tested something. Suppose someone 
>>> sets default zone to SimpleTimeZone:
>>>
>>> ???????? TimeZone.setDefault(
>>> ???????????? new SimpleTimeZone(3600000,
>>> ??????????????????????????????? "Europe/Paris",
>>> ??????????????????????????????? Calendar.MARCH, -1, Calendar.SUNDAY,
>>> ??????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
>>> ??????????????????????????????? Calendar.OCTOBER, -1, Calendar.SUNDAY,
>>> ??????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
>>> ??????????????????????????????? 3600000)
>>> ???????? );
>>>
>>> And then calls some methods that initialize the cache of the internal 
>>> shared TimeZone.defaultTimeZone instance:
>>>
>>> ???? new Date().toString();
>>>
>>> The code which after that tries to obtain default time zone and 
>>> calculate the offset from UTC at some current point in time, for 
>>> example:
>>>
>>> ???? TimeZone.getDefault().getOffset(now)
>>>
>>> can't use the cached state because it has been invalidated in the 
>>> returned clone. Such code has to re-compute the offset every time it 
>>> gets new clone. I measured this with a JMH benchmark and got the 
>>> following result:
>>>
>>> Default:
>>>
>>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501  
>>> ns/op
>>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040  
>>> ns/op
>>>
>>> Venkat's patch - invalidateCache():
>>>
>>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 179,476 ? 1,942  
>>> ns/op
>>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,538 ? 0,073  
>>> ns/op
>>>
>>> We see that ZoneId.systemDefault() is unaffected, but 
>>> TimeZone.getDefault().getOffset(now) becomes 3x slower.
>>>
>>> This is not good, so I tried an alternative fix for the issue - 
>>> simply making the SimpleTimeZone.clone() synchronized. Access to 
>>> cache fields is already synchronized, so this should fix the race. 
>>> Here's the JMH result:
>>>
>>> Default:
>>>
>>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501  
>>> ns/op
>>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040  
>>> ns/op
>>>
>>> Synchronized clone():
>>>
>>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 58,103 ? 0,936  
>>> ns/op
>>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 4,154 ? 0,034  
>>> ns/op
>>>
>>> We see that caching works again, but synchronization has some 
>>> overhead which is not big for single-threaded access, but might get 
>>> bigger when multiple threads try to get default zone concurrently.
>>>
>>> So I created a 3rd variant of the fix which I'm presenting here and 
>>> requesting a review for:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk10-dev/8191216_SimpleTimeZone_clone_race/webrev.01/ 
>>>
>>>
>>> The JMH benchmark shows this:
>>>
>>> Default:
>>>
>>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501  
>>> ns/op
>>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040  
>>> ns/op
>>>
>>> Cache object:
>>>
>>> Benchmark????????????????????????????????? Mode? Cnt Score Error? Units
>>> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 42,860 ? 0,274  
>>> ns/op
>>> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,545 ? 0,057  
>>> ns/op
>>>
>>> Not only does the fix not affect ZoneId.systemDefault() which is not 
>>> surprising, but it also speeds-up cache lookup in single-threaded 
>>> benchmark and certainly eliminates possible contention among threads 
>>> looking up the shared instance.
>>>
>>> I have run the test/jdk/java/util/TimeZone and 
>>> test/jdk/java/util/Calendar jtreg tests and there were 7 failures 
>>> caused by compilation errors (package sun.util.locale.provider is not 
>>> visible), while 59 other tests pass.
>>>
>>> So, what do you think?
>>>
>>> Regards, Peter
>>>
>>>
>>> Venkateswara R Chintala je 21. 11. 2017 ob 10:14?napisal:
>>>> Thanks Peter for sponsoring this patch. Is there anything else that 
>>>> needs to be done from my end for this patch to be integrated? Please 
>>>> let me know.
>>>>
>>>> -Venkat
>>>>
>>>>
>>>> On 14/11/17 8:46 PM, Peter Levart wrote:
>>>>> Hi Venkat,
>>>>>
>>>>> I created the following issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8191216
>>>>>
>>>>> I can also sponsor this patch and push it for JDK 10.
>>>>>
>>>>> The patch that you are proposing looks good to me. Does anybody 
>>>>> have anything else to say?
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>
>>>>> On 11/13/2017 11:28 AM, Venkateswara R Chintala wrote:
>>>>>> Thanks David, Peter for your review and comments. As I am new to 
>>>>>> the community, can you please help me to open a bug and integrate 
>>>>>> the changes into code base?
>>>>>>
>>>>>> -Venkat
>>>>>>
>>>>>> On 12/11/17 2:19 AM, Peter Levart wrote:
>>>>>>> Hi David, Venkat,
>>>>>>>
>>>>>>> On 11/11/17 21:15, Peter Levart wrote:
>>>>>>>> For example, take the following method:
>>>>>>>>
>>>>>>>> String defaultTZID() {
>>>>>>>> ??? return TimeZone.getDefault().getID();
>>>>>>>> }
>>>>>>>>
>>>>>>>> When JIT compiles it and inlines invocations to other methods 
>>>>>>>> within it, it can prove that cloned TimeZone instance never 
>>>>>>>> escapes the call to defaultTZID() and can therefore skip 
>>>>>>>> allocating the instance on heap.
>>>>>>>>
>>>>>>>> But this is fragile. If code in invoked methods changes, they 
>>>>>>>> may not get inlined or EA may not be able to prove that the 
>>>>>>>> cloned instance can't escape and allocation may be introduced. 
>>>>>>>> ZoneId.systemDefault() is a hot method and it would be nice if 
>>>>>>>> we manage to keep it allocation free.
>>>>>>>
>>>>>>> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>>>>>>>
>>>>>>> ??? public Object clone()
>>>>>>> ??? {
>>>>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>>>>> ??????? // like tz.invalidateCache() but without holding a lock 
>>>>>>> on clone
>>>>>>> ??????? tz.cacheYear = tz.startYear - 1;
>>>>>>> ??????? tz.cacheStart = tz.cacheEnd = 0;
>>>>>>> ??????? return tz;
>>>>>>> ??? }
>>>>>>>
>>>>>>>
>>>>>>> ...and the JMH benchmark with gc profiling shows that 
>>>>>>> ZoneId.systemDefault() still manages to get JIT-compiled without 
>>>>>>> introducing allocation.
>>>>>>>
>>>>>>> Even the following (original Venkat's) patch:
>>>>>>>
>>>>>>> ??? public Object clone()
>>>>>>> ??? {
>>>>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>>>>> ??????? tz.invalidateCache();
>>>>>>> ??????? return tz;
>>>>>>> ??? }
>>>>>>>
>>>>>>> ...does the same and the locking in invalidateCache() is elided 
>>>>>>> too. Allocation and lock-elision go hand-in-hand. When object 
>>>>>>> doesn't escape, allocation on heap may be eliminated and locks on 
>>>>>>> that instance elided.
>>>>>>>
>>>>>>> So this is better than synchronizing on the original instance 
>>>>>>> during .clone() execution as it has potential to avoid locking 
>>>>>>> overhead.
>>>>>>>
>>>>>>> So Venkat, go ahead. My fear was unjustified.
>>>>>>>
>>>>>>> Regards, Peter
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
> 

From naoto.sato at oracle.com  Mon Dec 11 21:01:50 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 11 Dec 2017 13:01:50 -0800
Subject: <i18n dev> [10]RFR 8190278: ClassCastException is thrown by
 java.util.Scanner when a NumberFormatProvider is used.
In-Reply-To: <04d2ca68-7cb8-e255-6fb1-51cb157e17f5@oracle.com>
References: <04d2ca68-7cb8-e255-6fb1-51cb157e17f5@oracle.com>
Message-ID: <8c95dd64-7b51-e67c-ed40-f85279717b17@oracle.com>

Looks good to me.

Naoto

On 12/11/17 1:04 AM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8190278
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190278
> Webrev: http://cr.openjdk.java.net/~nishjain/8190278/webrev.03/
> 
> Fix: Modified the code to check whether the object returned by 
> NumberFormat#getNumberInstance(Locale) is a DecimalFormat object, if not,
>  ? ?? then use the DecimalFormat constructor way to create its object, 
> where SPI provider implementation is ignored.
> 
> Regards,
> Nishit Jain
> 

From peter.levart at gmail.com  Mon Dec 11 23:46:36 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 12 Dec 2017 00:46:36 +0100
Subject: <i18n dev> RFR 8191216: SimpleTimeZone.clone() has a data race
 on cache fields
In-Reply-To: <dbc694cc-d305-6501-ab28-4f0b3d7f886e@oracle.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
 <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
 <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>
 <017c44ce-a3e2-a03d-d437-98e08655a6a1@gmail.com>
 <d86e99d1-75c9-8c6e-d5ac-57b4cbff8431@oracle.com>
 <fc40bb10-c28c-70db-6496-11eab8b0c449@gmail.com>
 <3bf0ce49-cb3d-f70b-717d-03680b001d3b@oracle.com>
 <9dbdf9bc-e93a-6ac4-d3ae-5168fd365403@oracle.com>
 <c394ad4d-c9b8-ccc1-bd84-cc0700c1d48e@gmail.com>
 <86b95ce3-2acd-8fda-77cf-222f957ac687@oracle.com>
 <03df6d4c-2392-642f-7e9f-048459bd7cf8@gmail.com>
 <dbc694cc-d305-6501-ab28-4f0b3d7f886e@oracle.com>
Message-ID: <00b82d4b-5c4d-a32a-4059-807dfcd82b49@gmail.com>

Thanks Naoto, Alan, David and Venkat. The change is in.

Regards, Peter

Naoto Sato je 11. 12. 2017 ob 19:41?napisal:
> Hi Peter,
>
> Thanks for the tests. Looks good to me.
>
> One nit: it should throw an Exception instead of AssertionError when 
> the test fails. No further review is needed.
>
> > Can this go into JDK 10 ?
>
> You can push it before the JDK 10 fork.
>
> Naoto
>


From mandy.chung at oracle.com  Mon Dec 18 22:13:57 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 18 Dec 2017 14:13:57 -0800
Subject: <i18n dev> Review Request: JDK-8193767: Improve javadoc in
 ResourceBundle working with modules
Message-ID: <32bff521-b54e-f19d-c0a6-a82a4fa526f3@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8193767/

The above includes the webrev, specdiff and javadoc for this update to 
ResourceBundle, ResourceBundleProvider, and 
AbstractResourceBundleProvider to improve the documentation of 
ResourceBundles working with modules.

thanks
Mandy

From rachna.goel at oracle.com  Tue Dec 19 06:35:43 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Tue, 19 Dec 2017 12:05:43 +0530
Subject: <i18n dev> [11] RFR of 8146656: Wrong Months Array for
	DateFormatSymbols
Message-ID: <428d88c5-8e79-bae6-f9e0-d2b8fa9c1d46@oracle.com>

Hi,

Kindly review API Doc fix for java.text.DateFormatSymbols.

JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8146656

Webrev: http://cr.openjdk.java.net/~rgoel/8146656/webrev/

CSR: https://bugs.openjdk.java.net/browse/JDK-8191414

-- 
Thanks,
Rachna


From joe.darcy at oracle.com  Tue Dec 19 08:37:31 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 19 Dec 2017 00:37:31 -0800
Subject: <i18n dev> [11] RFR of 8146656: Wrong Months Array for
	DateFormatSymbols
In-Reply-To: <428d88c5-8e79-bae6-f9e0-d2b8fa9c1d46@oracle.com>
References: <428d88c5-8e79-bae6-f9e0-d2b8fa9c1d46@oracle.com>
Message-ID: <286bbd77-08ed-bf4c-0ebe-bf7d383e0a90@oracle.com>

Hello Rachna,


On 12/18/2017 10:35 PM, Rachna Goel wrote:
> Hi,
>
> Kindly review API Doc fix for java.text.DateFormatSymbols.
>
> JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8146656
>
> Webrev: http://cr.openjdk.java.net/~rgoel/8146656/webrev/
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191414
>

An addendum to my CSR review. The newly added text should be normative, 
not just informative. That is, the text should officially be part of the 
specification of the class.

If you do not want the 13 elements behavior to be required of a 
subclass, change the @implNote into an @implSpec. If you want 13 
elements to be required of subclasses too, replace @implNote with a 
paragraph begin. (For more guidance on @impNote vs @implspec, etc. see 
http://openjdk.java.net/jeps/8068562)

The CSR should be updated with the amended API change.

Thanks,

-Joe

From joe.darcy at oracle.com  Tue Dec 19 09:25:21 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 19 Dec 2017 01:25:21 -0800
Subject: <i18n dev> [11] RFR of 8146656: Wrong Months Array for
	DateFormatSymbols
In-Reply-To: <719413d5-89e4-7ecd-3420-8a2a6ff63910@oracle.com>
References: <428d88c5-8e79-bae6-f9e0-d2b8fa9c1d46@oracle.com>
 <286bbd77-08ed-bf4c-0ebe-bf7d383e0a90@oracle.com>
 <719413d5-89e4-7ecd-3420-8a2a6ff63910@oracle.com>
Message-ID: <f6b77b89-1562-92fe-8d38-1bae05c5c0fc@oracle.com>

Hi Rachna,

On 12/19/2017 1:13 AM, Rachna Goel wrote:
>
> Hello Joe,
>
> Thanks for the review.
>
> Reason I added @implNote is that it's the case for the default 
> implementation. Not added as a part of spec, as some implementation 
> can just return 12 element array for same methods through the 
> "java.text.spi.DateFormatSymbolsProvider" SPI.
>
>

That is precisely the sort of situation the @implSpec tag is intended 
for. It allows the specification to say DateFormatSymbols must behave 
this way while allowing subclasses to behave differently.

Perhaps some general text can be added as normal specification, 
something like

"An array with either 12 or 13 elements will be returned depending on 
whether or {@link Calendar.UNDECIMBER} is supported."

paired with

@implSpec This method returns 13 elements since @link 
Calendar.UNDECIMBER} is supported.

HTH,

-Joe


From rachna.goel at oracle.com  Tue Dec 19 09:13:55 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Tue, 19 Dec 2017 14:43:55 +0530
Subject: <i18n dev> [11] RFR of 8146656: Wrong Months Array for
	DateFormatSymbols
In-Reply-To: <286bbd77-08ed-bf4c-0ebe-bf7d383e0a90@oracle.com>
References: <428d88c5-8e79-bae6-f9e0-d2b8fa9c1d46@oracle.com>
 <286bbd77-08ed-bf4c-0ebe-bf7d383e0a90@oracle.com>
Message-ID: <719413d5-89e4-7ecd-3420-8a2a6ff63910@oracle.com>

Hello Joe,

Thanks for the review.

Reason I added @implNote is that it's the case for the default 
implementation. Not added as a part of spec, as some implementation can 
just return 12 element array for same methods through the 
"java.text.spi.DateFormatSymbolsProvider" SPI.

Thanks,
Rachna

On 19/12/17 2:07 PM, joe darcy wrote:
> Hello Rachna,
>
>
> On 12/18/2017 10:35 PM, Rachna Goel wrote:
>> Hi,
>>
>> Kindly review API Doc fix for java.text.DateFormatSymbols.
>>
>> JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8146656
>>
>> Webrev: http://cr.openjdk.java.net/~rgoel/8146656/webrev/
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191414
>>
>
> An addendum to my CSR review. The newly added text should be 
> normative, not just informative. That is, the text should officially 
> be part of the specification of the class.
>
> If you do not want the 13 elements behavior to be required of a 
> subclass, change the @implNote into an @implSpec. If you want 13 
> elements to be required of subclasses too, replace @implNote with a 
> paragraph begin. (For more guidance on @impNote vs @implspec, etc. see 
> http://openjdk.java.net/jeps/8068562)
>
> The CSR should be updated with the amended API change.
>
> Thanks,
>
> -Joe

-- 
Thanks,
Rachna


From rachna.goel at oracle.com  Tue Dec 19 10:08:30 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Tue, 19 Dec 2017 15:38:30 +0530
Subject: <i18n dev> [11] RFR of 8146656: Wrong Months Array for
	DateFormatSymbols
In-Reply-To: <f6b77b89-1562-92fe-8d38-1bae05c5c0fc@oracle.com>
References: <428d88c5-8e79-bae6-f9e0-d2b8fa9c1d46@oracle.com>
 <286bbd77-08ed-bf4c-0ebe-bf7d383e0a90@oracle.com>
 <719413d5-89e4-7ecd-3420-8a2a6ff63910@oracle.com>
 <f6b77b89-1562-92fe-8d38-1bae05c5c0fc@oracle.com>
Message-ID: <ce6d1824-d8ee-82b7-6a5d-2f309de2757e@oracle.com>

Hi Joe,

Thanks for the comments.

I have updated the CSR to have @implSpec in place of @implNote.

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

Regarding  "An array with either 12 or 13 elements will be returned 
depending on whether or {@link Calendar.UNDECIMBER} is supported." ,  I 
would like to go with existing statement as this method always returns 
13 elements where the 13th element may be empty string or may contain 
Calendar.UNDECIMBER, depending upon whether its supported by the 
Calendar instance.

kindly suggest whether this looks fine!

Thanks,
Rachna


On 19/12/17 2:55 PM, joe darcy wrote:
> Hi Rachna,
>
> On 12/19/2017 1:13 AM, Rachna Goel wrote:
>>
>> Hello Joe,
>>
>> Thanks for the review.
>>
>> Reason I added @implNote is that it's the case for the default 
>> implementation. Not added as a part of spec, as some implementation 
>> can just return 12 element array for same methods through the 
>> "java.text.spi.DateFormatSymbolsProvider" SPI.
>>
>>
>
> That is precisely the sort of situation the @implSpec tag is intended 
> for. It allows the specification to say DateFormatSymbols must behave 
> this way while allowing subclasses to behave differently.
>
> Perhaps some general text can be added as normal specification, 
> something like
>
> "An array with either 12 or 13 elements will be returned depending on 
> whether or {@link Calendar.UNDECIMBER} is supported."
>
> paired with
>
> @implSpec This method returns 13 elements since @link 
> Calendar.UNDECIMBER} is supported.
>
> HTH,
>
> -Joe
>

-- 
Thanks,
Rachna


From naoto.sato at oracle.com  Tue Dec 19 18:38:30 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 19 Dec 2017 10:38:30 -0800
Subject: <i18n dev> Review Request: JDK-8193767: Improve javadoc in
 ResourceBundle working with modules
In-Reply-To: <32bff521-b54e-f19d-c0a6-a82a4fa526f3@oracle.com>
References: <32bff521-b54e-f19d-c0a6-a82a4fa526f3@oracle.com>
Message-ID: <87d965a9-b8c1-72ba-7eea-b13ced010958@oracle.com>

Looks good to me.

Naoto

On 12/18/17 2:13 PM, mandy chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8193767/
> 
> The above includes the webrev, specdiff and javadoc for this update to 
> ResourceBundle, ResourceBundleProvider, and 
> AbstractResourceBundleProvider to improve the documentation of 
> ResourceBundles working with modules.
> 
> thanks
> Mandy

From simon at elastic.co  Wed Dec 20 16:56:46 2017
From: simon at elastic.co (Simon Willnauer)
Date: Wed, 20 Dec 2017 17:56:46 +0100
Subject: <i18n dev> DateFormatSymbols for Locale.GERMAN changed form Java 8
	to Java 9
Message-ID: <CANq=Q3z1XFNMO1xsOKdoob=DgjiUjqE_nG45ZCPUqwd=NNf-Tg@mail.gmail.com>

Hey folks,

I have this simple test that I run with java 9.0.1 as well as java 1.8_131

DateFormatSymbols s = new DateFormatSymbols(Locale.GERMAN);
System.out.println(Arrays.toString(s.getShortWeekdays()));

on Java 9 it prints this:

[, So., Mo., Di., Mi., Do., Fr., Sa.]

while on Java 1.8 and below it prints:

[, So, Mo, Di, Mi, Do, Fr, Sa]

This is also true for Month in the German local. I didn't test
anything else but I wonder if this is expected or if it is considered
a bug. I also raised an issue against JodaTime which relies on this
here [1]. I ran into this a while ago on elasticsearch here [2] but
just picked it up. I wish I had done this earlier!

thanks,

simon


[1] https://github.com/JodaOrg/joda-time/issues/462
[2] https://github.com/elastic/elasticsearch/issues/10984

From joe.darcy at oracle.com  Wed Dec 20 17:14:25 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 20 Dec 2017 09:14:25 -0800
Subject: <i18n dev> [11] RFR of 8146656: Wrong Months Array for
	DateFormatSymbols
In-Reply-To: <ce6d1824-d8ee-82b7-6a5d-2f309de2757e@oracle.com>
References: <428d88c5-8e79-bae6-f9e0-d2b8fa9c1d46@oracle.com>
 <286bbd77-08ed-bf4c-0ebe-bf7d383e0a90@oracle.com>
 <719413d5-89e4-7ecd-3420-8a2a6ff63910@oracle.com>
 <f6b77b89-1562-92fe-8d38-1bae05c5c0fc@oracle.com>
 <ce6d1824-d8ee-82b7-6a5d-2f309de2757e@oracle.com>
Message-ID: <46a67401-92e4-09a2-dfdf-2c10a977a71e@oracle.com>

Hi Rachna,

I think the revised version with the @implSpec tag switch is acceptable, 
but also think providing more text to describe this situation would be 
helpful to programmers unaware of a 13 month possibility.

Cheers,

-Joe


On 12/19/2017 2:08 AM, Rachna Goel wrote:
>
> Hi Joe,
>
> Thanks for the comments.
>
> I have updated the CSR to have @implSpec in place of @implNote.
>
> https://bugs.openjdk.java.net/browse/JDK-8191414
>
> Regarding  "An array with either 12 or 13 elements will be returned 
> depending on whether or {@link Calendar.UNDECIMBER} is supported." ,  
> I would like to go with existing statement as this method always 
> returns 13 elements where the 13th element may be empty string or may 
> contain Calendar.UNDECIMBER, depending upon whether its supported by 
> the Calendar instance.
>
> kindly suggest whether this looks fine!
>
> Thanks,
> Rachna
>
>
> On 19/12/17 2:55 PM, joe darcy wrote:
>> Hi Rachna,
>>
>> On 12/19/2017 1:13 AM, Rachna Goel wrote:
>>>
>>> Hello Joe,
>>>
>>> Thanks for the review.
>>>
>>> Reason I added @implNote is that it's the case for the default 
>>> implementation. Not added as a part of spec, as some implementation 
>>> can just return 12 element array for same methods through the 
>>> "java.text.spi.DateFormatSymbolsProvider" SPI.
>>>
>>>
>>
>> That is precisely the sort of situation the @implSpec tag is intended 
>> for. It allows the specification to say DateFormatSymbols must behave 
>> this way while allowing subclasses to behave differently.
>>
>> Perhaps some general text can be added as normal specification, 
>> something like
>>
>> "An array with either 12 or 13 elements will be returned depending on 
>> whether or {@link Calendar.UNDECIMBER} is supported."
>>
>> paired with
>>
>> @implSpec This method returns 13 elements since @link 
>> Calendar.UNDECIMBER} is supported.
>>
>> HTH,
>>
>> -Joe
>>
>
> -- 
> Thanks,
> Rachna


From sean.coffey at oracle.com  Wed Dec 20 17:40:22 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 20 Dec 2017 17:40:22 +0000
Subject: <i18n dev> DateFormatSymbols for Locale.GERMAN changed form
 Java 8 to Java 9
In-Reply-To: <CANq=Q3z1XFNMO1xsOKdoob=DgjiUjqE_nG45ZCPUqwd=NNf-Tg@mail.gmail.com>
References: <CANq=Q3z1XFNMO1xsOKdoob=DgjiUjqE_nG45ZCPUqwd=NNf-Tg@mail.gmail.com>
Message-ID: <67d51a53-94cd-cdce-e86d-c626fd8bf5d1@oracle.com>

CLDR Locale data is now used by default in JDK 9. If you need to remain 
with JDK 8 behaviour you can use the 'java.locale.providers' system 
property. See 
https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-974CF488-23E8-4963-A322-82006A7A14C7

Regards,
Sean.

On 20/12/17 16:56, Simon Willnauer wrote:
> Hey folks,
>
> I have this simple test that I run with java 9.0.1 as well as java 1.8_131
>
> DateFormatSymbols s = new DateFormatSymbols(Locale.GERMAN);
> System.out.println(Arrays.toString(s.getShortWeekdays()));
>
> on Java 9 it prints this:
>
> [, So., Mo., Di., Mi., Do., Fr., Sa.]
>
> while on Java 1.8 and below it prints:
>
> [, So, Mo, Di, Mi, Do, Fr, Sa]
>
> This is also true for Month in the German local. I didn't test
> anything else but I wonder if this is expected or if it is considered
> a bug. I also raised an issue against JodaTime which relies on this
> here [1]. I ran into this a while ago on elasticsearch here [2] but
> just picked it up. I wish I had done this earlier!
>
> thanks,
>
> simon
>
>
> [1] https://github.com/JodaOrg/joda-time/issues/462
> [2] https://github.com/elastic/elasticsearch/issues/10984


From simon at elastic.co  Wed Dec 20 18:16:02 2017
From: simon at elastic.co (Simon Willnauer)
Date: Wed, 20 Dec 2017 19:16:02 +0100
Subject: <i18n dev> DateFormatSymbols for Locale.GERMAN changed form
	Java 8 to Java 9
In-Reply-To: <67d51a53-94cd-cdce-e86d-c626fd8bf5d1@oracle.com>
References: <CANq=Q3z1XFNMO1xsOKdoob=DgjiUjqE_nG45ZCPUqwd=NNf-Tg@mail.gmail.com>
 <67d51a53-94cd-cdce-e86d-c626fd8bf5d1@oracle.com>
Message-ID: <B3D48421-E706-461B-90C1-2DFCCEAEB2F9@elastic.co>


Sean, thanks for the answer. I missed that completely. Do you have any idea when this COMPAT option will be removed? There is also not option to use both providers in the same JVM I assume?!

> On 20. Dec 2017, at 18:40, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> CLDR Locale data is now used by default in JDK 9. If you need to remain with JDK 8 behaviour you can use the 'java.locale.providers' system property. See https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-974CF488-23E8-4963-A322-82006A7A14C7
> 
> Regards,
> Sean.
> 
>> On 20/12/17 16:56, Simon Willnauer wrote:
>> Hey folks,
>> 
>> I have this simple test that I run with java 9.0.1 as well as java 1.8_131
>> 
>> DateFormatSymbols s = new DateFormatSymbols(Locale.GERMAN);
>> System.out.println(Arrays.toString(s.getShortWeekdays()));
>> 
>> on Java 9 it prints this:
>> 
>> [, So., Mo., Di., Mi., Do., Fr., Sa.]
>> 
>> while on Java 1.8 and below it prints:
>> 
>> [, So, Mo, Di, Mi, Do, Fr, Sa]
>> 
>> This is also true for Month in the German local. I didn't test
>> anything else but I wonder if this is expected or if it is considered
>> a bug. I also raised an issue against JodaTime which relies on this
>> here [1]. I ran into this a while ago on elasticsearch here [2] but
>> just picked it up. I wish I had done this earlier!
>> 
>> thanks,
>> 
>> simon
>> 
>> 
>> [1] https://github.com/JodaOrg/joda-time/issues/462
>> [2] https://github.com/elastic/elasticsearch/issues/10984
> 

From naoto.sato at oracle.com  Thu Dec 21 17:10:37 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 21 Dec 2017 09:10:37 -0800
Subject: <i18n dev> [PATCH] Support for UTC Zones with
	TimeZone.getTimeZone()
In-Reply-To: <CAGJzMZjdAVc2n7aT2FVLGwZLSwnSV70HkbADbEMquuchuWfz3Q@mail.gmail.com>
References: <CAGJzMZg_8Bn+B80yjOowB0FP7bzYZFQt+Prf=afJRCHsXBBHMg@mail.gmail.com>
 <8287adfe-079c-be54-789a-2b609d5721e9@oracle.com>
 <CAGJzMZjdAVc2n7aT2FVLGwZLSwnSV70HkbADbEMquuchuWfz3Q@mail.gmail.com>
Message-ID: <c0327ce5-375f-5b05-f7b4-da945ad4388a@oracle.com>

Hi Naufal,

I can sponsor your fix. Here is the issue created for this:

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

If haven't already, would you take a look at the OpenJDK contribute 
page? [1]

Also, I will need a regression test for the fix as well.

Thanks!
Naoto

[1] http://openjdk.java.net/contribute/

On 12/20/17 5:44 PM, Mohamed Naufal wrote:
> Hi Naoto,
> 
> Thank you for the feedback, I'll send an updated patch shortly.
> 
> Best regards,
> Naufal
> 
> On 21 December 2017 at 05:19, Naoto Sato <naoto.sato at oracle.com 
> <mailto:naoto.sato at oracle.com>> wrote:
> 
>     Hi Naufal,
> 
>     Thank you for the patch. It does seem to be a bug. However, TimeZone
>     class defines CustomID as "GMT+(offset)", so I'd rather fix it in
>     GregorianCalendar.from() to recognize those "UTC+offset" zones.
> 
>     Naoto
> 
> 
>     On 12/16/17 2:27 AM, Mohamed Naufal wrote:
> 
>         Hi,
> 
>         I noticed that with the following data:
> 
>         LocalDateTime ldt = LocalDateTime.parse("2017-01-01T00:00:00");
>         ZonedDateTime dt1 = ZonedDateTime.of(ldt, ZoneId.of("GMT+10"));
>         ZonedDateTime dt2 = ZonedDateTime.of(ldt, ZoneId.of("UTC+10"));
> 
>         dt1.equals(dt2) returns true as expected, but with:
> 
>         GregorianCalendar gc1 = GregorianCalendar.from(dt1);
>         GregorianCalendar gc2 = GregorianCalendar.from(dt2);
> 
>         gc1.equals(gc2) returns false.
> 
>         Looking at the code, I see when a GregorianCalendar is being
>         constructed,
>         TimeZone.getTimeZone() gets called, but it doesn't recognise UTC
>         time-zones
>         with offsets, and falls back to GMT(+0), whereas ZoneId treats
>         GMT and UTC
>         based zones equivalently.
> 
>         PFA a patch to fix this.
> 
>         Thank you,
>         Naufal
> 
> 

From naoto.sato at oracle.com  Fri Dec 22 18:39:15 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 22 Dec 2017 10:39:15 -0800
Subject: <i18n dev> DateFormatSymbols for Locale.GERMAN changed form
 Java 8 to Java 9
In-Reply-To: <B3D48421-E706-461B-90C1-2DFCCEAEB2F9@elastic.co>
References: <CANq=Q3z1XFNMO1xsOKdoob=DgjiUjqE_nG45ZCPUqwd=NNf-Tg@mail.gmail.com>
 <67d51a53-94cd-cdce-e86d-c626fd8bf5d1@oracle.com>
 <B3D48421-E706-461B-90C1-2DFCCEAEB2F9@elastic.co>
Message-ID: <6d567713-ae4b-d3cb-295b-926350ae7410@oracle.com>

Hi Simon,

On 12/20/17 10:16 AM, Simon Willnauer wrote:
> 
> Sean, thanks for the answer. I missed that completely. Do you have any idea when this COMPAT option will be removed?

At this moment, there is no plan to remove COMPAT provider in the near 
future.

> There is also not option to use both providers in the same JVM I assume?!

Yes, that is correct.

Naoto

> 
>> On 20. Dec 2017, at 18:40, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>
>> CLDR Locale data is now used by default in JDK 9. If you need to remain with JDK 8 behaviour you can use the 'java.locale.providers' system property. See https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-974CF488-23E8-4963-A322-82006A7A14C7
>>
>> Regards,
>> Sean.
>>
>>> On 20/12/17 16:56, Simon Willnauer wrote:
>>> Hey folks,
>>>
>>> I have this simple test that I run with java 9.0.1 as well as java 1.8_131
>>>
>>> DateFormatSymbols s = new DateFormatSymbols(Locale.GERMAN);
>>> System.out.println(Arrays.toString(s.getShortWeekdays()));
>>>
>>> on Java 9 it prints this:
>>>
>>> [, So., Mo., Di., Mi., Do., Fr., Sa.]
>>>
>>> while on Java 1.8 and below it prints:
>>>
>>> [, So, Mo, Di, Mi, Do, Fr, Sa]
>>>
>>> This is also true for Month in the German local. I didn't test
>>> anything else but I wonder if this is expected or if it is considered
>>> a bug. I also raised an issue against JodaTime which relies on this
>>> here [1]. I ran into this a while ago on elasticsearch here [2] but
>>> just picked it up. I wish I had done this earlier!
>>>
>>> thanks,
>>>
>>> simon
>>>
>>>
>>> [1] https://github.com/JodaOrg/joda-time/issues/462
>>> [2] https://github.com/elastic/elasticsearch/issues/10984
>>