[
https://issues.apache.org/jira/browse/WW-5828?focusedWorklogId=1051628&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1051628
]
ASF GitHub Bot logged work on WW-5828:
--------------------------------------
Author: ASF GitHub Bot
Created on: 31/Oct/26 13:40
Start Date: 31/Oct/26 13:40
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #2086:
URL: https://github.com/apache/struts/pull/2086
Fixes [WW-5828](https://issues.apache.org/jira/browse/WW-5828)
Backport of the change on `main` to the 6.x line, adjusted for the
`com.opensymphony.xwork2` package layout and the `X.class.isInstance(value)`
style this line uses.
WW-5711 bounded `maximumFractionDigits` to 340 in `StringConverter`, 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: `DecimalFormat` applies it
by dropping the leading digits rather than by rounding.
This change bounds the integer digit count (`precision - scale`, computed in
`long` because the subtraction overflows `int` at the extreme of the scale
range) to 340 and, past it, falls back to `BigDecimal.toString()`. Every
`double` still formats in full; the existing test pins `Double.MAX_VALUE` at
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+340` style scientific notation instead of its full digits, and such a value
no longer round-trips through a form because the parser does not accept the
`E+` form. The same kind of trade-off as the rounding introduced by WW-5711.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1051628)
Time Spent: 20m (was: 10m)
> StringConverter does not bound integer digits when formatting BigDecimal
> ------------------------------------------------------------------------
>
> Key: WW-5828
> URL: https://issues.apache.org/jira/browse/WW-5828
> Project: Struts 2
> Issue Type: Bug
> Components: Core
> Reporter: Lukasz Lenart
> Priority: Major
> Fix For: 6.13.0, 7.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> WW-5711 bounded {{maximumFractionDigits}} to 340 in
> {{StringConverter.convertToString()}}, so the length of a formatted
> {{BigDecimal}} no longer follows a large positive scale. The integer side has
> no equivalent bound: {{DecimalFormat}} keeps its default
> {{maximumIntegerDigits}} of {{Integer.MAX_VALUE}}, and for a {{BigDecimal}}
> with a large negative scale it pads the integer part out to the full value,
> so the length of the output follows the scale of the value rather than its
> precision — the counterpart of WW-5711 on the other side of the decimal point.
> {{setMaximumIntegerDigits}} is not the right bound. {{DecimalFormat}} applies
> it by dropping the leading digits rather than by rounding, so an ordinary
> value wider than the bound would format as its trailing digits only.
> Bound the number of integer digits ({{precision() - scale()}}) to the same
> 340 instead. A {{BigDecimal}} within that bound formats exactly as before;
> 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
> tests pin that.
> Add a regression test covering the bound on both sides of it.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
