Repository navigation
WW-5828 Bound integer digits when formatting BigDecimal (6.x) - #2086
Merged
lukaszlenart merged 2 commits intoNov 1, 2026
Merged
lukaszlenart merged 2 commits into
lukaszlenart merged 2 commits into
Conversation
WW-5711 bounded maximumFractionDigits to 340, so the length of a formatted BigDecimal no longer follows a large positive scale. The integer side had no equivalent bound: DecimalFormat keeps its default maximumIntegerDigits of Integer.MAX_VALUE and pads the integer part of a value with a large negative scale out in full, so the output length followed the scale of the value rather than its precision. setMaximumIntegerDigits is not the right bound, because DecimalFormat applies it by dropping the leading digits rather than by rounding. Bound the integer digit count (precision - scale, computed in long because the subtraction overflows int at the edge of the scale range) to 340 and, past it, fall back to BigDecimal.toString(), which renders the value compactly in scientific notation. Every double still formats in full; the widest, Double.MAX_VALUE, has 309 integer digits and the existing test pins it. Backport of the same change on main, adjusted for the com.opensymphony.xwork2 package layout of this line. Fixes: https://issues.apache.org/jira/browse/WW-5828 Co-Authored-By: Claude Mythos 5.1 <noreply@anthropic.com>
lukaszlenart
marked this pull request as ready for review
October 31, 2026 14:26
Use instanceof for the BigDecimal check (S6202) and drop the throws clause the new test does not need (S1130). Co-Authored-By: Claude Mythos 5.1 <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes WW-5828
Backport of the change on
mainto the 6.x line, adjusted for thecom.opensymphony.xwork2package layout and theX.class.isInstance(value)style this line uses.WW-5711 bounded
maximumFractionDigitsto 340 inStringConverter, so the length of a formattedBigDecimalno longer follows a large positive scale. The integer side had no equivalent bound:DecimalFormatkeeps its defaultmaximumIntegerDigitsofInteger.MAX_VALUEand pads the integer part of a value with a large negative scale out in full, so the output length followed the scale of the value rather than its precision.setMaximumIntegerDigitsis not the right bound:DecimalFormatapplies it by dropping the leading digits rather than by rounding.This change bounds the integer digit count (
precision - scale, computed inlongbecause the subtraction overflowsintat the extreme of the scale range) to 340 and, past it, falls back toBigDecimal.toString(). Everydoublestill formats in full; the existing test pinsDouble.MAX_VALUEat 309 integer digits.The regression test pins both sides of the bound, the far case, and the scale boundary.
Observable change: a value with more than 340 integer digits now renders as
1E+340style scientific notation instead of its full digits, and such a value no longer round-trips through a form because the parser does not accept theE+form. The same kind of trade-off as the rounding introduced by WW-5711.🤖 Generated with Claude Code