[12] RFR: 8210142: java.util.Calendar.clone() doesn't respect sharedZone flag

Naoto Sato naoto.sato at oracle.com
Tue Sep 4 20:12:38 UTC 2018


Hi Roger,

Yes, I considered that too, but did not change the behavior and just to 
maintain the field consistent. I agree that it would not be observable 
via the public Calendar API, but some apps (like how the submitter found 
it) may be doing something using reflection.

Naoto

On 9/4/18 12:31 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> The spec for clone doesn't say whether the clone should share or not 
> share the TimeZone.
> Did you consider that if sharedZone was true , *not* to clone the TimeZone?
> It would still get cloned when requested from getTimeZone().
> 
> This does seem somewhat safer not to change the cloning behavior but I 
> don't think the behavior would be observable.
> 
> The current code and test is fine, except for reducing the potential for 
> sharing the TimeZone.
> 
> Thanks, Roger
> 
> On 9/4/2018 2:14 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8210142
>>
>> The proposed fix is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8210142/webrev.00/
>>
>> The fix is a simple one line change, which is to make the sharedZone 
>> field consistent with the cloned TimeZone instance in Calendar.clone().
>>
>> Naoto
> 


More information about the core-libs-dev mailing list