public class MyKey {
    private int intProperty;
    private List<String> listProperty;

    public MyKey(int intProperty, List<String> listProperty) {
        this.intProperty = intProperty;
        this.listProperty = listProperty;
    }

    public int getIntProperty() {
        return intProperty;
    }

    public void setIntProperty(int intProperty) {
        this.intProperty = intProperty;
    }

    public List<String> getListProperty() {
        return listProperty;
    }

    public void setListProperty(List<String> listProperty) {
        this.listProperty = listProperty;
    }
}

Надо реализовать методы equals и hashCode.

Также изменяемые объекты в качестве ключа это странный выбор. По крайней мере после того, как они стали ключом, их менять нельзя.

Здравствуйте, vsb, Вы писали:

vsb>Надо реализовать методы equals и hashCode.

Возможно еще сделать объект immutable

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

vsb>>Надо реализовать методы equals и hashCode.

A_L>Возможно еще сделать объект immutable

В идеале — да. Или, по-современному — record. Ещё есть тонкий момент — List, который передали в конструкторе, вызывающий может потом решить поменять. Поэтому с какой-то точки зрения правильно бы его скопировать, а не просто ссылку сохранить. С другой точки зрения возможно, что в 100% случаев его никто менять не будет и будет пустое копирование, которое просто замедляет программу ради борьбы с призрачной угрозой. Я даже не знаю, как в таких случаях поступать. В идеале бы в языке должны быть отдельные интерфейсы для иммутабельных структур, но в жаве что-то не додумались до сих пор.

Здравствуйте, vsb, Вы писали:

vsb>В идеале — да. Или, по-современному — record. Ещё есть тонкий момент — List, который передали в конструкторе, вызывающий может потом решить поменять. Поэтому с какой-то точки зрения правильно бы его скопировать, а не просто ссылку сохранить. С другой точки зрения возможно, что в 100% случаев его никто менять не будет и будет пустое копирование, которое просто замедляет программу ради борьбы с призрачной угрозой. Я даже не знаю, как в таких случаях поступать. В идеале бы в языке должны быть отдельные интерфейсы для иммутабельных структур, но в жаве что-то не додумались до сих пор.

Да, в идеале data class котлина + его иммутабл List.

Здравствуйте, Aleksei_Lekomtsev, Вы писали:


A_L>

A_L>public class MyKey {
A_L>    private int intProperty;
A_L>    private List<String> listProperty;
A_L>

Присоединаюсь к господам выше: обязательно копировать лист, обязательно equals + hashCode.
Можно и без этого но тогда бы ты не спрашивал

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Aleksei_Lekomtsev, Вы писали:

vsb>>>Надо реализовать методы equals и hashCode.

A_L>>Возможно еще сделать объект immutable

vsb>В идеале — да. Или, по-современному — record. Ещё есть тонкий момент — List, который передали в конструкторе, вызывающий может потом решить поменять. Поэтому с какой-то точки зрения правильно бы его скопировать, а не просто ссылку сохранить. С другой точки зрения возможно, что в 100% случаев его никто менять не будет и будет пустое копирование, которое просто замедляет программу ради борьбы с призрачной угрозой. Я даже не знаю, как в таких случаях поступать. В идеале бы в языке должны быть отдельные интерфейсы для иммутабельных структур, но в жаве что-то не додумались до сих пор.

То есть если правильно понял, добавляем final для полей и параметров конструктора(хотя может это и не обязательно), удаляем сеттеры и геттер для listProperty, listProperty инициализируем в конструкторе копированием — new ArrayList<>(oldList)

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>То есть если правильно понял, добавляем final для полей и параметров конструктора(хотя может это и не обязательно), удаляем сеттеры и геттер для listProperty, listProperty инициализируем в конструкторе копированием — new ArrayList<>(oldList)

Для параметров final не нужен.

Если нужен геттер для списка, то надо инициализировать примерно как Collections.unmodifiableList(new ArrayList(oldList)). Такой список можно наружу отдать и его не смогут поменять.

Здравствуйте, GarryIV, Вы писали:


GIV>Да, в идеале data class котлина + его иммутабл List.

Ну а в Java — Collections.unmodifiedList

https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#unmodifiableList-java.util.List-

Собственно все зависит от задачи. Вообще, чаще всего объекты лучше в хешмапы в качестве ключа вообще не пихать. А если пихать, то только
иммутабельные. Но в некоторыз задачах (каких, я не вспомню уже, помню что были, кажется интерпретация AST дерева или трансформация дерева) было вполне допустимо у меня пихать именно объект и было пофиг на хешкод, ибо важно был именно сам инстанс объекта, а не его значения.

Соответственно нужно тупо понимание что ты делаешь и для чего.