Étant donné le code suivant:
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
}
Il semble, de toute évidence, de ce tableau toString
, les equals
méthodes sont utilisées ( au lieu de méthodes statiques, Arrays::equals
, Arrays::deepEquals
ou Array::toString
).
Donc je suppose que les enregistrements Java 14 ( JEP 359 ) ne fonctionnent pas trop bien avec les tableaux, les méthodes respectives doivent être générées avec un IDE (qui au moins dans IntelliJ, génère par défaut des méthodes "utiles", c'est-à-dire qu'elles utilisent les méthodes statiques dans Arrays
).
Ou existe-t-il une autre solution?
toString()
, equals()
et les hashCode()
méthodes d'un enregistrement sont mises en œuvre en utilisant une référence invokedynamic. . Si seulement l'équivalent de classe compilé aurait pu être plus proche de ce que fait la méthode Arrays.deepToString
dans sa méthode privée surchargée aujourd'hui, il aurait pu résoudre les cas de primitives.
Object
, car cela pourrait également arriver avec les classes définies par l'utilisateur. par exemple des égaux incorrects
invokedynamic
n'a absolument rien à voir avec la sélection de la sémantique; indy est un pur détail d'implémentation ici. Le compilateur aurait pu émettre du bytecode pour faire la même chose; c'était juste un moyen plus efficace et plus flexible pour y arriver. Lors de la conception des enregistrements, il a été longuement discuté de l'opportunité d'utiliser une sémantique d'égalité plus nuancée (telle qu'une égalité profonde pour les tableaux), mais cela s'est avéré causer bien plus de problèmes qu'il n'en aurait résolu.
List
au lieu d'un tableau?