Краткий ответ

Set.of требует, чтобы все переданные элементы были уникальны. При обнаружении дубликата фабричный метод выбрасывает IllegalArgumentException, потому что создание набора с неоднозначным входом считается ошибкой, а не обычной операцией добавления, которую можно бездействием проигнорировать.

Исторический контекст

Фабричные методы коллекций Set.of, List.of и Map.of появились в Java 9, чтобы упростить создание небольших неизменяемых коллекций без явного создания изменяемого объекта и последующей настройки.

Такой подход решает две задачи: сокращает шаблонный код и позволяет сразу проверить ограничения входных данных. Для множества это отсутствие дубликатов, а для этих фабрик также недопустимость null.

Постановка проблемы

Обычный вызов add у множества является операцией над уже существующей коллекцией. Если элемент уже присутствует, метод обычно возвращает false, а состояние коллекции не меняется — это нормальный результат повторной вставки.

Фабрика Set.of выполняет другую роль: она строит коллекцию из набора аргументов. Если среди аргументов есть дубликаты, молчаливое удаление повторов может скрыть ошибку в конфигурации, списке разрешений или наборе констант. Поэтому неверный вход отклоняется сразу.

Подробное решение

Контракт Set.of гарантирует создание неизменяемого множества без повторяющихся элементов. Если два аргумента считаются равными согласно правилам множества, создание завершается IllegalArgumentException.

Проверка дубликатов опирается на семантику равенства элементов, используемую конкретной реализацией неизменяемого множества. Для обычных объектов это практически означает согласованное применение equals и hashCode; полагаться на конкретное внутреннее представление или точную сложность проверки нельзя, поскольку API этого не обещает.

Отдельно обрабатывается null: фабрики Set.of не допускают null и выбрасывают NullPointerException. Это отличается от некоторых изменяемых реализаций, например HashSet, которые допускают один null.

После успешного создания результат нельзя изменять: операции добавления и удаления завершаются UnsupportedOperationException. Это не то же самое, что обычный Set, где повторная вставка возвращает false; в данном случае коллекция уже создана как неизменяемая структура.

Важно не переносить это поведение на все фабрики. Например, Set.copyOf также создаёт неизменяемый набор, но при передаче коллекции с дубликатами документация не обещает выброс исключения: в результат попадёт один из равных элементов. Если требуется обнаруживать дубли именно во входных данных, Set.of и Set.copyOf нельзя считать взаимозаменяемыми.

Минимальный пример:

import java.util.Set;

class Demo {
    public static void main(String[] args) {
        Set<String> roles = Set.of("reader", "writer", "reader");
    }
}

Вызов завершается IllegalArgumentException ещё до получения ссылки на коллекцию. Это позволяет обнаружить ошибку при инициализации, а не после незаметного удаления повторяющегося значения.

Ситуация из практики

В сервисе набор разрешений для роли задаётся при запуске приложения. В конфигурации по ошибке дважды указано разрешение write.

Вариант с HashSet автоматически устранит дубликат. Его плюс — простота и возможность дальнейшего изменения, но минус — ошибка конфигурации останется незаметной. Вариант с List, проверкой уникальности и последующим преобразованием в множество даёт контроль, но требует дополнительного кода и легко реализуется непоследовательно.

Выбран Set.of для фиксированного набора разрешений. Приложение завершается с явной ошибкой на этапе инициализации, а успешно созданный набор нельзя случайно изменить во время работы. Для динамических данных этот вариант не подходит: там нужна изменяемая реализация множества и явная политика обработки повторов.

Что кандидаты часто упускают

Одинаковы ли правила для Set.of и обычного add?

Нет. add сообщает о повторе возвращаемым значением false и оставляет множество без изменений. Set.of не изменяет уже существующую коллекцию, а валидирует весь набор аргументов при создании и сообщает о дубликате исключением. Это различие связано с разными контрактами операции добавления и фабрики.

Что произойдёт, если элементы равны по equals, но имеют разные hashCode?

Такое нарушение контракта equals и hashCode делает поведение коллекций некорректным и непредсказуемым с точки зрения ожидаемой семантики. Фабрика не обязана надёжно обнаруживать такой дубликат: корректность определения равенства предполагает, что равные объекты имеют одинаковый hashCode. Ошибку нужно исправлять в классе элемента, а не обходить подбором другой коллекции.

Можно ли использовать Set.of, если дубликаты нужно игнорировать?

Нет, если игнорирование повторов является нормальным сценарием. Тогда следует использовать изменяемое множество, например HashSet, и учитывать результат add, либо заранее явно нормализовать входные данные. Set.of предназначен для декларативного создания фиксированного набора, где повтор аргумента обычно рассматривается как ошибка, а не как допустимая ситуация.