Java 25
Год назад обещал рассказать про Java 25, а тут уже неделю как Java 27 зарелизилась. Зато можно сверить свои прогнозы с последними исследованияии.
Материалы:
— Дискуссия «Горячие JEP’ы 25: юбилейное» на JPoint 2025:
* YouTube
* VK Видео
* Презентация
— Доклад «Есть время объяснять, переходим на Java 25» на Podlodka Java Crew:
* YouTube
* Презентация
LTS-версии Java:
— Java 11 — 2018
— Java 17 — 2021
— Java 21 — 2023
— Java 25 — 2025
На новые LTS мигрируют независимо от того, насколько значимые изменения были в этой версии. По результатам исследований видно (см. презентацию выше), что старые версии продолжают использоваться на протяжении долгого времени («хвост» медленно усыхает), но «мейнстримная» версия сменяется приблизительно через 3 года с момента релиза.
За последние годы значимых изменений в самом языке было немного, а основной фокус был направлен на внутренние изменения (JVM) и развитие библиотеки классов (API, реализация). Таким образом, переход на новую версию обусловлен либо естественным обновлением на свежую версию, либо качественным отличием рантайма. Мой прогноз из 2025 года: переход на Java 25 будет идти более высокими темпами как раз благодаря второму пути. Во-первых, в экосистеме Java сложилась уникальная ситуация — среда исполнения поддерживает несколько алгоритмов сборки мусора, нацеленных на разные аспекты производительности (пропускная способность и латентность приложений). Во-вторых, в Java «доезжают» JEP-ы, задуманные 10-15 лет назад (или ещё раньше), но реализация которых была осложнена заботой о «священной корове» Java (сохранении обратной совместимости).
Возвращаясь к теме GC: на текущий момент у нас есть выбор из 4-х production ready сборщиков мусора:
— Parallel GC, максимизирующий throughput приложения за счёт минимального оверхеда.
— ZGC, минимизирующий паузы в приложении, хорошо подходит для огромных хипов.
— G1GC — отличный сборщик мусора по умолчанию (читай — для общего случая, когда heap < 32GB), нацеленный на некоторый баланс между throughput и latency, смещённый в сторону пропускной способности приложения. В самой свежей версии JDK 27, вышедшей буквально неделю назад, благодаря JEP 532, G1GC стал сборщиком мусора по умолчанию для всех вариантов развёртывания.
— Shenandoah — ещё один GC, нацеленный на баланс между пропускной способностью и паузами, но нацеленный на обеспечение коротких пауз в том числе на больших хипах.
Выбирайте подходящий алгоритм GC в зависимости от профиля нагрузки. При этом важно не только погонять на обычном уровне нагрузке, но и на экстремальном (когда из кластера реплик выпадает их часть, когда случается наплыв пользователей из-за 11.11 и т.п.).
Как я уже упомянул выше, в прошлом году при обсуждении Java 25 я прогнозировал более высокую скорость распространения. И вот, спустя полгода-год, при подготовке State of Java 2026 мы видим, что этот тренд подтвердился. Причин этому много, но самое главное: Java (JVM) ускоряется прямо «из коробки», когда простая смена версии рантайма позволяет получить прирост в скорости работы. В планах на JPoint 2026 сделать выступление про увеличение производительности JVM на реальных задачах за последние 15 лет.
Чек-лист для перехода на новую версию Java
— BOM (Bill of materials): заявлена совместимость у библиотек и фреймворков, зависимости обновить при необходимости
— Не используется закрытый и удалённый API, перейти на альтернативный API при необходимости
— Провалидировано изменение настроек и поведения по списку JEP-ов
— Проведено функциональное и performance тестирование, проведено сравнение результатов «до» и «после»
— Обновлены инструкции по эксплуатации (метрики, GC, ...)
— Новые фичи используем в следующую итерацию!
И переходим на Java 25+ в проде, дамы и господа! 🎉
#java #jvm #материалы #видеозаписи #доклад #jpoint #podlodka
