Use Advanced Search to search the entire archive.
[jsr363-experts] Re: some things :)
- From: Martin Desruisseaux <
>
- To:
- Subject: [jsr363-experts] Re: some things :)
- Date: Sat, 13 Dec 2014 19:04:27 +0900
- Organization: Geomatys
Le 12/12/14 01:22, Leonardo Lima a écrit :
>
>
One important question that might also deserve a JIRA ticket is
>
how the equals() method (and where applicable others including
>
compareTo()) should deal with some Java inconsistencies, e.g.
>
KILOGRAM normally results in a BaseUnit while KILO(GRAM) becomes a
>
TransformedUnit or similar. Hence KILOGRAM.equals(KILO(GRAM)) is
>
false simply because the two classes underneath currently use
>
standard equals() behavior that takes the exact class into
>
consideration. This seems correct in general Java terms, e.g.
>
BigInteger.ONE.equals(Integer.valueOf(1)) will also be false
>
though the numeric value is the same. You'd have to compare
>
something like doubleValue() to make it work, similar for
>
different Unit implementations getSymbol() getName() where
>
available or a combination of both usually work, especially for
>
KILOGRAM vs. KILO(GRAM).
>
>
>
I agree it should be in a Jira issue, but briefly I believe that we
>
should convert one of the units to the other and than do the
>
comparison in case of different classes...
I wonder why KILO(GRAM) has not been able to recognize by itself that
the result is a BaseUnit? My inclination would be to fix that part
rather than taking the risk of changing the 'equals' method. In my
experience, making 'equals' not strict leads to lot of inconsistency
problems:
* keeping 'hashCode' consistent with 'equals',
* ensuring that A.equals(B) == B.equals(A),
* ensuring that if A.equals(B) and B.equals(C) then A.equals(C),
* /etc./
all those invariants tend to become very tricky with "lousy" 'equals'
methods.
Martin