RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v6]
Stuart Marks
smarks at openjdk.java.net
Fri Feb 12 23:33:44 UTC 2021
On Fri, 12 Feb 2021 22:52:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>> A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum.
>>
>> Once the changes are agreed to, I'll reflow paragraphs and update the copyright years.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix typo.
Marked as reviewed by smarks (Reviewer).
src/java.base/share/classes/java/math/BigDecimal.java line 99:
> 97: * hold. The results of methods like {@link scale} and {@link
> 98: * unscaledValue} will differ for numerically equal values with
> 99: * different representations.
While this text is correct and reasonable, it doesn't really explain _why_ equals() considers the representation. One might assume incorrectly that the representation is internal only and doesn't affect computations. Of course it does affect computations, which is why I suggested the example. Maybe the example doesn't belong right here, in which case it's reasonable for this change to proceed. I think it would be good to put an example _somewhere_ of non-substitutability of numerical values with different representations. Maybe we could handle that separately.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2471
More information about the core-libs-dev
mailing list