Dato il seguente codice:
public static void main(String[] args) {
record Foo(int[] ints){}
var ints = new int[]{1, 2};
var foo = new Foo(ints);
System.out.println(foo); // Foo[ints=[I@6433a2]
System.out.println(new Foo(new int[]{1,2}).equals(new Foo(new int[]{1,2}))); // false
System.out.println(new Foo(ints).equals(new Foo(ints))); //true
System.out.println(foo.equals(foo)); // true
}
Sembra, ovviamente, tale matrice toString
, equals
metodi sono utilizzati (invece di metodi statici, Arrays::equals
, Arrays::deepEquals
o Array::toString
).
Quindi suppongo che Java 14 Records ( JEP 359 ) non funzionino troppo bene con le matrici, i rispettivi metodi devono essere generati con un IDE (che almeno in IntelliJ, per impostazione predefinita genera metodi "utili", cioè usano i metodi statici in Arrays
).
O c'è qualche altra soluzione?
toString()
, equals()
e hashCode()
metodi di un record sono implementati utilizzando un riferimento invokedynamic. . Se solo l'equivalente di classe compilato avrebbe potuto essere più vicino a quello che il metodo Arrays.deepToString
fa oggi nel suo metodo di sovraccarico privato, avrebbe potuto risolvere i casi di primitive.
Object
, poiché ciò potrebbe accadere anche con classi definite dall'utente. ad esempio, uguale a errato
invokedynamic
ha assolutamente nulla a che fare con la selezione della semantica; indy è un puro dettaglio di implementazione qui. Il compilatore avrebbe potuto emettere bytecode per fare la stessa cosa; questo era solo un modo più efficiente e flessibile per arrivarci. Durante la progettazione dei record è stato ampiamente discusso se usare una semantica di uguaglianza più sfumata (come l'uguaglianza profonda per le matrici), ma ciò si è rivelato causare molti più problemi di quanto si supponesse risolto.
List
invece di un array?