Use Advanced Search to search the entire archive.
[jsr363-experts] Re: some things :)
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: some things :)
- Date: Sat, 13 Dec 2014 16:44:49 +0100
We should likely address this on the top level of the implementation,
AbstractUnit is the common base type (the unfinished JScience 5 called such
abstract base class implementing Unit-API 0.6 PhysicalUnit,
I discussed the term with leading EC Members before proposing the new JSR
and they said, it might be a bit too restrictive and put the JSR into a
"scientific" corner (similar to why 275 was cancelled sounding too "geeky"
and science-laden at the time for many EC Members;-) so until we find a
better term AbstractUnit is as good as it gets.
Java and (Open)JDK have the most lousy equals() methods one can imagine.
See the Integer class:
if (obj instanceof Integer) {
return value == ((Integer)obj).intValue();
}
Which is why BigInteger.ONE.equals(Integer.valueOf(1)) will always return
false[?]
Guess we can handle that better within an implementation like RI at least.
Werner
On Sat, Dec 13, 2014 at 11:04 AM, Martin Desruisseaux <
>
wrote:
>
>
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
>
>
Attachment:
362.gif
Description: GIF image