JavaDoc fix in java.util.Date

[Steffen Nießing]

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.liang at oracle.com>](mailto:chen.l.liang at 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-retn at openjdk.org>](mailto:core-libs-dev-retn at openjdk.org) on behalf of Naoto Sato [<naoto.sato at oracle.com>](mailto:naoto.sato at oracle.com)
>>> Sent: Wednesday, April 30, 2025 3:11 PM
>>> To: core-libs-dev at openjdk.org [<core-libs-dev at openjdk.org>](mailto:core-libs-dev at 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-retn at openjdk.org>](mailto:core-libs-dev-retn at openjdk.org) on behalf of
>>>> Joseph D. Darcy [<joe.darcy at oracle.com>](mailto:joe.darcy at oracle.com)
>>>> *Sent:* Wednesday, April 30, 2025 2:54 PM
>>>> *To:* Steffen Nießing [<zuniquex at protonmail.com>](mailto:zuniquex at protonmail.com); core-libs-
>>>> dev at openjdk.org [<core-libs-dev at openjdk.org>](mailto:core-libs-dev at 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
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250501/70a90d34/attachment-0001.htm>