org.sonar.l10n.java.rules.squid.S2111.html Maven / Gradle / Ivy

Go to download

Show more of this group Show more artifacts with this name
Show all versions of java-checks Show documentation

The newest version!

Because of floating point imprecision, you're unlikely to get the value you expect from the BigDecimal(double) constructor. 
From the JavaDocs:
The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.
Instead, you should use BigDecimal.valueOf, which uses a string under the covers to eliminate floating point rounding errors.
Noncompliant Code Example

double d = 1.1;

BigDecimal bd1 = new BigDecimal(d); // Noncompliant; see comment above
BigDecimal bd2 = new BigDecimal(1.1); // Noncompliant; same result

Compliant Solution

double d = 1.1;

BigDecimal bd1 = BigDecimal.valueOf(d);
BigDecimal bd2 = BigDecimal.valueOf(1.1);

See


 CERT, NUM10-J - Do not construct BigDecimal ojbects from floating-point literals