Геттер и сеттер, срабатывающий при прямом обращении к полю

Не делай в сеттерах проверки

...козлёночком станешь.

set/get это не только проверкі (см урлы на код выше) Геттер и сеттер, срабатывающий при прямом обращении к полю (комментарий)

Тут уже советовали. Подключи groovy-all-xxx.jar и будет тебе счастье.

Весь код не читал, но в этом методе я бы

if (dependencies == null) {
            throw new NullPointerException("dependencies");
        }

for (final String dependency : dependencies) {
            if (dependency == null) {
                throw new NullPointerException("dependencies contains null dependency.");
            }
            final String normalisedDependency = normalisePath(dependency);
            if (normalisedDependency.equals(path)) {
                throw new IllegalArgumentException("Cannot add itself as a dependency.");
            }
        }
        this.dependencies.clear();
        for (final String dependency : dependencies) {
            this.dependencies.add(normalisePath(dependency));
        }

this.dependencies.add(normalisePath(dependency));

if (normalisedDependency.equals(path)) {
                throw new IllegalArgumentException("Cannot add itself as a dependency.");
            }

Но еще раз повторюсь, лучше выкинуть нахрен весь этот ужас повыше, в бизнес логику, и упростить pojo по максимуму. Он ведь не обязан гарантировать, что данные в нем обязательно правильные, он их лишь содержит в себе, а за правильностью данных должен следить тот, кто и добавляет их в pojo.

P.S.

if (normalisedDependency.equals(path)) {
                throw new IllegalArgumentException("Cannot add itself as a dependency.");
            }

if (!normalisedDependency.equals(path)) {
    this.dependencies.add(normalisedDependency);
}

Кстати, если не хочешь, чтобы в коллекции были null'ы, то популярным решением является расширение существующей коллекции добавлением проверок где это необходимо. Скажем, иметь «умный» список Dependencies было бы, возможно, удобнее.

Почитай жавакод к функции, подумай. Потом напишешь что это ужас. Ключевые слова - transactionality & incapsulation.

Бины что делают кодеры за деньги/еду видел - их можно мне не предлагать.

Усложнение API + (мне) требуется transactional set.

перенес бы в метод, который вызывает оный сеттер.

Так делать НЕ нужно. Даже в энтэрпрайзе. Потому что потом эти проверки расползутся по коду в каждом месте со своими индийскими прибамбасами.

Он ведь не обязан гарантировать, что данные в нем обязательно правильные, он их лишь содержит в себе, а за правильностью данных должен следить тот, кто и добавляет их в pojo.

Жавадок на функцию с этим не согласен. Весь код построен на гарантии что там нет того что там иметь не положено.

P.S.

Имхо, лучше сделать так:

Exceptions are invented for good.

Скажем, иметь «умный» список Dependencies было бы, возможно, удобнее.

throw new IllegalArgumentException("Cannot add itself as a dependency.");

вот этот кейс нужно было бы костылить передачей ModuleInfo в конструктор коллекции + реализовывать проверку == moduleInfo в многочисленных add/set/merge функциях java.util.Set.

Весь код не читал, но в этом методе я бы «if (dependencies == null)» перенес бы в метод, который вызывает оный сеттер.

Кстати, код, который будет вызывать этот setDependencies пока что не написан - он public и должен использоваться подключаемыми компонентами. Нехорошо доверять состояние об'екта который используется в разных местах сторонним людям.

Так делать НЕ нужно. Даже в энтэрпрайзе. Потому что потом эти проверки расползутся по коду в каждом месте со своими индийскими прибамбасами.

Сделай отдельно примитивный pojo и отдельно - апи которое в него пишет.

Я сделал просто pojo который гарантирует определённое своё состояние. Цэ-подобные структуры заврапленые в set/get + пачка helpers (у каждого - свой) не нужны. Это называется «контракт», который у моей поджы есть.

scala или либа с аннотация которую тебе уже посоветовали.