Дано наступний код:
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
}
Здається, очевидно, цей масив toString
, equals
використовуються методи (замість статичних методів Arrays::equals
, Arrays::deepEquals
або Array::toString
).
Тому я думаю, що записи Java 14 ( JEP 359 ) не надто добре працюють з масивами, відповідні методи повинні бути створені за допомогою IDE (який, принаймні, в IntelliJ, за замовчуванням генерує "корисні" методи, тобто вони використовують статичні методи в Arrays
).
Або є якесь інше рішення?
toString()
, equals()
і hashCode()
способи запису реалізовані з використанням invokedynamic посилання. . Якби тільки складений еквівалент класу міг бути ближчим до того, що цей метод Arrays.deepToString
робить у приватному перевантаженому методі сьогодні, він міг би вирішити для випадків примітивів.
Object
, оскільки це може статися і з визначеними користувачем класами. наприклад, неправильні рівні
invokedynamic
абсолютно не має нічого спільного з підбором семантики; indy тут є чистою деталізацією реалізації. Компілятор міг би випустити байт-код, щоб зробити те саме; це був просто більш ефективний і гнучкий спосіб дістатися. Під час проектування записів широко обговорювалося, чи використовувати більш нюансовану семантику рівності (таку як глибока рівність для масивів), але це виявилося, що спричинило набагато більше проблем, ніж передбачалося.
List
замість масиву?