Community
Participate
Working Groups
I had a look at the code of assertEquals and noticed something interesting. The current implementation relies on EolObjectComparator, which compares two numbers like this: return ((Number) o1).doubleValue() == ((Number) o2).doubleValue(); This line has one problem: large integer values (likely Long values) will be rounded down, making different integers seem to be equal. Indeed, adding this line inside testCompareIntegers() in the ComparisonTests.eol file in the EOL acceptance tests project makes the test fail: assertEquals(9223372036854775807l == 9223372036854775806l, true); To fix this, I propose that the Java Language Specification is followed more closely, particularly regarding sections 5.6.1 ("unary numeric promotion") and 5.6.2 ("binary numeric promotion"), in the NumberUtil and EolObjectComparator classes: http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.6.1
Created attachment 191322 [details] Patch which fixes the problem and makes NumberUtil follow JLS 5.6.1 and 5.6.2 Here is a patch which reimplements sections 5.6.1 and 5.6.2 of the Java Language Specification to fix the problem and heavily reduce the number of casts in NumberUtil.
> Indeed, adding this line inside testCompareIntegers() in the > ComparisonTests.eol file in the EOL acceptance tests project makes the test > fail: > > assertEquals(9223372036854775807l == 9223372036854775806l, true); Oops, I meant these two lines: assertEquals(9223372036854775807l == 9223372036854775807l, true); assertEquals(9223372036854775807l == 9223372036854775806l, false);
The above patch has been integrated for a while. Closing this bug as fixed.
Fixed in 0.9.1
