[
https://issues.apache.org/jira/browse/WW-5711?focusedWorklogId=1038885&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1038885
]
ASF GitHub Bot logged work on WW-5711:
--------------------------------------
Author: ASF GitHub Bot
Created on: 31/Aug/26 18:45
Start Date: 31/Aug/26 18:45
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1888:
URL: https://github.com/apache/struts/pull/1888
6.x backport of #1887.
`StringConverter` formatted `BigDecimal`, `Double` and `Float` with
`maximumFractionDigits` set to `Integer.MAX_VALUE`.
That constant arrived with
[WW-4871](https://issues.apache.org/jira/browse/WW-4871), which fixed
round-trip precision loss for `double` and `float`. Both of those types are
naturally bounded — the widest `double` needs 325 fraction digits
(`Double.MIN_VALUE`) and the widest `float` needs 45 — so `Integer.MAX_VALUE`
is far wider than WW-4871 required.
`BigDecimal` carries 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 instead.
### Differences from the main-line change
Same change, adjusted for this line: the class sits under
`com.opensymphony.xwork2.conversion.impl` rather than
`org.apache.struts2.conversion.impl`, and the surrounding code uses the
`X.class.isInstance(value)` idiom, which is left as it is. Not a cherry-pick.
### Backward compatibility
Every `double` and `float` value still formats in full, so WW-4871's
behaviour is preserved exactly. Every `BigDecimal` with a scale of 340 or less
is also unchanged. A `BigDecimal` scaled 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:
`testDoubleToStringConversionPL` pins `Double.MIN_VALUE` at 325 fraction
digits, and `testBigDecimalToStringConversionPL` pins a value slightly wider
than `double` at 326.
### Scope
Render side only. `NumberConverter.convertToBigDecimal` is unchanged in this
PR.
### Testing
The new test was confirmed failing on `support/struts-6-x-x` before the fix
was applied, then green after. Full suite: `mvn test -DskipAssembly -pl core` —
2728 tests, 0 failures.
Fixes [WW-5711](https://issues.apache.org/jira/browse/WW-5711)
Issue Time Tracking
-------------------
Worklog Id: (was: 1038885)
Time Spent: 0.5h (was: 20m)
> StringConverter does not bound fraction digits when formatting BigDecimal
> -------------------------------------------------------------------------
>
> Key: WW-5711
> URL: https://issues.apache.org/jira/browse/WW-5711
> Project: Struts 2
> Issue Type: Bug
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 6.12.0, 7.4.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{StringConverter.convertToString()}} sets
> {{format.setMaximumFractionDigits(Integer.MAX_VALUE)}} for {{BigDecimal}},
> {{Double}} and {{Float}}.
> That constant arrived with WW-4871, which fixed round-trip precision loss
> when formatting {{double}} and {{float}}. Both of those types are naturally
> bounded — the widest {{double}} needs 325 fraction digits
> ({{Double.MIN_VALUE}}) and the widest {{float}} needs 45 — so
> {{Integer.MAX_VALUE}} is far wider than WW-4871 actually required.
> {{BigDecimal}} carries 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 is driven by the scale of
> the value rather than by anything the formatter decides.
> Bound {{maximumFractionDigits}} to 340 instead. That preserves WW-4871's
> intent exactly — every {{double}} and {{float}} value still formats in full,
> as does every {{BigDecimal}} within that range — while making the output
> length independent of an arbitrarily large scale.
> Add a regression test covering the bound.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
