Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NumberUtils.convertNumberToTargetClass does not report overflow when converting BigInteger to Long [SPR-11434] #16060

Closed
spring-projects-issues opened this issue Feb 16, 2014 · 2 comments
Assignees
Labels
type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Feb 16, 2014

Tom Leccese opened SPR-11434 and commented

I was expecting that the NumberUtils.convertNumberToTargetClass method might throw an exception when converting a BigInteger to a Long if the BigInteger value is less than Long.MIN_VALUE or greater than Long.MAX_VALUE.

In other words I would not expect this test to pass:
assertEquals(Long.valueOf(Long.MIN_VALUE),NumberUtils.convertNumberToTargetClass(BigInteger.valueOf(Long.MAX_VALUE).add(BigInteger.ONE), Long.class));

... yet it passes due to the two's complement rollover from max to min value.

Attached are a modified version of NumberUtils and NumberUtilsTests which have a fix that will cause an exception to be thrown when the targetClass is Long, the number is an instance of BigInteger or BigDecimal, and the value of the number is outside the range of the long domain. Feel free to use the "fix" if you think this issue is a bug in the NumberUtils class.


Affects: 3.2.7

Attachments:

Issue Links:

Referenced from: commits 4744180

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Indeed, NumberUtils doesn't really have well-defined rules for overflowing there. We'll try to address this in the 4.1 line.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Turns out that this is effectively analogous to JDK 8's BigInteger.longValueExact() method, which we of course can't use there but we're now addressing the same issue through min/max comparisons.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants