Версии Java и что нам с ними делать

В настоящее время Oracle перевела выпуск Java на шестимесячный цикл. В результате каждые шесть месяцев мы имеем новую версию Java, а в каждый данный момент времени — сразу несколько «живых» версий, в которых можно запутаться. Изложу свои мысли на эту тему.

От 8 до 15

Все версии Java сейчас делятся на долгоживущие Long Term Support (LTS) и промежуточные.

Титул LTS в настоящее время носят две версии Java: Java 8 и Java 11. По ним проводятся сертификационные экзамены и пишутся базовые книги. Их рекомендуется использовать в PROD, для них выпускаются критические патчи и портируются критические фичи из промежуточных версий.

Промежуточные версии — Java 9, Java 10, Java 12, Java 13 и грядущая в марте 2020 года Java 14 (и грядущая в сентябре 2020 года Java 15) содержат незначительные улучшения (впрочем, да, Java 9 получила очень важное улучшение — модульную систему бибилиотек), некритические патчи и обновления, а также некоторые экспериментальные функции, которые можно включить и поиграться, но пока не рекомедуется использовать на PROD. По этим версиям выпускаются тоненькие книжки, которые дают общий обзор новинок.

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

Java имеет замечательное свойство — обратную совместимость. Это позволяет осуществлять миграцию с версии на версию постепенно и неспеша. На PROD вы можете иметь JVM от Java 11, исходный код проекта — по-прежнему написаный в стиле Java 7 и скомпиллированый компилятором из JDK 8.

Проблемы миграции

Хочу отметить, что сам лично столкнулся с проблемой миграции с Java 8 на Java 13 на своем личном проекте: в Java 13 нет больше библиотек JAXB. Начиная с Java 9 модуль java.xml.bind обозначен как deprecated, а начиная с Java 11 — он выпилен вообще. А JAXB нужно для работы Apache Camel. Пришлось помучаться с зависимостями и даже совет, который дает Клаус Ибсен не работает полностью. Правильное решение с зависимостями выглядит так:

<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>

<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>2.3.0.1</version>
</dependency>

<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.2</version>
</dependency>

<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.11.0</version>
</dependency>

Итоги

Значит по итогам 2019 года:

  • все ваши проекты на PROD уже должны были работать как минимум на Java JVM 8.
  • исходный код ваших проектов должен быть скомипилирован компилятором из JDK 8.
  • вполне допустимо в исходном коде не использовать новинки Java 8 (например, streams, lambdas и default-интерфейсы), но практика показывает, что новинки языка Java 8 позволяют писать более удобный, читаемый и компактный код. Осваивайте Java 8 как можно скорее.
  • готовьтесь к переходу на Java 11: например, пробуйте запустить ваш проект на DEV на Java 11 и посмотрите, вылазят ли какие-то косяки и ошибки. Если да, вносите изменения в код, подготавливая его к будущей безболезненной миграции.

 

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s