Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

25 причин обновляться на более новую версию JDK (Часть 1)

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

В цикле статей я хотел бы рассказать о 25 причинах перехода на самую актуальную версию JDK. Конечно, их больше 25 и с каждым новым релизом их становится все больше, поскольку люди могут относиться к этим причинам как угодно, но я попытался составить список наиболее важных изменений в JDK и Java как языке со дня выпуска JDK 9, которые являются вполне весомыми причинами для обновления.

Несмотря на то, что я говорю «причины для обновления до JDK XX», я настоятельно рекомендую вам перейти на последнюю версию, поскольку вы получите больше, чем предлагает эта статья!

Цикл статей будет состоять из нескольких разделов:

  • Среда выполнения и производительность (runtime and performance);
  • Структурирование кода и инструментарий (code structuring and tools);
  • Разработка приложений(Application development).

Некоторые из упомянутых релизов (например, JDK 9) больше не поддерживаются, но когда вы преодолеете барьер между JDK 8 и JDK 9, проблем с обновлением до последней версии — JDK 15 практически не возникнет.

Вообще идея написать цикл таких вот статей возникла после многочисленных обсуждений «сложившихся заблуждений» относительного того, что происходит с Java и области применений, ибо некоторые заблуждения основаны на нежелании бизнеса (в худшем случае разработчика) переходить на более новые версии JDK. Поэтому я решил сформировать свой ТОП 25 причин почему стоит обновляться, а 25 их потому что в 2020-м Java исполнилось 25 лет и данная статья хорошо ложится на хэштег #movedByJava. В общем, приступим...

Runtime and Performance

Причина обновления до JDK 9: Compact Strings

В рамках релиза JDK 9 была представлена новая функция, которая в большинстве случаев, сокращает объем памяти, занимаемой String, вдвое. Если все символы строки могут быть представлены с помощью LATIN-1, тогда будут использоваться только 8 бит, любой другой случай подразумевает UTF16 (16 бит для каждого символа). Причин почему стоит обновляться я думаю ни у кого не возникнет. Так как всегда в коде есть куча сущностей построенных на строках, то любая оптимизация по памяти тут только в плюс!

Для получения дополнительной информации, рекомендую почитать соответствующий JEP openjdk.java.net/jeps/254.

Причина обновления до JDK 11: JDK Flight Recorder

JDK Flight Recorder — это среда сбора данных с низкими накладными расходами для устранения неполадок в приложениях Java и JVM HotSpot. Целями разработки программного комплекса — предоставление API для потребления и создания данных в виде особого типа событий, функций конфигурации и фильтрации, а также в предоставлении событий для ОС, JVM HotSpot и библиотек JDK. Если коротко, то данный фреймворк был создан для генерации и трассировки событий приложения, которые можно отслеживать в реальном времени и/или пост-фактум используя программный комплекс JDK Mission Control.

Одной из наиболее важных целей было сокращение накладных расходов на 1% и 0% при отключенной записи «полета».

JDK Flight Recorder имеет следующие преимущества:

  • Согласованная модель данных упрощает перекрестные ссылки и фильтрацию событий;
  • Набор API позволяющий JDK Flight Recorder отслеживать сторонние приложения, также API для описания и генерации кастомных событий;
  • Позволяет разработчикам тратить меньше времени на диагностику и устранение неполадок, сокращает эксплуатационные расходы и прерывания бизнеса, обеспечивает более быстрое разрешение при возникновении проблем и повышает эффективность системы.

Если совсем по-простому, то использую событийную систему JDK Flight Recorder, можно отслеживать жизненный цикл приложения по всем аспектам жизнедеятельности (память, GC паузы, треды и так далее). Уже на текущий момент многие компоненты стандартной библиотеки JDK уже реализовали поддержку событийной систему JDK Flight Recorder.

Для получения дополнительной информации, рекомендую почитать соответствующий JEP openjdk.java.net/jeps/328.

Причина обновления до JDK 13: динамическое совместное использование классов приложений (AppCDS)

Концепция CDS (class-data sharing) — это отображение памяти классов JDK, доступных только для чтения, среди других JVM, которые были ранее отображены в памяти во время предыдущего выполнения приложения. Основная идея состоит в том, чтобы снизить нагрузку на CPU при загрузке классов и позволить приложению запускаться быстрее (один из шагов решения проблемы, которая носит название «cold start», эта проблема существует в тех средах, где есть необходимость инициализировать саму среду выполнения до запуска самого приложений. Пример: docker — запуск самого контейнера, Python/NodeJS — запуск интерпретатора, Java — инициализация виртуальной машины).

Концепция AppCDS заключается в применении той же концепции CDS, но для классов приложения и их зависимостей.

Типичный алгоритм AppCDS состоит из трех шагов:

  • Создайте список классов для дальнейшего обмена между экземплярами JVM;
  • Собрать архив этих классов;
  • Прикрепите архив к новому экземпляру JVM.

Идея динамического AppCDS состоит в том, чтобы позволить JVM составить список необходимых классов (для приложения), а затем создать динамический архив тех, которые можно использовать для любого другого экземпляра JVM с тем же приложение. Момент сборки архива классов — момент завершения приложения с кодом выхода «0», в противном случае общий архив не будет создан.

Данный функционал вполне себе актуален в современном мире много-экземплярных микросервисов в контейнерных средах типа Docker, K8s. Область применения может быть расширена до концепта serverless, где как раз проблема «холодного старта» весьма критична.

Для получения дополнительной информации прочтите:

Причина обновления до JDK 15: новый сборщик мусора с низкой задержкой — ZGC

ZGC, масштабируемый сборщик мусора с малыми паузами, вероятно, самая важная (production-) фича релиза JDK 15.

Ключевые моменты:

  • Сумма пауз (stop-the-world) не более 10мс (по заявлениям, вскоре, паузы сократятся до 1мс);
  • Может работать с heap различного размера до нескольких терабайт;
  • Перемещение памяти происходит параллельно, чтобы избежать длительных пауз.

Спросите, для кого предназначен этот новый сборщик мусора? Да для всех, без исключений! Независимо от того, какие приложения вы разрабатываете, сетевые приложения, обработка данных с большими кучами (от 8 МБ до 16 ТБ!) И быстрое время отклика.

Для получения дополнительной информации прочтите:

А вот свежий выпуск подкаста Inside.Java с моими коллегами Пер Лиденом и Дэвидом Делабасси inside.java/2020/10/14/podcast-005 как раз на тему ZGC.

На этом я завершу первую часть цикла «причин». На самом деле, если почитать релиз-ноуты к каждой версии, то можно будет убедиться в том, что каждые 6 месяцев разработчики OpenJDK выкатывают очередную порцию новшеств и улучшений. Более того, сами релиз-ноуты показывают те изменения, имплементация которых требует оформления JEP. Но некоторые изменения, на уровне API, не требуют отдельного документа (спецификации). Так что быть Java-разработчиком в 2020 вполне себе интересно, ибо на наших глаза происходит революция инструментария и самого языка.

А вот мне интересно, а что вас сдерживает от обновления на самую актуальную версию JDK?

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

...ага... что сдерживает? IBM SDK 1.8, WebSphere 9.2 и постоянно дырявый Oracle WebLogic (в версии 14.1.1.0 остались уязвимости еще 2018-го года...)... ага и попробуйте безопасности одного из мировых банков объяснить переход на «какую-то Jakarta»... «What is Jakarta?» «This is the brand new Java EE!» — «So... You should use Java EE — not Jakarta EE!...» — вот где-то так...

Статья на 4 минут чтения.
Не понимаю, зачем бить её на части — хотелось бы видеть все причины в одном месте.
PS:linkedin link в профиле битый

Благодарю за комментарий, 4-5 минут отличный формат чтобы удержать внимание до конца поста. В следующих частях будет больше материала, поэтому и время на прочтение будет расти. Ну и первая часть в таком виде для того чтобы понять заинтересованность аудитории.

Так что не сетуйте так рано, обещаю качественное продолжение.

PS:linkedin link в профиле битый

Я знаю, но не по моей вине, уже написал в поддержку.

Вычислительная мощность стоит дороже памяти. Что мешало создать отдельный тип String только там, где он нужен? Вы бы ради интереса, взяли приложение, и посмотрели ВСЕ стринги, сколько они занимают, и откуда берутся. И соответственно, во что выльется анализ и преобразование вместо тупого копирования этого дерьма потоком, и вместо уничтожения сборщиком мусора, даже без чтения. Львиная доля данных тупо избыточна, и единственная цель их передачи и хранения — упростить жизнь программисту.

То, что должно было стать фичей языка, стало зачем-то фичей JDK, незаметно травящей код. Правильнее — это вообще иметь класс-надстройку над byte array, с преобразованием в нужный тип на лету.

Да, это было бы классной фичей в далёком прошлом, когда Жабу запускали на 10 мегабайтах оперативки. Сейчас же на любую серверную потребность память проще докупить, чем платить производительностью, особенно отравлением кэшей.

Начну с конца. «Было бы классно сделать» — пожалуйста, процесс оформления JEP все давно известен и доступен для всех желающих.

То, что должно было стать фичей языка, стало зачем-то фичей JDK

Я вас тут не очень понимаю. Языка без инструментария не существует, то есть языка Java (по-сути, JLS) не существует без JDK. Так о чем вы говорите?

Обычно сдерживают хреновые девопс процессы. Когда у тебя джава в кубере, то проблем вообще никаких нет.

Тут, кстати да, но есть большой вопрос. Чаще всего сдерживающим фактором являются библиотеки, которые все еще саппортят jdk 6 и для их мейнейнеров вообще не в приоритете какое либо обновление. Так вот мой вопрос к вам — были ли какие-то факторы, которые тормозили или блокировали возможность обновления на новый JDK?

сдерживает от обновления на самую актуальную версию JDK

Мы в прошлом году на 11 переехали, терь только на 17 в следующем году. От шагания в ногу с новым релиз трейном сдерживает КПД такого переезда: это ж не просто сдкмэном новую jdk поставить, а тратить ресурсы девов и девопсов каждые полгода на апгрейд ради пары новых в лучшем случае языковых фич сомнительно. И это еще опуская вопрос поддержки вендорами новых версий

Дело не в том, чтобы гнаться за постоянно-новыми релизами, брать EA билды и работать с ними, но при этом, когда явно говорят, что есть прирост в производительности, то первым делом должны быть инвестированы ресурсы в R&D чтобы понять на сколько «все хорошо» или «все плохо».

Цель цикла статей больше в том, чтобы показать, что переход как таковой необходим и на то есть множество причин. Маленький спойлер — я начал с самых простых, дальше больше!

Підписатись на коментарі