Incorrect validation of DST in java.util.SimpleTimeZone
sean.coffey at oracle.com
Fri Nov 10 15:59:40 UTC 2017
I think the OpenJDK mailing lists accept attachments if in patch format.
If it's a simple short patch, it's acceptable to paste it into email body.
Easiest solution is to use webrev. If you can't upload this to
cr.openjdk.java.net - then one of your colleagues may be able to help.
On 10/11/17 12:18, Venkateswara R Chintala wrote:
> Looks like the patch attached earlier is not visible. As this is my
> first contribution, please let me know how I can send the patch for
> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>> In a multi-threaded environment, when java.util.SimpleTimeZone object
>> is used to create a default timezone, there can be a race condition
>> between the methods java.util.Timezone.getDefault() and
>> java.util.Timezone.getDefaultRef() which can result in inconsistency
>> of cache that is used to validate a particular time/date in DST.
>> When a thread is cloning a default timezone object (SimpleTimeZone)
>> and at the same time if a different thread modifies the time/year
>> values, then the cache values (cacheYear, cacheStart, cacheEnd) can
>> become inconsistent which leads to incorrect DST determination.
>> We considered two approaches to fix the issue.
>> 1)Synchronize access to cloning default timezone object when cache is
>> being modified.
>> 2)Invalidate the cache while returning the clone.
>> We preferred the second option as synchronization is more expensive.
>> We have attached the patch and jtreg testcase. Please review.
More information about the core-libs-dev