[
https://issues.apache.org/jira/browse/WICKET-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367599#comment-14367599
]
Sven Meier commented on WICKET-5853:
------------------------------------
Hi Marek,
>both BigInteger and BigDecimal can not have arbitrary size because they are
>bound
>in the range of -Double.MAX_VALUE and Double.MAX_VALUE in their respective
>converters
this is what I thought too initially.
But it is not the case actually - the double value of very large BigDecimal is
Double.MAX_VALUE, thus the converter will not complain.
> LongConverter converts some values greater than Long.MAX_VALUE
> --------------------------------------------------------------
>
> Key: WICKET-5853
> URL: https://issues.apache.org/jira/browse/WICKET-5853
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 7.0.0-M5, 6.19.0
> Reporter: Marek Šabo
> Priority: Minor
>
> Currently it's possible to submit some values via Long Textfield<Long> that
> are greater than Long.MAX_VALUE. This will produce converted input and model
> update with value of Long.MAX_VALUE
> I'm not sure what the behavior should be - imho throwing ConversionException
> seems fair as the input isn't a valid Long.
> The reason seems to be precision loss during Double.valueOf(input) execution
> while converting, and then comparing to Long.MAX_VALUE using
> Long.doubleValue() in *AbstractNumberConverter*, which by casting leads to to
> the same precision loss and the numbers are seemingly equal during comparison
> of ranges.
> Maybe using BigDecimals for parsing could help here.
> The quickstart is available at
> [https://github.com/zeratul021/wicket-number-conversion].
> For the fastest demonstration I extended Wicket's _longConversion()_
> test-case in *ConvertersTest*:
> [https://github.com/zeratul021/wicket-number-conversion/blob/master/src/test/java/com/github/zeratul021/wicketnumberconversion/ConvertersTest.java#L300]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
