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

[Joe Wang]

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
>>