Open msqr opened 5 years ago
With a quantity it is often the case, that a rather strict equals() method by the JDK fails because it looks at the exact class which is not representative in many cases, that's why we introduced the notion of equivalence. It may happen less often with units, but a TransformedUnit and AlternateUnit are also not equal in the sense of Java, so it is likely because of that. Did you try isEquivalentTo()
here as well? Aside from that, while HERTZ
has no special character in the UCUM catalog, you may stick to one of the classic UnitFormat
implementations for units in the RI, the UCUMFormat
you got from the UCUMServiceProvider
is optimized to work with the UCUM
system.
If I cast the Unit
to a ComparableUnit
then isEquivalentTo()
does return true
-- I did this:
final Unit<Frequency> rpm = Units.HERTZ.divide(60);
if ( unit2.isCompatible(rpm) && unit2 instanceof ComparableUnit<?> ) {
ComparableUnit<Frequency> cu2 = (ComparableUnit<Frequency>) unit2.asType(Frequency.class);
assertThat("Unit is RPM", cu2.isEquivalentTo(rpm), equalTo(true));
}
Unfortunately ComparableUnit
and thus isEquivalentTo()
is not in the javax.measure
API, that is why I was using equals()
for comparison. The UCUMServiceProvider
is used here as I extracted the test case out of an application that is relying on UCUM. Is there a recommended way to compare Unit
instances for equality while staying within the javax.measure
API? For example using UnitConverter.isIdentity()
worked, but I wondered if there was a more straightforward way?
Hello, I was writing some tests to verify parsing of UCUM units, and ran into a problem where parsing
Hz/60
did not result in aUnit
that was equal toUnits.HERTZ.divide(60)
as I was expecting. When parsing the string, the result ends up asHz/one*60
. I wondered if these two Units should actually be considered equal? Maybe this is related to #140?Here's some example test code of what I am doing: