[kimseongchan0914]

Overview

NumberUtils.convertNumberToTargetClass() already checks for overflow when converting BigInteger and BigDecimal values to integral types (see gh-16060 and gh-18613), but Double and Float values are passed to Number.longValue() unchecked. Values outside the long range therefore saturate silently, and NaN becomes 0.

The same behavior shows up through DefaultConversionService:

DefaultConversionService cs = new DefaultConversionService();
cs.convert(1e20, Integer.class);    // ConversionFailedException (overflow)
cs.convert(1e20, Long.class);       // 9223372036854775807
cs.convert(Double.NaN, Long.class); // 0
cs.convert(1e20, BigInteger.class); // 9223372036854775807
cs.convert(new BigDecimal("1e20"), BigInteger.class); // 100000000000000000000

This PR contains two commits:

1. Detect long overflow for floating-point numbers: checkedLongValue() now rejects Double/Float values outside [-2^63, 2^63), which includes NaN and infinite values. Integral targets, Long among them, now raise the same overflow exception that Integer raises today.
2. Avoid precision loss for floating-point numbers to BigInteger: these values are converted via BigDecimal, the same way the existing BigDecimal to BigInteger path works, instead of being truncated to the long range.

In-range values behave as before, for example 1.5 still converts to 1. SpEL operators and comparisons are not affected, because they handle Double/Float operands before taking the BigInteger path.

Related Issues

• NumberUtils.convertNumberToTargetClass does not report overflow when converting BigInteger to Long [SPR-11434] #16060
• BigDecimal to Integer/Short/Byte should overflow like BigDecimal to Long does [SPR-14041] #18613

[sbrannen]

Hi @kimseongchan0914,

Congratulations on submitting your first PR for the Spring Framework! 👍

The first commit looks good: detecting overflow for Double and Float values when converting to Long makes sense, as does rejecting NaN and infinite values for all integral types. Your range check handles the edge cases correctly, including the exclusive upper bound at 2^63. For readability, you might consider introducing constants for the bounds (-0x1p63 and 0x1p63) instead of using -(double) Long.MIN_VALUE.

However, the second commit introduces a regression for large values that are still within the long range. Float.toString() and Double.toString() return the shortest decimal string that represents the value, not its exact value, so digits are lost. For example:

• 0x1p40f (2^40) is converted to 1099511600000 instead of 1099511627776.
• 0x1p60 (2^60) is converted to 1152921504606847000 instead of 1152921504606846976.

Prior to this PR, both conversions were exact. In addition, converting NaN or an infinite value to BigInteger now fails with a rather cryptic NumberFormatException instead of the overflow exception used for the other integral types.

To address that in the second commit, please:

• Use new BigDecimal(number.doubleValue()).toBigInteger(), which is exact for all finite values and consistent with the existing behavior for in-range values.
• Raise the overflow exception for NaN and infinite values before converting to BigInteger.

Regarding tests, please add assertions for:

• Large in-range values converted to BigInteger (for example, 0x1p40f and 0x1p60), verifying that the results match the Long conversion.
• NaN and infinite values converted to BigInteger, verifying that the overflow exception is thrown.

Since this changes existing behavior (for example, NaN now throws instead of converting to 0), we'll consider it for 7.1 rather than backporting it.

Cheers,

Sam

[kimseongchan0914]

Thanks for the thorough review, @sbrannen!

I've updated both commits:

• Introduced LONG_MIN_AS_DOUBLE / LONG_MAX_AS_DOUBLE_EXCLUSIVE constants for the range check.
• Switched to new BigDecimal(number.doubleValue()).toBigInteger() for exact conversion, and raised the overflow exception for NaN and infinite values before converting.
• Added the requested assertions for 0x1p40f / 0x1p60 (matching the Long conversion) and for NaN / infinite values. I also fixed the existing 1e20f expectation, which had baked in the lossy toString() result.

[sbrannen]

Thanks for making the requested changes.

This has been merged into main in a13ae06 and revised in dfbe36b.