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

[Roger Riggs]

+1

On 8/6/20 4:18 PM, naoto.sato at oracle.com wrote:
> 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
>>>>
>>