Skip to content

Reject out-of-range long and float values in NumberConverter (1.X)#405

Merged
garydgregory merged 1 commit into
apache:1.Xfrom
rootvector2:numberconverter-long-float-range-1x
Jun 26, 2026
Merged

Reject out-of-range long and float values in NumberConverter (1.X)#405
garydgregory merged 1 commit into
apache:1.Xfrom
rootvector2:numberconverter-long-float-range-1x

Conversation

@rootvector2

Copy link
Copy Markdown
Contributor

Port of #404 to the 1.X branch. @garydgregory asked to verify whether the fix applies there, and it does, identically.

NumberConverter.toNumber(Class, Number) range-checks the byte/short/int branches, but the Long branch has no bounds check and the Float branch only checks the upper bound, so an out-of-range value is silently clamped instead of rejected: a Double/BigInteger/BigDecimal beyond long range is truncated/clamped to Long.MAX_VALUE, a locale-parsed String past long range comes back from DecimalFormat as a Double and gets clamped the same way, and a Number below -Float.MAX_VALUE becomes -Infinity. Fix adds the missing bounds checks to the Long branch and the lower bound to the Float branch, mirroring the existing branches, so out-of-range input throws ConversionException.

Regression tests added to LongConverterTest (testInvalidAmount, testLocaleStringOutOfRange) and FloatConverterTest (negative overflow); they fail without the runtime change. Both converter test classes pass. The full mvn run is green except for LocaleBeanificationTest.testContextClassloaderIndependence, which already fails on an unmodified 1.X checkout in my environment (it passes in isolation) and is unrelated to this change.

  • Read the contribution guidelines for this project.
  • Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
  • I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
  • Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
  • Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

The Long branch had no bounds check and the Float branch checked only the
upper bound, so out-of-range input was silently clamped to Long.MAX_VALUE or
to -Infinity instead of throwing. Add the missing checks mirroring the
byte/short/int branches. Ports the master fix (apache#404) to 1.X.
@garydgregory garydgregory changed the title reject out-of-range long and float values in NumberConverter (1.X) Reject out-of-range long and float values in NumberConverter (1.X) Jun 26, 2026
@garydgregory garydgregory merged commit 138d455 into apache:1.X Jun 26, 2026
8 checks passed
@garydgregory

Copy link
Copy Markdown
Member

TY @rootvector2 , merged 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants