Java 17 почти никто не заметил, а зря: почему я решил перейти на новую версию

Привет! Меня зовут Никита Земницкий, я Java Developer в NIX и спикер IT-конференции NIX MultiConf. В этой статье я расскажу об основных нововведениях Java 17 на уровнях JDK и JVM, об изменениях в языке, безопасности, платформах, а также сравню популярные сборщики мусора для этой версии. Отдельно разберу недостатки новой Java, которые, на мой взгляд, могут усложнить работу разработчика.

Java 17 появилась в конце прошлого года, но остается почти незаметной на рынке — и это очень досадно. Согласно опросу компании NewRelic, в начале 2022 года большинство разработчиков пользовались 11-й и 8-й версиями Java: около 48,5% и 46,5% соответственно. Доля 17-й составила всего лишь… 0,37%! Думаю, IT-специалистам стоит больше узнать о новой «долговременной» Java, ее преимуществах и трудностях, с которыми можно столкнуться в процессе работы и наконец-то попробовать ее на реальном проекте.

Чем так особенна 17-я версия Java? Ответ прост: это так называемый релиз Long-Term Support, который авторы будут поддерживать до 2029 года.

Предыдущим LTS была Java 11, представленная еще в 2018 году. Конечно, 11-й версией и дальше можно пользоваться и не волноваться о безопасности вплоть до сентября 2026 года. Все найденные уязвимости к этому сроку гарантированно будут исправлены. Но все же прогресс не стоит на месте, поэтому следует попробовать и новую версию.

В отличие от промежуточных версий, LTS используются в большинстве проектов. Каждые шесть месяцев выпускается новая версия Java (non-LTS): от Java 12 до Java 16 включительно, также вышла аналогичная Java 18.

Единственная разница с LTS заключается в том, что ее поддержка истекает с появлением следующей версии. Например, поддержка Java 12 завершается вместе с дебютом Java 13. И если хотите сохранить поддержку, вам нужно перейти на Java 13. Это может вызвать проблемы, если некоторые из ваших зависимостей еще не готовы к новой версии.

Именно поэтому столь важна премьера 17-й версии. Что же в ней интересного?

Основные изменения в JDK

В первую очередь хочу выделить самые главные изменения, произошедшие с JDK:

• Во-первых, из некоторых методов был удален Finalize. С ним была проблема: после «смерти» объекта он ставится в очередь, чтобы Finalize выполнил свою работу. Но по спецификации не гарантируется его выполнение даже до окончания работы JVM. Поэтому от Finalize в самих JDK потихоньку избавляются.
• Во-вторых, незначительные изменения в Java 17 связаны с интерфейсами Packer и Unpacker, реализация класса Pack200. Ранее он больше использовался для внутренних нужд, в связи с чем количество разочарованных из-за удаления пользователей, наверное, будет не столь и большим. Конструктор класса URLDecoder в новой версии вообще исчез.
• В-третьих, при изучении ряда классов AWT и Swing заметно, что многие классы изменили видимость. Как правило, они были публичны, у них все было отовсюду доступно. Сейчас многие классы спрятали. Хотя ключевые интерфейсы все равно остаются видимыми.
• И в конце концов также отмечен для удаления API Applet. То есть пользоваться им можно, но все же это уже не рекомендуется.

Ключевые нововведения в JVM

В Java Virtual Machine больше всего изменений произошло с Garbage-коллекторами — собирателями мусора. CMS здесь удалили, так что вам так или иначе придется выбирать какой-нибудь инструмент этого типа.

По дефолту у нас в системе есть G1. Еще существует ZGC, но он появился как экспериментальный в Java 11. Однако там его лучше не использовать из-за некоторых неисправленных недостатков (это уже тема для отдельной статьи).

Важное новшество — это то, что у G1 появились Abortable Mixed Collection. Во время сбора мусора часть регионов собирается безусловно. Благодаря этому они должны быть собраны полностью. Другая часть, допустим, 20% регионов могут быть собраны в следующий цикл, если текущий не укладывается во временные ограничения.

Также G1 научили аллокировать память и быть NUMA-Aware. Другими словами, для многонодных архитектур выделится место под новые объекты в памяти, находящейся поближе к Thread у исполнителя.

Другие незначительные изменения в JVM нацелены на то, чтобы как можно больше процессов продолжалось параллельно выполнению Java-приложения.

Основная цель — уменьшение пауз, чтобы они не напрягали пользователей, которые не хотят видеть задержки из-за Garbage Collector.

Надо сказать несколько слов и о Just-in-Time-компиляторе. GraalVM теперь находится в отдельном проекте. Главное изменение Java Flight Recorder — это возможность сдерживать события, которые JFR записывает, что позволяет отслеживать изменения в режиме реального времени.

Новинки Java 17

Думаю, многие читатели уже знают их, но хотя бы коротко пробегусь по этой теме. Так, в отношении языка были добавлены Sealed-классы, Switch-выражения, расширенные экземпляры (Enhanced instanceof), текстовые блоки и рекорды (Records).

Также в Java 17 добавили Vector API, но только в инкубатор — то есть этот модуль можно подключить специальной командой. Кроме того, были добавлены Foreign Function и Memory API.

А еще Security Manager теперь отмечен как Deprecate.

Нельзя забывать и об изменениях платформы MacOS: в ней был добавлен рендеринг с использованием Metal API. Также есть полезные Null Pointer Exception, которые, наверное, многие ждали. Они покажут обширную информацию об ошибке — и не только строку, в которой произошла ошибка, но и конкретный объект, который оказался Null.

Отмечу несколько изменений безопасности. Например, были усовершенствованы современная криптография и контекстно-зависимые фильтры десериализации, а также расширенное псевдослучайное число (оно стало еще более псевдослучайным).

G1 против ParallelGC

Отдельно хочу поговорить о сборщиках мусора, тех же Garbage Collectors, о которых я вспоминал выше. Я решил сравнить два распространенных инструмента для Java 17: G1 и ParallelGC.

Garbage-First collector (G1) — это алгоритм сборки мусора, представленный в виртуальной машине Oracle HotSpot Java (JVM) 6 и поддерживаемый начиная с 7 Update 4.

Собиратель мусора G1 — это долгосрочная замена CMS, предназначенная для многопроцессорных машин с большим объемом памяти. G1 пытается с высокой вероятностью достичь цели по времени прекращения сборки мусора, показывая при этом высокую пропускную способность с небольшой потребностью в настройках.

ParallelGC иногда называют сборщиком пропускной способности. Когда работает сборщик мусора, он останавливает все потоки программы и выполняет свое задание, используя несколько потоков. Таким образом работа GC может производиться очень эффективно без перерывов. Обычно это лучший способ минимизировать общее время, которое тратится на работу сборщика мусора по сравнению с работой программы. Но отдельные паузы Java-программы, вызванные GC, могут быть достаточно продолжительными.

Сравнение этих инструментов было бы неполным без статистики. Для этого посмотрим на отчет OptaPlanner, в котором сравнивается скорость сборщиков и показано, насколько для них лучше Java 17.

Подчеркну, что цифры усреднены, но все равно очень показательны. По этим данным, 17-я Java быстрее для G1 на 8,66%, чем 11-я. Также она быстрее по сравнению с прошлой версией и для ParallelGC — на 6,54%. При этом сам ParallelGC на 16,39% быстрее G1.

Из всего этого можно заключить: Java 17 где-то в среднем на 7% эффективнее для сборщиков мусора — и это очень круто.

Недостатки Java 17

Как ни прискорбно об этом говорить, но у новой LTS Java есть не только положительные моменты. Во-первых, в ней отсутствуют 100% обратной совместимости. Мы привыкли, что обратная совместимость — это главная концепция, вокруг которой выстраиваются новые версии Java. Но в 17 было удалено довольно большое количество методов, которые до этого обозначались как deprecated. У разработчиков было достаточно времени, чтобы их удалить. Но для тех, кто этого так и не сделал, у меня плохие новости: ваш проект может просто не скомпилироваться.

Также многие внутренние модули изменили видимость и стали частными. Поэтому теперь у вас нет к ним доступа.

Конечно, практически для всех таких ситуаций был добавлен публичный API, с помощью которого вы можете получить такой доступ. Но это все равно предполагает изменение кода. Кроме того, у новой версии Java нет официальной поддержки от Spring. Это не значит, что инструмент не работает, но теперь официальная гарантия отсутствует.

Главный недостаток Java 17 — потери времени. Ведь если у вас объемный проект, то вы столкнетесь с большим количеством пусть и маленьких, но проблем при переходе на новую версию. Но отмечу сразу: миграция с 11-й на 17-ю версию все же не настолько болезненна, как было во времена с 8-й на 11-ю.

Думаю, все разработчики хорошо помнят этот не самый лучший опыт. Там ведь было очень много зависимостей, которые конфликтовали между собой. Например, наиболее яркой проблемой моего личного перехода стала библиотека djkloyn, которая по неизвестным причинам была несовместима с Worker Thread на Java 11. Поэтому мне вообще пришлось отказаться от ее использования в будущем.

Несмотря на эти моменты, все равно думаю, что стоит попробовать новую версию — недостатки не превышают ее преимущества. Я лично очень рад наконец-то перейти на Java 17. Она лучше и с точки зрения скорости, и с точки зрения новых, реализованных в ней функций и языковых приложений (те же Sealed-классы и Records). Поэтому рекомендую всем переходить на Java 17 и не сидеть на устаревших версиях.

Что дальше?

И напоследок немного слов о том, что нас ждет дальше. Следующий шаг для разработчиков Java запланирован на 20 сентября 2022, когда должен выйти Java 19. Но помните: это non-LTS-версия, в которой будет не так уж много изменений. Поэтому я бы больше ожидал сентября 2023 года, когда должна появиться следующая «полноценная» LTS Java 21. В ней, наверное, будет немало интересного.

Я лично жду появления Project Loom. Давно слежу за этим проектом. В нем должны появиться виртуальные потоки. И пусть сейчас в моих проектах не используется многопоточность, мне было бы интересно попробовать его на практике. Ведь для обычных Java-пользователей Project Loom обещает легкую многопоточность без необходимости перехода на другой язык, использования библиотеки или фреймворка.

Это уже звучит очень хорошо. Но самое важное, как мне кажется, ожидает разработчиков библиотек, которые постоянно должны решать проблему concurrency — снова и снова, и снова… А с таким решением все это можно перевести на JVM, как раньше делали с оптимизацией памяти (GC) и кода (JIT). Это должна быть настоящая революция.