Same values, but with different types, was considered different.

[ezidio]

@Test
public void test_equality() throws Exception {
ComparableQuantity<Length> value = Quantities.getQuantity(20.0, Units.METRE);
ComparableQuantity<Length> anotherValue = Quantities.getQuantity(20, Units.METRE);
assertEquals(value, anotherValue);
}

Result

java.lang.AssertionError: Expected :20.0 m Actual :20 m

[otaviojava]

Thanks for giving us feedback about the API, WIP to fix it.

[otaviojava]

from JavaDoc:

/**

• Compares this measure against the specified object for strict equality (same unit and same amount).
• Similarly to the {@link BigDecimal#equals} method which consider 2.0 and 2.00 as different objects because of different internal scales,
• quantities such as Quantities.getQuantity(3.0, KILOGRAM) Quantities.getQuantity(3, KILOGRAM) and
• Quantities.getQuantity("3 kg") might not be considered equals because of possible differences in their implementations.
• To compare measures stated using different units or using different amount implementations the {@link #compareTo compareTo} or
• {@link #equals(javax.measure.Quantity, double, javax.measure.unit.Unit) equals(Quantity, epsilon, epsilonUnit)} methods should be used.
• @param obj

•      the object to compare with.
  

• @return this.getUnit.equals(obj.getUnit())

•     && this.getValue().equals(obj.getValue())</code>
  

*/

[keilw]

Java is rather strict on that, it is not something a JSR 363 implementation introduced or causes.

BigInteger.ONE.equals(Integer.valueOf(1)

to be false as well.

In some particular subtypes like DoubleQuantity a method like doubleValue() could be used to compare it to a given Number instead of applying equals() on that number.

[keilw]

In fact the RI must behave exactly the same here, so any PR or improvement should be available to both.

[otaviojava]

@keilw I can do the same on RI if this change make sense:
#157

[otaviojava]

FWI do it on RI is easier than on SE