-
Bug
-
Resolution: Fixed
-
P4
-
17, 18, 19
-
b06
-
generic
-
generic
-
Verified
A DESCRIPTION OF THE PROBLEM :
A previous bug report was filed asJDK-8183912 which was fixed and now causes these two functions to not allocate a new BigDecimal if called with n==0 argument. However, this behavior can be wrong according to the java docs for each function. The last sentence of movePointLeft() says "The BigDecimal returned by this call has value (this × 10-n) and scale max(this.scale()+n, 0)."
Example:
new BigDecimal("1e3").movePointLeft(0);
result on jdk 17 is 1e3 (scale -3)
However, the expected scale according to the java docs is max(this.scale()+n, 0) which is max(-3, 0) or scale of 0.
Therefore the expected value is 1000 (scale 0). This behavior seems to be correct in older versions of Java.
FREQUENCY : always
A previous bug report was filed as
Example:
new BigDecimal("1e3").movePointLeft(0);
result on jdk 17 is 1e3 (scale -3)
However, the expected scale according to the java docs is max(this.scale()+n, 0) which is max(-3, 0) or scale of 0.
Therefore the expected value is 1000 (scale 0). This behavior seems to be correct in older versions of Java.
FREQUENCY : always
- csr for
-
JDK-8289504 BigDecimal movePointLeft() and movePointRight() do not follow their API spec
- Closed
- relates to
-
JDK-8183912 java.math.BigDecimal.movePointLeft() should return this if called with zero argument
- Resolved
-
JDK-8289934 Release Note: Restore Behavior of java.math.BigDecimal.movePointLeft() and movePointRight() on a Zero Argument
- Resolved