Ensure consistency between NumberUtils.isCreatable and createNumber for extreme exponents by FloydDsilva · Pull Request #1623 · apache/commons-lang

FloydDsilva · 2026-04-04T17:25:27Z

Background
NumberUtils.isCreatable(String) previously returned true for certain scientific‑notation inputs (e.g. 1E-2147483648) that cannot be represented by any Java Number type. Calling NumberUtils.createNumber with such inputs resulted in a NumberFormatException, breaking the implied contract between the two methods.

Changes

Updated isCreatable to reject unrepresentable negative exponents in scientific notation.
Refined exponent parsing to correctly handle type suffixes (D, F, L) and preserve valid inputs.
Updated createNumber to gracefully handle NumberFormatException raised during BigDecimal creation by propagating a consistent and descriptive failure for invalid values.

Result
These changes restore consistency between isCreatable and createNumber, ensuring that isCreatable only returns true for values that createNumber can successfully construct, while keeping existing behavior intact for all valid numeric representations across supported Java versions.

Test cases for the same has been added.

…NO-BREAK SPACE

…rror handling for invalid exponential formats in createNumber and updated isCreatable to handle edge cases. Added new test cases for extreme exponent values.

garydgregory · 2026-04-04T17:53:30Z

Hello @FloydDsilva

-1: The build fails. Please run 'mvn' by itself before you push.

…h its test cases

garydgregory · 2026-04-05T11:09:07Z

+        try {
+            return createBigDecimal(str);
+        } catch (final NumberFormatException ignored) {
+            throw new NumberFormatException(str + " is not a valid number.");


This doesn't seem necessary. Also the original cause is lost, making the input harder to debug.

garydgregory

@FloydDsilva

Please see my comment.

…atch block for createBigDecimal.

… removing unnecessary line breaks and ensuring consistent formatting.

FloydDsilva · 2026-04-05T13:46:48Z

sorry for the failed build it did not give me any issue when i ran "mvn"

FloydDsilva · 2026-04-05T14:14:49Z

i think the behaviour for BigDecimal for java 8 and java 21 is different for 1E2147483648

garydgregory · 2026-04-05T14:19:17Z

i think the behaviour for BigDecimal for java 8 and java 21 is different for 1E2147483648

Then you'll need to account for that...

…rge exponent values based on Java version. Updated corresponding test cases for consistency.

garydgregory

Hello @FloydDsilva

Thank you for your updates. Please see my comment.
TY!

garydgregory · 2026-04-07T11:34:50Z

                }
            } catch (final NumberFormatException ignored) {
-                return false;
+                return ("2147483648".equals(expStr) || "+2147483648".equals(expStr)) && SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_21);


This is rather messy IMO. You'll need to provide comments here to explain what's going on. The magic strings should likely be derived from constants like Integer.MAX_VALUE.

Hey i have refactored the code and also added more test cases. Kindly let me know about if more changes are required.

garydgregory · 2026-04-07T11:35:52Z

        compareIsCreatableWithCreateNumber(".e10", false); // LANG-1646
        compareIsCreatableWithCreateNumber(".e10D", false); // LANG-1646
+        compareIsCreatableWithCreateNumber("1E-2147483648", false);
+        compareIsCreatableWithCreateNumber("1E2147483648", SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_21));


You need more tests around the edge cases.
TY!

…xponent values for Java 21 and later. Added comprehensive test cases to validate behavior for various exponent scenarios.

garydgregory · 2026-04-08T18:18:06Z

@FloydDsilva

I had to fix more Checkstyle errors... Do run mvn as noted in the PR template before you push and fix all issues please.

garydgregory

@FloydDsilva

The unit tests fail.

…rgest positive exponent and enhance test cases for various exponent formats, including edge cases for Java 21 compatibility.

garydgregory · 2026-04-11T14:11:07Z

Hi @chtompki

Does this look OK to you from a mathy POV?

chtompki · 2026-04-14T15:12:22Z

Thinking...like the edge case testing with exponent

chtompki · 2026-04-14T17:39:20Z

We could simply wrap instantiation in a try catch. Return true if it works and false if it doesnt? May not be as efficient but it would work exactly

NumberUtils.createNumber(String), exactly Add tests from PR apache#1623

garydgregory · 2026-04-15T19:55:34Z

See #1626 for simpler solution CC @chtompki

…(String), exactly (#1626) * Add testLang1641() * Rename some test methods * NumberUtils.isCreatable(String) should match NumberUtils.createNumber(String), exactly Add tests from PR #1623

garydgregory · 2026-04-16T13:30:16Z

Closing in favor of #1626

FloydDsilva · 2026-04-16T18:41:02Z

Closing in favor of #1626
Hi @garydgregory, it’s a neat and simple approach.

However, I don’t think using createNumber directly inside isCreatable is a good fit here, mainly for two reasons:

1)Performance considerations: isCreatable is commonly used in loops and validation paths. Calling createNumber would introduce object creation and additional overhead, which would be a noticeable regression for a method intended to be lightweight.

2)Separation of concerns: isCreatable is designed as a validation method that checks whether number creation is viable, not to actually construct the number. If callers already need to invoke createNumber, validating by constructing the number twice defeats the purpose of having a separate, inexpensive check.

Is there some perspective i haven't accounted for or i am missing? can you help me out?

garydgregory · 2026-04-16T20:09:43Z

Hello @FloydDsilva

The main issue, I think, is having two methods with distinct, complex custom parsing code that attempts (and has obviously failed) to match not only what the JRE number classes allow but also our own rules. In addition, we want the methods to be consistent with each other, if the "is" method returns true, then the "create" method should always work, and vice versa.

Unless it is measured (say with a JMH benchmark), we'll never know. Unfortunately, even with a benchmark, there are many "it depends". For example, classes like Integer, Short, Long, Byte, and Character, but not Float and Double, have their own cache to reduce object creation. Another is that the parsing code is going to favor, intentionally or not, one type over another. Parsing in the "is" method wasn't allocation free either.

HTH

floyd.dsilva added 3 commits April 3, 2026 17:43

Add javadoc examples for StringUtils.isBlank to include EM SPACE and …

f46776c

…NO-BREAK SPACE

reverting past commit f46776c

260ba9c

Enhance NumberUtils to improve number parsing and validation. Added e…

1537408

…rror handling for invalid exponential formats in createNumber and updated isCreatable to handle edge cases. Added new test cases for extreme exponent values.

Added code formatting and fixed positive exponent behaviour along wit…

a46c98f

…h its test cases

garydgregory reviewed Apr 5, 2026

View reviewed changes

garydgregory requested changes Apr 5, 2026

View reviewed changes

floyd.dsilva added 2 commits April 5, 2026 18:27

Reverted createNumber method in NumberUtils to remove redundant try-c…

a521f17

…atch block for createBigDecimal.

Refactor isCreatable method in NumberUtils to improve code clarity by…

8d4ed1c

… removing unnecessary line breaks and ensuring consistent formatting.

Enhance isCreatable method in NumberUtils to handle edge cases for la…

dbbe9b4

…rge exponent values based on Java version. Updated corresponding test cases for consistency.

garydgregory requested changes Apr 7, 2026

View reviewed changes

garydgregory reviewed Apr 7, 2026

View reviewed changes

floyd.dsilva and others added 3 commits April 8, 2026 22:06

Refine isCreatable method in NumberUtils to accurately handle large e…

9ba768a

…xponent values for Java 21 and later. Added comprehensive test cases to validate behavior for various exponent scenarios.

Fix Checkstyle error.

22284a0

Fix more Checkstyle errors.

5be0c0e

garydgregory requested changes Apr 8, 2026

View reviewed changes

Update isCreatable method in NumberUtils to use a constant for the la…

8ac4ea3

…rgest positive exponent and enhance test cases for various exponent formats, including edge cases for Java 21 compatibility.

garydgregory added a commit to garydgregory/commons-lang that referenced this pull request Apr 15, 2026

NumberUtils.isCreatable(String) should match

0739ddb

NumberUtils.createNumber(String), exactly Add tests from PR apache#1623

garydgregory mentioned this pull request Apr 15, 2026

NumberUtils.isCreatable(String) should match NumberUtils.createNumber(String), exactly #1626

Merged

5 tasks

garydgregory closed this Apr 16, 2026

Conversation

FloydDsilva commented Apr 4, 2026

Uh oh!

garydgregory commented Apr 4, 2026

Uh oh!

garydgregory Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

garydgregory left a comment

Choose a reason for hiding this comment

Uh oh!

FloydDsilva commented Apr 5, 2026

Uh oh!

FloydDsilva commented Apr 5, 2026

Uh oh!

garydgregory commented Apr 5, 2026

Uh oh!

garydgregory left a comment

Choose a reason for hiding this comment

Uh oh!

garydgregory Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

FloydDsilva Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

garydgregory Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

garydgregory commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

garydgregory left a comment

Choose a reason for hiding this comment

Uh oh!

garydgregory commented Apr 11, 2026

Uh oh!

chtompki commented Apr 14, 2026

Uh oh!

chtompki commented Apr 14, 2026

Uh oh!

garydgregory commented Apr 15, 2026

Uh oh!

garydgregory commented Apr 16, 2026

Uh oh!

FloydDsilva commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

garydgregory commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

garydgregory commented Apr 8, 2026 •

edited

Loading

FloydDsilva commented Apr 16, 2026 •

edited

Loading