RFR [16/java.xml] 8246816: XMLGregorianCalendar.hashCode() produces far too many identical hashes

[naoto.sato at oracle.com]

Hi Joe, thank you for looking it into further.

Yes, I agree the chances of collision is very rare, as sub-millisecond 
difference in two objects. So fine with the version 01.

Naoto

On 8/6/20 12:18 PM, Joe Wang wrote:
> Thanks Naoto, Roger for the review!
> 
> For Naoto's concern about the equals method using EonAndYear and 
> FractionalSecond, I did cut corners using the all int getXXX method. The 
> rational was: it fulfills the equals-hashcode contract just fine, is 
> consistent with the existing implementation, and concise. This API was 
> introduced since 1.5, but I have yet to see any usage of EonAndYear, and 
> very rarely FractionalSecond. The chances collisions occur due to these 
> differences are very low.
> 
> But I understand your concern. To be precise or exact as equals(), we 
> would need to call getFractionalSecond and EonAndYear. Here's what that 
> would look like:
> http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev_02/
> 
> To me, I like version 1 for the reasons above:
> http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev_01/
> 
> What would you think?
> 
> Regards,
> Joe
> 
> On 8/5/20 6:13 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> For the consistency with equals(), just wondering if the sub-second 
>> element should be obtained with getFractionalSecond() instead of 
>> getMillisecond(), as the equals() subsequently calls it in 
>> internalCompare() method. Also should it call getEonAndYear() 
>> appropriately for the year?
>>
>> Naoto
>>
>> On 8/5/20 4:37 PM, Joe Wang wrote:
>>> Hello,
>>>
>>> Please review a fix for the hashCode generation.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8246816
>>>
>>> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev/
>>>
>>> Thanks,
>>> Joe
>>>
>