Шпаргалка по sealed-иерархиям в Java!

На картинке показано, как sealed-класс ограничивает прямых наследников. Одни ветки закрываются через final, другая остаётся контролируемой через sealed, а non-sealed снова разрешает свободное наследование.

Например, для фиксированного набора фигур можно явно перечислить допустимые реализации Shape. Это помогает выразить границы модели прямо в типах и облегчает проверку вариантов при работе с pattern matching.

Сохрани, чтобы не потерять!

👉 Java Ready | #ресурс

Следим за появлением файлов в папке через WatchService!

Создадим наблюдатель и зарегистрируем каталог. Папка должна существовать заранее:

Path dir = Path.of("incoming");
try (WatchService watcher = FileSystems.getDefault().newWatchService()) {
    dir.register(watcher, ENTRY_CREATE, ENTRY_MODIFY);

Константы ENTRY_CREATE и ENTRY_MODIFY берутся из StandardWatchEventKinds. try-with-resources закроет наблюдатель при выходе из блока.

Дальше ждём сигнал. Метод take блокирует поток, пока событие не появится:

    while (true) {
        WatchKey key = watcher.take();
        for (WatchEvent<?> event : key.pollEvents()) {

Контекст события содержит имя относительно наблюдаемой папки, а не готовый абсолютный путь. Не подставляй его отдельно от dir:

            if (event.kind() == OVERFLOW) continue;
            Path file = dir.resolve((Path) event.context());
            System.out.println(event.kind() + " " + file);
        }

После обработки обязательно сбросим ключ. Если каталог удалён или больше недоступен, reset вернёт false:

        if (!key.reset()) break;
    }
}

События могут повторяться, а при перегрузке наблюдатель сообщит OVERFLOW. Поэтому важную обработку лучше делать идемпотентной и предусмотреть повторное сканирование каталога после переполнения.

👉 Java Ready | #практика

Почему после Stream.toList() нельзя добавить элемент?

При работе со Stream часто нужно собрать результаты обратно в список. Короткая запись выглядит естественно:

var names = Stream.of("Ana", "Bob").toList();

Но у Stream.toList() есть важное свойство, он возвращает немодифицируемый список. Такой код не добавит третье имя:

names.add("Cyd");

Вместо изменения списка программа получит UnsupportedOperationException. То же произойдёт при remove или set.

Если нужен готовый результат только для чтения, это как раз удобно:

List<String> labels = users.stream()
    .map(User::name)
    .toList();

Вызывающий код не сможет случайно поменять состав labels. При этом сами элементы могут оставаться изменяемыми, не модифицируемость списка не делает глубоко неизменяемыми объекты внутри него.

Если список нужно дополнять после сбора, задайте изменяемую коллекцию явно:

var names = Stream.of("Ana", "Bob")
    .collect(Collectors.toCollection(ArrayList::new));

Теперь add и remove доступны. Есть и вариант обернуть готовый результат:

var names = new ArrayList<>(stream.toList());

Выбирайте способ сбора по тому, что будет происходить со списком дальше. Для чтения подойдёт toList(), для дальнейших изменений лучше явно создать ArrayList.

👉 Java Ready | #совет

Безопасная настройка retry для всей системы!

В статье Java-разработчик делится опытом внедрения политики повторных попыток в проекте с Kafka и цепочкой микросервисов. Одной аннотации недостаточно, когда результат операции может оказаться неизвестным, а сообщение пройти обработку дважды.

Автор разбирает:
• какие ошибки имеет смысл повторять, а какие нет
• чем отличаются блокирующие и неблокирующие retry у Kafka consumer
• как повторы на нескольких уровнях создают лишнюю нагрузку

Продолжай читать на Habr!

👉 Java Ready | #статья