[
https://issues.apache.org/jira/browse/WW-5828?focusedWorklogId=1051627&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1051627
]
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, #2085:
URL: https://github.com/apache/struts/pull/2085
Fixes [WW-5828](https://issues.apache.org/jira/browse/WW-5828)
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, so an ordinary value
wider than the bound would format as its trailing digits only.
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()`, 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.
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.
A 6.x backport follows in a separate PR.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1051627)
Remaining Estimate: 0h
Time Spent: 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: 10m
> 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)
