GString hash codes are incorretly calculated

I reproduced this issue with the test case below and found a little more information. The equals() and hashCode() methods seem to be consistent with each other but inconsistent with ==. This is probably because "2" is a java.lang.String and "${2}" is a groovy.lang.GString.

void testEqualsTemplateToLiteral() {
def template = "${2}"
def literal = "2"

// prints "class java.lang.String"
print("literal: ${literal.getClass()}\n")

// prints "class GStringTest$67"
print("template: ${template.getClass()}\n")

// succeeds
assertTrue("template == literal not true", template == literal)

// these all fail
assertTrue("literal not equal to template", literal.equals(template))
assertTrue("template not equal to literal", template.equals(literal))
assertEquals("hash codes not equal", literal.hashCode(), template.hashCode())
}

If it's still a problem, please reopen.

GString and Strings do not have the same hashcode by design.

As Edwin said equals and hashCode are consistent, but

assert "${2}".hashCode() != "2".hashCode() // good
assert "${2}".equals("2") == false // good
assert "${2}" == "2" // bad
assert "2" == "${2}" // bad

surprisingly fails.

The problem is
DefaultTypeTransformation#compareEqual(Object, Object)
which dispatches to
DefaultTypeTransformation#compareToWithEqualityCheck(Object, Object, boolean)
which makes use of the object's Comparable semantics. This is inadequate (and also inefficient) since inequality could be easily proven by GString's equals method.