Thanks for all these helpful responses. So I guess there's nothing to do here except we want to integrate the change proposed by Chen to update the expression to use Long.hashCode.
Cheers, Steffen -------- Ursprüngliche Nachricht -------- Am 30.04.25 23:25 schrieb Roger Riggs : > Hi Steffen, > > One other oddity about the shift operators in Java, they only use the lower 5 > bits of the shift distance argument. > > So, > > int x = 1024; > x >>4 == 64; and > x >> 36 == 64; > > It is unusual to specify the algorithm used for hashcodes, though in some > cases backward compatibility has forced them to be specified. > > Regards, Roger > > On 4/30/25 4:37 PM, Steffen Nießing wrote: > >> Thanks, haven't seen unsigned right shift before. You're right, it should be >> fine to use the unsigned one and hence Long.hashCode for that. >> >> However, the docs should match the expression used in the implementation >> when explicitly naming the returned expression. Should we update both to >> Long.hashCode(this.getTime())? >> >> Cheers, >> Steffen >> >> Chen Liang [<chen.l.li...@oracle.com>](mailto:chen.l.li...@oracle.com) >> schrieb am Mittwoch, 30. April 2025 um 22:27: >> >>> Well, the sign has no impact here - the most significant 32 bits duplicated >>> from the original sign bit are immediately discarded in the subsequent int >>> cast truncation to the least significant 32 bits. However, how there is >>> such a difference from before OpenJDK was published is still intriguing. >>> --------------------------------------------------------------- >>> >>> From: core-libs-dev >>> [<core-libs-dev-r...@openjdk.org>](mailto:core-libs-dev-r...@openjdk.org) >>> on behalf of Naoto Sato >>> [<naoto.s...@oracle.com>](mailto:naoto.s...@oracle.com) >>> Sent: Wednesday, April 30, 2025 3:11 PM >>> To: core-libs-dev@openjdk.org >>> [<core-libs-dev@openjdk.org>](mailto:core-libs-dev@openjdk.org) >>> Subject: Re: JavaDoc fix in java.util.Date >>> >>> Interestingly, the implementation of Date.hashCode() does use the signed >>> right shift ">>". >>> >>> Naoto >>> >>> On 4/30/25 1:06 PM, Chen Liang wrote: >>>> Indeed, Joe is right. Unsigned right shift does not appear often and is >>>> equivalent to signed right shift if the sign bit is 0. >>>> >>>> However, this piece of quote can get an upgrade - it can become >>>> `Long.hashCode(this.getTime())`. >>>> >>>> * >>>> Chen >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* core-libs-dev >>>> [<core-libs-dev-r...@openjdk.org>](mailto:core-libs-dev-r...@openjdk.org) >>>> on behalf of >>>> Joseph D. Darcy [<joe.da...@oracle.com>](mailto:joe.da...@oracle.com) >>>> *Sent:* Wednesday, April 30, 2025 2:54 PM >>>> *To:* Steffen Nießing >>>> [<zuniq...@protonmail.com>](mailto:zuniq...@protonmail.com); core-libs- >>>> d...@openjdk.org >>>> [<core-libs-dev@openjdk.org>](mailto:core-libs-dev@openjdk.org) >>>> *Subject:* Re: JavaDoc fix in java.util.Date >>>> Unsigned right shift is non-existent? >>>> >>>> "The operators << (left shift), >> (signed right shift), and >>> >>>> (unsigned right shift) are called the shift operators. The left-hand >>>> operand of a shift operator is the value to be shifted; the right-hand >>>> operand specifies the shift distance. " >>>> >>>> https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19 >>>> <https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19> >>>> >>>> -Joe >>>> >>>> On 4/30/2025 12:46 PM, Steffen Nießing wrote: >>>>> Hello, >>>>> >>>>> I'm new to the OpenJDK community and plan to make my first change. >>>>> >>>>> I've found a small mistake in the documentation of >>>>> java.util.Date#hashCode(). The documentation provides a Java >>>>> expression of the returned value, which uses a non-existent operator >>>>> '>>>'. >>>>> >>>>> Now I'm searching for a sponsor for a JBS issue and the code review. >>>>> Chen Liang directed me to this mailing list to ask for sponsoring on >>>>> this topic. >>>>> >>>>> Cheers, >>>>> Steffen >>>> >>>>
