Details

    • Sub-task
    • Status: Reopened
    • Major
    • Resolution: Unresolved
    • 1.8-beta-3
    • None
    • groovy-runtime
    • 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

      Attachments

        Activity

          People

            Unassigned Unassigned
            jonfelch Jonathan Felch
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: