WW-5711 fix(conversion): bound fraction digits when formatting BigDecimal - #1888
Open
lukaszlenart wants to merge 1 commit into
Open
WW-5711 fix(conversion): bound fraction digits when formatting BigDecimal#1888lukaszlenart wants to merge 1 commit into
lukaszlenart wants to merge 1 commit into
Conversation
…imal StringConverter formatted BigDecimal, Double and Float with maximumFractionDigits set to Integer.MAX_VALUE. That constant arrived with WW-4871, which fixed round-trip precision loss for double and float; both of those types are naturally bounded, the widest being Double.MIN_VALUE at 325 fraction digits. BigDecimal has no such bound. DecimalFormat honours maximumFractionDigits literally and pads the fraction out to the value's full scale, so the length of the formatted output followed the scale of the value rather than its precision. Bound the setting to 340. Every double and float value still formats in full, as does every BigDecimal within that range; beyond it the value is rounded to the bound. The existing round-trip assertions for Double.MIN_VALUE (325 fraction digits) and for a BigDecimal slightly wider than double (326) are untouched and still pass. 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-5711 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LwgeV4TN78ke2hHKTVWAUP
|
lukaszlenart
marked this pull request as ready for review
September 1, 2026 05:09
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
1 participant
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.
6.x backport of #1887.
StringConverterformattedBigDecimal,DoubleandFloatwithmaximumFractionDigitsset toInteger.MAX_VALUE.That constant arrived with WW-4871, which fixed round-trip precision loss for
doubleandfloat. Both of those types are naturally bounded — the widestdoubleneeds 325 fraction digits (Double.MIN_VALUE) and the widestfloatneeds 45 — soInteger.MAX_VALUEis far wider than WW-4871 required.BigDecimalcarries no such bound.DecimalFormathonoursmaximumFractionDigitsliterally and pads the fraction out to the value's full scale, so the length of the formatted output followed the scale of the value rather than its precision.Bound the setting to 340 instead.
Differences from the main-line change
Same change, adjusted for this line: the class sits under
com.opensymphony.xwork2.conversion.implrather thanorg.apache.struts2.conversion.impl, and the surrounding code uses theX.class.isInstance(value)idiom, which is left as it is. Not a cherry-pick.Backward compatibility
Every
doubleandfloatvalue still formats in full, so WW-4871's behaviour is preserved exactly. EveryBigDecimalwith a scale of 340 or less is also unchanged. ABigDecimalscaled beyond 340 is now rounded to that bound rather than padded out in full — the only observable difference.The existing round-trip assertions are untouched and still pass:
testDoubleToStringConversionPLpinsDouble.MIN_VALUEat 325 fraction digits, andtestBigDecimalToStringConversionPLpins a value slightly wider thandoubleat 326.Scope
Render side only.
NumberConverter.convertToBigDecimalis unchanged in this PR.Testing
The new test was confirmed failing on
support/struts-6-x-xbefore the fix was applied, then green after. Full suite:mvn test -DskipAssembly -pl core— 2728 tests, 0 failures.Fixes WW-5711