Details
-
Sub-task
-
Status: Reopened
-
Major
-
Resolution: Unresolved
-
1.8-beta-3
-
None
-
None
-
Linux 64 bit
Description
This could be by design, but honestly I doubt it. Consider the following:
---------------------------
def a = 5.0
Integer b = 5i
println "$a => ${a.class}" // BigDecimal as expected
println "$b => ${b.class}" // Integer as expected
println '\nTest using =='
println b == a // true
println a == b // true
println '\nTest using .equals()'
println a.equals(b) // false
println b.equals(a) // false
println '\nTest using .compareTo()'
println a.compareTo(b) // == 0
println b.compareTo(a) // == 0
---------------------------
Why does this surprise me?
- Again and again Groovy's == is explained using Java's .equals() as its reference point, so one might expect the results to be the same
- Although not required, it is recommended in the Java spec that is compareTo(...) == 0 then equals() should equals true
- If a == b isn't calling a.equals(b) under the hood and it isn't using a.compareTo(b) == 0, then I have no idea what method on Number is being called or where to seek documentation
I guess the good news is that a operator b and b operator a had consistent and predictable results in both tests