これまでは、.equals()の演算子オーバーロードは==でした。しかし、私は最近Groovy ==演算子
new Integer(1).equals(new Long(1)) // returns false
に対し
new Integer(1) == new Long(1) // returns true
ことを発見したので、私は==は正確に.equals()の短縮形ではないので、どのようにそれは平等を決定しないと思いますか？
==equals()とほぼ同等である、しかし、あなたは同じ値を持つ異なるクラスを比較するとき、それはJavaから違う見つける - クラスがComparableある場合。可能であれば、Groovyも型キャストを行います。
コードをチェックアウトすると、最終的にが==に対して実行されたように見えます。
がequals()に委任されていないことが判明した場合は、compareToに委任します。
new Integer(1) == new Long(1)
が、これは必ずしもその
new Integer(1).equals(new Long(1))
意味するものではありません。もしa.compareTo(b)戻り0
ので==は、この特定のケース
new Integer(1).compareTo(new Long(1)) == 0
ので、そのためにだから、trueを返しますこれがなぜとても奇妙で混乱しているのかの理由は、contract of Comparableは、equalsと一致する必要はありませんが、強くお勧めします。
自然の順序が等しいことが強く推奨されます（必須ではありません）。これは、明示的コンパレータのないソートされたセット（およびソートされたマップ）が、自然順序付けがequalsと矛盾する要素（またはキー）とともに使用されるとき、「妙に」振舞うためです。 Groovyで
これは、長いデータベースIDを持つGORMを使用しているときに引き続き私に噛み付きます。 JSONからのリクエストは、次のような動作を生成する整数値を生成しました： groovy：000> m> [1L： 'foo'] ===> [1：foo] groovy：000> m.containsKey（1L） ===> true groovy：000> m.containsKey（1） ===> false –