[
https://issues.apache.org/jira/browse/WW-5711?focusedWorklogId=1038882&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1038882
]
ASF GitHub Bot logged work on WW-5711:
--------------------------------------
Author: ASF GitHub Bot
Created on: 31/Aug/26 18:37
Start Date: 31/Aug/26 18:37
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1887:
URL: https://github.com/apache/struts/pull/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.
### 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
`mvn test -DskipAssembly -pl core` — 3301 tests, 0 failures.
Fixes [WW-5711](https://issues.apache.org/jira/browse/WW-5711)
Issue Time Tracking
-------------------
Worklog Id: (was: 1038882)
Remaining Estimate: 0h
Time Spent: 10m
> 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
> Priority: Major
> Time Spent: 10m
> 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)
