Fino ad ora, la mia comprensione era che == è un sovraccarico dell'operatore per .equals(). Tuttavia, di recente ho scoperto cheGroovy == operatore
new Integer(1) == new Long(1) // returns true
mentre
new Integer(1).equals(new Long(1)) // returns false
quindi credo == non è esattamente una scorciatoia per .equals(), così come fa a determinare l'uguaglianza?
== in Groovy è grosso modo equivalente a equals(), tuttavia, troverete che è diverso da Java quando si confrontano diverse classi con lo stesso valore - se la classe è Comparable. Groovy esegue anche il casting, se possibile.
Se si controlla il codice, sembra che alla fine compareToWithEqualityCheck() venga eseguito per ==.
Si scopre che == non è delegato a equals(), delega a compareTo. Così == restituirà vero se a.compareTo(b) restituisce 0
Quindi, in questo caso particolare
new Integer(1).compareTo(new Long(1)) == 0
così dunque:
new Integer(1) == new Long(1)
ma questo non vuol necessariamente dire che
new Integer(1).equals(new Long(1))
Il La ragione per cui tutto ciò è così strano e confuso è perché l'contract of Comparable non richiede che sia coerente con gli uguali, sebbene sia fortemente raccomandato.
Si consiglia vivamente (anche se non obbligatorio) che gli ordini naturali siano coerenti con gli uguali. Questo perché i set ordinati (e le mappe ordinate) senza comparatori espliciti si comportano "stranamente" quando vengono utilizzati con elementi (o chiavi) il cui ordinamento naturale è incoerente con gli uguali.
Questo continua a mordermi quando si utilizza GORM, che ha ID database lunghi. Richieste da valori interi generati da JSON che producono un comportamento come: groovy: 000> m = [1L: 'foo'] ===> [1: foo] groovy: 000> m.containsKey (1L) ===> true groovy: 000> m.containsKey (1) ===> false –