1. Overview
Sometimes, we must compare the numbers, ignoring their classes or types. This is especially helpful if the format isn’t uniform and the numbers might be used in different contexts.
In this tutorial, we’ll learn how to compare primitives and numbers of different classes, such as Integers, Longs, and Floats. We’ll also check how to compare floating points to whole numbers.
2. Comparing Different Classes
Let’s check how Java compares different primitives, wrapper classes, and types of numbers. To clarify, in the context of this article, we’ll refer to the “types” as floating point and whole numbers and not as the classes or primitive types.
2.1. Comparing Whole Primitives
In Java, we have several primitives to represent whole numbers. For simplicity’s sake, we’ll talk only about int, long, and double. If we want to check if one number is equal to another one, we can do it without any issues while using primitives:
@ValueSource(strings = {"1", "2", "3", "4", "5"})
@ParameterizedTest
void givenSameNumbersButDifferentPrimitives_WhenCheckEquality_ThenTheyEqual(String number) {
int integerNumber = Integer.parseInt(number);
long longNumber = Long.parseLong(number);
assertEquals(longNumber, integerNumber);
}At the same time, this approach doesn’t work well with overflows. Technically, in this example, it would clearly identify that the numbers aren’t equal:
@ValueSource(strings = {"1", "2", "3", "4", "5"})
@ParameterizedTest
void givenSameNumbersButDifferentPrimitivesWithIntegerOverflow_WhenCheckEquality_ThenTheyNotEqual(String number) {
int integerNumber = Integer.MAX_VALUE + Integer.parseInt(number);
long longNumber = Integer.MAX_VALUE + Long.parseLong(number);
assertNotEquals(longNumber, integerNumber);
}However, if we experience an overflow in both values, it can lead to incorrect results. Though it’s hard to shoot ourselves in the foot, it is still possible with some manipulations:
@Test
void givenSameNumbersButDifferentPrimitivesWithLongOverflow_WhenCheckEquality_ThenTheyEqual() {
long longValue = BigInteger.valueOf(Long.MAX_VALUE)
.add(BigInteger.ONE)
.multiply(BigInteger.TWO).longValue();
int integerValue = BigInteger.valueOf(Long.MAX_VALUE)
.add(BigInteger.ONE).intValue();
assertThat(longValue).isEqualTo(integerValue);
}
This test would consider the numbers equal, although one is twice as big as the other. The approach might work for small numbers if we don’t expect them to overflow.
2.2. Comparing Whole and Floating Point Primitives
While comparing whole numbers to floating point numbers using primitives, we have a similar situation:
@ValueSource(strings = {"1", "2", "3", "4", "5"})
@ParameterizedTest
void givenSameNumbersButDifferentPrimitivesTypes_WhenCheckEquality_ThenTheyEqual(String number) {
int integerNumber = Integer.parseInt(number);
double doubleNumber = Double.parseDouble(number);
assertEquals(doubleNumber, integerNumber);
}This happens because the integers would be upcasted to doubles or floats. That’s why if we have even a small difference between the numbers, the equality operation would behave as expected:
@ValueSource(strings = {"1", "2", "3", "4", "5"})
@ParameterizedTest
void givenDifferentNumbersButDifferentPrimitivesTypes_WhenCheckEquality_ThenTheyNotEqual(String number) {
int integerNumber = Integer.parseInt(number);
double doubleNumber = Double.parseDouble(number) + 0.0000000000001;
assertNotEquals(doubleNumber, integerNumber);
}However, we still have some issues with the precision and overflow. Thus, we cannot be entirely sure of the correctness of the results, even when we compare the same types of numbers:
@Test
void givenSameNumbersButDifferentPrimitivesWithDoubleOverflow_WhenCheckEquality_ThenTheyEqual() {
double firstDoubleValue = BigDecimal.valueOf(Double.MAX_VALUE).add(BigDecimal.valueOf(42)).doubleValue();
double secondDoubleValue = BigDecimal.valueOf(Double.MAX_VALUE).doubleValue();
assertEquals(firstDoubleValue, secondDoubleValue);
}Imagine that we need to compare the fraction using two different percentage representations. In the first case, we use floating point numbers, where 1 represents 100%. In the second case, we use whole numbers to identify percentages:
@Test
void givenSameNumbersWithDoubleRoundingErrors_WhenCheckEquality_ThenTheyNotEqual() {
double doubleValue = 0.3 / 0.1;
int integerValue = 30 / 10;
assertNotEquals(doubleValue, integerValue);
}
Therefore, we cannot rely on primitive comparison, especially if we use calculations involving floating point numbers.
3. Comparing Wrappers Classes
While using wrapper classes, we’ll receive a different result from the one we got comparing primitives:
@ValueSource(strings = {"1", "2", "3", "4", "5"})
@ParameterizedTest
void givenSameNumbersButWrapperTypes_WhenCheckEquality_ThenTheyNotEqual(String number) {
Float floatNumber = Float.valueOf(number);
Integer integerNumber = Integer.valueOf(number);
assertNotEquals(floatNumber, integerNumber);
}Although the Float and Integer numbers were created from the same numerical representations, they aren’t equal. However, the issue might be because we compare different types of numbers: floating point and whole numbers. Let’s check the behavior with Integer and Long:
@ValueSource(strings = {"1", "2", "3", "4", "5"})
@ParameterizedTest
void givenSameNumbersButDifferentWrappers_WhenCheckEquality_ThenTheyNotEqual(String number) {
Integer integerNumber = Integer.valueOf(number);
Long longNumber = Long.valueOf(number);
assertNotEquals(longNumber, integerNumber);
}Oddly enough, we have the same result. The main issue here is that we try to compare different classes in the Number hierarchy. In most cases, the first step in the equals() method is to check if the types are the same. For example, Long has the following implementation:
public boolean equals(Object obj) {
if (obj instanceof Long) {
return value == ((Long)obj).longValue();
}
return false;
}
This is done to avoid any issues with transitivity and is generally a good rule to follow. However, it doesn’t solve the problem of comparing two numbers with different representations.
4. BigDecimal
While comparing integers with floating point numbers, we can take the same route as in the previous case: convert the numbers to the representation with the most precision and compare them. The BigDecimal class is the perfect fit for this.
We’ll consider two cases, the number with the same scale and the numbers with different scales:
static Stream<Arguments> numbersWithDifferentScaleProvider() {
return Stream.of(
Arguments.of("0", "0.0"), Arguments.of("1", "1.0"),
Arguments.of("2", "2.0"), Arguments.of("3", "3.0"),
Arguments.of("4", "4.0"), Arguments.of("5", "5.0"),
Arguments.of("6", "6.0"), Arguments.of("7", "7.0")
);
}
static Stream<Arguments> numbersWithSameScaleProvider() {
return Stream.of(
Arguments.of("0", "0"), Arguments.of("1", "1"),
Arguments.of("2", "2"), Arguments.of("3", "3"),
Arguments.of("4", "4"), Arguments.of("5", "5"),
Arguments.of("6", "6"), Arguments.of("7", "7")
);
}We won’t check the different numbers as it’s a trivial case. Also, we won’t see cases where comparison rules are heavily based on domain logic.
Let’s check the numbers with the same scale first:
@MethodSource("numbersWithSameScaleProvider")
@ParameterizedTest
void givenBigDecimalsWithSameScale_WhenCheckEquality_ThenTheyEqual(String firstNumber, String secondNumber) {
BigDecimal firstBigDecimal = new BigDecimal(firstNumber);
BigDecimal secondBigDecimal = new BigDecimal(secondNumber);
assertEquals(firstBigDecimal, secondBigDecimal);
}The BigDecimal behaves as expected. Now let’s check the numbers with different scales:
@MethodSource("numbersWithDifferentScaleProvider")
@ParameterizedTest
void givenBigDecimalsWithDifferentScale_WhenCheckEquality_ThenTheyNotEqual(String firstNumber, String secondNumber) {
BigDecimal firstBigDecimal = new BigDecimal(firstNumber);
BigDecimal secondBigDecimal = new BigDecimal(secondNumber);
assertNotEquals(firstBigDecimal, secondBigDecimal);
}The BigDecimal treats numbers 1 and 1.0 as different. The reason is that the equals() method in BigDecimal uses the scale while comparing. Even if numbers differ only in the trailing zeroes, they would be considered non-equal.
However, another method in the BigDecimal API provides the logic we need for our case: the compareTo() method. It doesn’t consider trailing zeros and works perfectly to compare numbers:
@MethodSource("numbersWithDifferentScaleProvider")
@ParameterizedTest
void givenBigDecimalsWithDifferentScale_WhenCompare_ThenTheyEqual(String firstNumber, String secondNumber) {
BigDecimal firstBigDecimal = new BigDecimal(firstNumber);
BigDecimal secondBigDecimal = new BigDecimal(secondNumber);
assertEquals(0, firstBigDecimal.compareTo(secondBigDecimal));
}
Thus, while BigDecimal is a good and the most reasonable choice to solve this problem, we should consider the quirk with the equals() and compareTo() methods.
5. AssertJ
If we use the AssertJ library, we can simplify the assertion code and make it more readable:
@MethodSource("numbersWithDifferentScaleProvider")
@ParameterizedTest
void givenBigDecimalsWithDifferentScale_WhenCompareWithAssertJ_ThenTheyEqual(String firstNumber, String secondNumber) {
BigDecimal firstBigDecimal = new BigDecimal(firstNumber);
BigDecimal secondBigDecimal = new BigDecimal(secondNumber);
assertThat(firstBigDecimal).isEqualByComparingTo(secondBigDecimal);
}Additionally, we can provide a comparator for more complex logic if needed.
6. Conclusion
Often, we need to compare the numbers as they are, ignoring the types and classes. By default, Java can work with some values, but in general, direct comparison of primitives is error-prone, and comparing wrappers won’t work as intended.
The BigDecimal is an excellent solution to the issue. However, it has a non-intuitive behavior regarding the equals() and hashCode() methods. Thus, we should consider it while comparing the numbers and using BigDecimals.
As usual, all the code from this article is available over on GitHub.
