You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Lukasz Lenart (Jira)" <ji...@apache.org> on 2026/08/31 18:43:00 UTC
[jira] [Work started] (WW-5711) StringConverter does not bound fraction digits when formatting BigDecimal
[ https://issues.apache.org/jira/browse/WW-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on WW-5711 started by Lukasz Lenart.
-----------------------------------------
> 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: 7.4.0
>
> 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)