Adds support to BigDecimal in JsonPrimitive#equals

[MaicolAntali]

Purpose

Fixes #904

Description

Currently a BigDeciamal is cast to a double and this can give issue if the number doesn't fit in it.

double a = getAsNumber().doubleValue();
double b = other.getAsNumber().doubleValue();
return a == b || (Double.isNaN(a) && Double.isNaN(b));

I have implemented a ternary operator to check if a number is a BigDecimal and in that case use the proper equals method.

Checklist

• New code follows the Google Java Style Guide
• If necessary, new public API validates arguments, for example rejects null
• New public API has Javadoc
  • Javadoc uses @since $next-version$
    ($next-version$ is a special placeholder which is automatically replaced during release)
• If necessary, new unit tests have been added
  • Assertions in unit tests use Truth, see existing tests
  • No JUnit 3 features are used (such as extending class TestCase)
  • If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
• mvn clean verify javadoc:jar passes without errors

[MaicolAntali]

This assert probably is overkill because is already tested here:

gson/gson/src/test/java/com/google/gson/JsonPrimitiveTest.java

Lines 246 to 250 in 3adead6

	public void testFloatEqualsBigDecimal() {
	JsonPrimitive p1 = new JsonPrimitive(10.25F);
	JsonPrimitive p2 = new JsonPrimitive(new BigDecimal("10.25"));
	assertThat(p1).isEqualTo(p2);
	assertThat(p1.hashCode()).isEqualTo(p2.hashCode());

It's here to be consistent with the code in the issue #904

[Marcono1234]

@MaicolAntali, could you please merge main into your branch and fix the new Error Prone warning:

[WARNING] /gson/src/main/java/com/google/gson/JsonPrimitive.java:[294,47] [OperatorPrecedence] Use grouping parenthesis to make the operator precedence explicit
    (see https://errorprone.info/bugpattern/OperatorPrecedence)
  Did you mean 'return (this.value instanceof BigDecimal && other.value instanceof BigDecimal)'?

To me these changes look reasonable, and they should solve #904. I assume there might be some other cases where comparing BigDecimal with primitive values such as double or long might still cause precision loss, but if necessary that can be addressed later.

@eamonnmcmanus, what do you think?

[Marcono1234]

@MaicolAntali, could you please merge main into the branch of this PR, mainly to be sure it passes the formatting checks? Sorry for the trouble.

[MaicolAntali]

Don't worry, help it's a pleasure!

[Marcono1234]

As side note / for future reference: I originally proposed using compareTo when this code was also comparing BigDecimal with non-BigDecimal, see #2364 (comment).

However, using compareTo instead of equals here has another advantage: It ensures JsonPrimitive.equals is transitive (as required by Object.equals), at least when wrapping a BigDecimal.

(x equals y and y equals z) implies x equals z

Now let

• x = new JsonPrimitive(new BigDecimal("0"))
• y = new JsonPrimitive(0.0d)
• z = new JsonPrimitive(new BigDecimal("0.00"))

Using compareTo makes sure that equals is transitive. Whereas using BigDecimal.equals here would cause: x equals y and y equals z (because they fall back to double comparison), but x !equals z, which would not be transitive.

[eamonnmcmanus]

Thanks for doing this! I ran it against all of Google's internal tests and everything passed.