[
https://issues.apache.org/jira/browse/WICKET-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367527#comment-14367527
]
Marek Šabo commented on WICKET-5853:
------------------------------------
Hi Sven,
we can of course use BigIntegers or BigDecimals.
Our specification allows numbers in the Long range so we used that and hit a
corner-case. We fixed it by setting RangeValidator max to the Long.MAX_VALUE -
1 which works as a viable workaround for us.
So you might say that from this point on it's a theoretical exercise. In my
books it's a bug because it contract of AbstractNumberConverter#parse() is not
honored. It's up to you guys to decide what to do with it. I can see that a
signature change at such place is risky and gain is meager.
Another curious thing I noticed while working on this is that 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
(forced by method signature).
> 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)
