Skip to main content

[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



[jsr363-experts] some things :)

Leonardo Lima 12/11/2014

[jsr363-experts] Re: some things :)

Martin Desruisseaux 12/13/2014

[jsr363-experts] Re: some things :)

Werner Keil 12/13/2014

[jsr363-experts] Re: some things :)

Martin Desruisseaux 12/14/2014

[jsr363-experts] Re: some things :)

Werner Keil 12/14/2014
 
 
Close
loading
Please Confirm
Close