Все, что Вы должны знать о переходе на Java 11 (часть 2)

С установленным JDK вашего любимого поставщика (и, возможно, с LTS в заднем кармане) вы хотите чтобы ваш проект на Java 8 заработал на Java 11. Мы знаем, что вы готовы к апгрейду, но прежде, чем мы пойдем дальше, необходимо обсудить, как подготовиться к переходу наилучшим образом.

Быстрый или длительный переход?

Перед началом перехода с Java 8 на Java 11 или на более позднюю версию, первый вопрос, на который необходимо ответить — можете ли вы реализовать переход одним махом или вам необходимо провести его в течение длительного промежутка времени.

Если миграция обещает быть быстрой или к проекту могут быть предъявлены новые требования по использованию версии Java, используйте новую версию Java сразу для всего процесса сборки, включая компиляцию. Осталось только исправить проблемы, которые при этом могут возникнуть.

Если же вы не хотите изменять требования к минимальной версии Java или ваш проект слишком большой, мы рекомендуем следующий подход:

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

Таким образом, вы можете гарантировать, что ваш проект работает и на Java 8 и на Java 11 (или более поздней версии). Если вы захотите работать с двумя (или более) версиями Java, то сможете быстро переключать профайлы и работать с ними. А когда вы совсем перестанете использовать Java 8, то не забудьте объединить версии конфигурации, чтобы уменьшить сложность проекта.

⇝ Planning Your Java 9 Update (fully applies to Java 11)
⇝ Maven on Java 9 – Six Things You Need To Know (fully applies to Java 11)

Делаем общий апгрейд

Первое правило перехода на Java 11 — обновить все: вашу IDE, систему сборки, ее плагины и, самое главное, ваши зависимости. Вам не обязательно делать все эти обновления заранее, но если вы это можете, то вы должны так сделать — это, скорее всего, поможет вам преодолеть некоторые препятствия, относительно которых вы останетесь в блаженном неведении.

Ниже приведены необходимые минимальные версии для некоторых приложений:

IntelliJ IDEA: 2018.2
Eclipse: Photon 4.9RC2 with Java 11 plugin
Maven: 3.5.0
- compiler plugin: 3.8.0
- surefire and failsafe: 2.22.0
Gradle: blocked by #5120

Некоторые зависимости, которые вы должны отслеживать (а также версии, которые, как известно, работают на Java 11):

Все, что использует для работы байт-код, например ASM (7.0), Byte Buddy (1.9.0), cglib (3.2.8) или Javassist (3.23.1-GA). Начиная с Java 9, модификации байт-кода происходят каждые шесть месяцев, поэтому вам придется регулярно обновлять такие библиотеки.
Все, что использует то, что работает с байт-кодом, например Spring (5.1), Hibernate (неизвестно), Mockito (2.20.0) и многие, многие другие проекты.

Второй совет слишком общий и не очень-то помогает, но это печальная правда: многие мощные проекты работают с байт-кодом под капотом. Это помогает развить подход к выявлению проблем, связанных с этим.

Вот некоторые советы — обращайте внимание в логах на:

трассировки стеков, которые заканчиваются вызовом библиотек, использующих байт-коды;
ошибки или предупреждения, которые жалуются на уровень байт-кода;
ошибки или предупреждения, которые бормочут о «unknown (constant pool) entries»;

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

Например, для более старой версией Hibernate необходимо было обновить Javassist для работы с Java 11:

<dependency>
	<groupId>org.hibernate</groupId>
	<artifactId>hibernate-core</artifactId>
	<!-- LOOK OUT: YOU SHOULD USE A NEWER VERSION! -->
	<version>5.2.12.Final</version>
</dependency>
<dependency>
	<!-- update Hibernate dependency on Javassist
			from 3.20.0 to 3.23.1 for Java 11 compatibility -->
	<groupId>org.javassist</groupId>
	<artifactId>javassist</artifactId>
	<version>3.23.1-GA</version>
</dependency>

Аналогично, при использовании устаревшей версии Maven-плагина 3.7.0 для компиляции, необходимо было обновление его зависимости от ASM:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-compiler-plugin</artifactId>
	<!-- LOOK OUT: YOU SHOULD USE 3.8.0! -->
	<version>3.7.0</version>
	<configuration>
		<release>${java.version}</release>
	</configuration>
	<dependencies>
		<dependency>
			<!-- update compiler plugin dependency on ASM
					for Java 11 compatibility -->
			<groupId>org.ow2.asm</groupId>
			<artifactId>asm</artifactId>
			<version>6.2</version>
		</dependency>
	</dependencies>
</plugin>

К сожалению, не у всех, используемых в вашем проекте библиотек, поддержка может находиться в хорошем состоянии и даже, возможно, что она прекращена. В этом случае вам нужно искать альтернативы. Примерами могут являтся FindBugs (вместо этого используйте SpotBugs), Log4j 1 (используйте Log4J 2) и Cobertura (используйте JaCoCo).

Однако, если проблема кроется в вашем собственном коде или такие обновления / замены не помогают или невозможны, тогда имеет смысл заняться углубленным ее изучением.