You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Marek Šabo (JIRA)" <ji...@apache.org> on 2015/03/09 13:46:38 UTC
[jira] [Updated] (WICKET-5853) LongConverter converts some values
greater than Long.MAX_VALUE
[ https://issues.apache.org/jira/browse/WICKET-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marek Šabo updated WICKET-5853:
-------------------------------
Description:
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]
was:
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]
> 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: 6.19.0
> Reporter: Marek Šabo
>
> 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)