⚠️ Java продолжает готовиться к удалению finalize()

В рамках JDK 27 у ThreadPoolExecutor-а, очень популярного API в Java, будет удалён метод finalize(). Несмотря на то, что в силу dynamic dispatch вызов метода finalize() всё равно будет транслирован в Object, данное изменение не source level compatible.

А все потому, что у Object.finalize() сигнатура содержит throws Throwable, в то время как ThreadPoolExecutor.finalize() — нет. Пока метод был в ThreadPoolExecutor, компилятору было ок. Как только его удалят, вызов super.finalize() начнет резолвиться в Object.finalize(), и тогда прилетит “unreported exception Throwable”.

Комментарий от Михаила Поливаха:

Вот это кстати довольно редкий пример того, что имзенение может быть binary level compatible, но не source level compatible.

Например:

class MyPool extends ThreadPoolExecutor {
  @Override
  protected void finalize() {
    super.finalize(); // JDK 27: теперь это Object.finalize() throws Throwable
  }
}

Как избежать?

* поискать и удалить любые finalize() / super.finalize() (и вообще любые авто-cleanup через финализацию)
* управлять жизненным циклом executor’ов явно: shutdown()/awaitTermination() или просто close() в try-with-resources (да, ExecutorService — AutoCloseable)

Spring АйО рекомендует не использовать finalize() в целом, но если подобного рода хук нужен, то лучше использовать Java Cleaner API. С его помощью нельзя "случайно" воскресить объект, сломать integrity объекта или т.п.

Ждем JDK 27 🫠

Разрыв в неизменяемости: почему Java Records нужны оптики (Lenses)

Records и pattern matching сделали чтение вложенных данных в Java удобным. Но обновить поле глубоко внутри неизменяемой структуры все еще больно: чтобы поменять одну строку (street у адреса менеджера отдела), приходится вручную пересобирать каждый record по пути. В примере это около 25 строк с каскадом копирующих конструкторов и риском ошибки на каждом уровне.

Потенциально новые методы withX() в record помогают мало: обновленное значение все равно нужно протаскивать назад через Address -> Employee -> Department -> Company. Даже JEP 468 (with для records, preview в JDK 25) упрощает один уровень, но не поддерживает вложенное обновление, поэтому получаются цепочки with на каждом слое.

Оптики закрывают этот разрыв: это типобезопасные, компонуемые пути доступа, которые позволяют один раз описать маршрут и дальше читать/писать по нему. Базовая оптика - Lens (ровно 1 цель), есть Prism (0/1 вариант sealed), Affine (0/1 без построения), Traversal (0..many для коллекций). Скомпонованные линзы сами выполняют промежуточную реконструкцию, и обновление превращается в одно простое выражение.

📚 Полный текст по ссылке: https://habr.com/ru/companies/spring_aio/articles/1001066/

❗️Spring АйО на Java Rock Stars meetup ❗️

Друзья, по традиции, эксперты Spring АйО выступят на ближайшем Java Rock Stars meetup.

5 марта. Москва. Лофт Casa Picassa на Бауманской.

💬 В программе:

– Илья и Фёдор Сазоновы расскажут о том, как обычные проекты внезапно начинают задыхаться при масштабировании, хотя пользователей и данных там не так много. Узнаем о причине проблем с производительностью и главном правиле работы с реляционными БД, которое регулярно нарушают.

– Александр Ланцов покажет, как работа со строками и произвольным Unicode в Java может поставить в тупик даже опытного разработчика, и разберёт типичные ошибки на примерах.

Для участия нужна только регистрация.

✈️ Когда использовать параллельный стрим в Java?

parallelStream() не всегда быстрее: в бенчмарке sum(1..100) в параллели занял ~35 476 нс/оп против ~68 нс/оп в последовательном.

Параллельные стримы работают через ForkJoinPool.commonPool (кол-во потоков: ядра CPU - 1). Порядок обработки элементов не фиксирован, а некорректный reduce может дать неверный итог: identity прибавляется в каждом worker`е (например, reduce(5, sum)).

Где параллельные стримы реально полезны:

– Большой объем данных и много вычислений на элемент (так называемая модель NQ: чем больше N*Q, тем выше шанс ускорения; для тривиального суммирования эмпирически N > 10 000).

– Источник легко и равномерно делится: массивы и ArrayList. На 1 000 000 элементов ArrayList в бенчмарке быстрее в параллели (~2.0 мс vs ~5.4 мс).

– Дешевая операция объединения результатов: reduce/sum обычно выигрывают. Например, сумма на ArrayList быстрее в параллели (~2.07 мс vs ~5.51 мс).

– Хорошая локальность данных. Например, массив примитивов (int[]) даёт больший выигрыш, чем массив ссылок (Integer[]), потому что меньше скачков по памяти.

– Есть I/O с большим числом объектов: поиск по 1500 текстовым файлам через Files.walk в параллели быстрее (~10.8 мс vs ~13.3 мс).

📚 Подробнее тут: https://habr.com/ru/companies/spring_aio/articles/1005180/