Как поменять jdk в проекте

Смена JDK в уже существующем Java-проекте затрагивает не только установленную на компьютере версию Java, но и конфигурацию сборки, IDE и самого проекта. Даже если в системе установлен JDK 21, проект может продолжать компилироваться под JDK 8 из-за настроек Maven, Gradle или параметров IDE. Это приводит к ошибкам компиляции, несовместимости библиотек и расхождениям между локальной сборкой и CI.

Перед обновлением JDK важно понимать, какую версию реально использует проект: java.version в Maven, sourceCompatibility и targetCompatibility в Gradle, а также выбранный SDK в настройках среды разработки. Например, проект может запускаться под JDK 17, но компилироваться с флагами Java 11, из-за чего новые языковые конструкции будут недоступны. Эти несоответствия нужно устранить до смены платформы.

Отдельное внимание требуется зависимостям: не все библиотеки готовы работать на новых версиях Java. Переход с JDK 8 на JDK 17 или 21 часто требует обновления Spring, Hibernate, драйверов JDBC и плагинов сборки. Игнорирование этого шага приводит к ошибкам на этапе старта приложения или при выполнении тестов.

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

Определение текущей версии JDK, используемой проектом

Первый источник правды – система сборки. В Maven фактическая версия Java задаётся через свойства maven.compiler.source и maven.compiler.target или через maven.compiler.release в файле pom.xml. Если указан только release, именно он определяет уровень байткода и доступные API, независимо от установленного JDK. Отсутствие этих параметров означает, что используется версия JDK, с которой запущен Maven.

В Gradle следует проверить значения sourceCompatibility и targetCompatibility, а также блок java { toolchain { languageVersion } }. При наличии toolchain проект может компилироваться, например, под Java 11, даже если Gradle запущен на JDK 21. Именно параметр languageVersion определяет, какой JDK будет загружен для компиляции.

В среде разработки выбранная версия JDK может отличаться от сборочной. В IntelliJ IDEA нужно открыть настройки проекта и посмотреть поле Project SDK и Project language level. Если язык установлен ниже версии SDK, часть возможностей Java будет заблокирована. В Eclipse аналогичную роль выполняют Installed JREs и Compiler compliance level.

Дополнительно стоит проверить конфигурации CI и Docker-окружений. В файлах pipeline и Dockerfile часто явно указана версия образа, например openjdk:17 или eclipse-temurin:21. Если локальный проект собран под одну версию, а сервер под другую, проект фактически использует две разные платформы Java, что критично при смене JDK.

Установка нужной версии JDK на рабочую систему

Для проекта следует выбирать не просто номер Java, а конкретную сборку JDK с поддержкой долгосрочных обновлений. На практике чаще используются дистрибутивы Eclipse Temurin, Oracle JDK и Amazon Corretto, так как они содержат полный набор инструментов компиляции и отладки. Если проект нацелен на Java 17 или 21, нужно скачивать именно JDK, а не JRE, иначе сборка Maven или Gradle не сможет работать.

На Windows рекомендуется устанавливать JDK в каталог без пробелов, например C:\Java\jdk-21, чтобы избежать ошибок в скриптах и CI-скриптах. В Linux и macOS предпочтительнее использовать пакетные менеджеры или архивы с распаковкой в /usr/lib/jvm или /Library/Java/JavaVirtualMachines, сохраняя несколько версий параллельно для разных проектов.

После установки необходимо убедиться, что новая версия физически присутствует в системе и доступна для инструментов сборки. Проверяется путь к каталогу JDK и наличие подкаталогов bin, lib и jmods, что подтверждает корректную установку. Отсутствие этих элементов означает, что был установлен не JDK, а урезанный runtime.

Если проект использует Gradle Toolchain или Maven Toolchains, установленный JDK должен соответствовать требуемому номеру версии, иначе сборщик не сможет его выбрать автоматически. В этом случае установка нужного JDK – обязательное условие для переключения проекта на новую платформу Java без ошибок компиляции.

Настройка переменной JAVA_HOME для новой версии JDK

Переменная JAVA_HOME указывает инструментам сборки и IDE, какой каталог JDK использовать по умолчанию. Если она ссылается на старую версию, Maven, Gradle и серверы приложений будут продолжать работать с устаревшей платформой, даже если в системе установлен более новый JDK.

Значение JAVA_HOME должно указывать на корневую папку JDK, а не на подкаталог bin. Например, для JDK 21 это каталог вида jdk-21, внутри которого находятся bin, lib и jmods. Ошибка в одном уровне пути приводит к тому, что команда java может работать, а компилятор и плагины сборки – нет.

После изменения переменной необходимо перезапустить терминалы, IDE и агенты CI, иначе они будут продолжать использовать старое значение, сохранённое в окружении процесса. Проверка должна выполняться из той же среды, где запускается сборка проекта.

Если проект использует несколько JDK через toolchain, JAVA_HOME всё равно должен указывать на валидную версию Java, под которой запускается сам Maven или Gradle. Неверное значение приводит к сбоям загрузки плагинов и невозможности выбрать нужную версию компилятора.

Выбор JDK в настройках IntelliJ IDEA или Eclipse

В IntelliJ IDEA версия JDK для проекта задаётся через Project SDK. Если здесь выбран JDK 8, а в системе установлен JDK 21, компилятор IDE будет использовать старую платформу независимо от настроек Maven или Gradle. Дополнительно необходимо проверить Project language level, так как он может быть зафиксирован на более низком уровне и блокировать новые синтаксические возможности.

Для проектов на Maven и Gradle в IntelliJ важно открыть настройки импорта и указать, какой JDK использовать для самой сборки. В разделе Build Tools выбирается JDK, под которым запускается Maven или Gradle, и он может отличаться от Project SDK. Несовпадение этих значений приводит к ситуациям, когда код в IDE компилируется, а сборка из панели инструментов падает.

В Eclipse выбор версии Java выполняется через список Installed JREs и параметр Execution Environment в настройках проекта. Если проект привязан к, например, JavaSE-11, то даже при установленном JDK 17 компиляция будет происходить с ограничениями Java 11. Для полного перехода нужно изменить оба параметра.

После смены JDK в IDE требуется пересобрать индекс проекта и перезапустить среду разработки. Это гарантирует, что внутренний компилятор, автодополнение и запуск приложений будут работать на новой версии Java, а не на кэшированной конфигурации.

Изменение версии JDK в конфигурации Maven или Gradle

Настройки IDE не имеют приоритета над параметрами сборки, поэтому целевая версия Java должна быть явно зафиксирована в конфигурации Maven или Gradle. Именно эти файлы определяют, какой уровень языка и байткода будет использован при компиляции на локальной машине и в CI.

В Maven контроль версии Java осуществляется через свойства проекта и плагин компилятора. Для корректного перехода на новую платформу необходимо проверить и синхронизировать следующие элементы:

• значение maven.compiler.release, которое задаёт и API, и формат байткода одной цифрой
• пары maven.compiler.source и maven.compiler.target, если используется старая схема настройки
• версию плагина maven-compiler-plugin, так как старые релизы не поддерживают новые JDK

В Gradle версия Java может задаваться несколькими уровнями, и при смене JDK нужно привести их к одному значению:

1. параметры sourceCompatibility и targetCompatibility в конфигурации проекта
2. блок java.toolchain.languageVersion, если используется механизм автоматического выбора JDK
3. версия Gradle Wrapper, так как старые сборки не умеют работать с новыми выпусками Java

Если toolchain активирован, Gradle будет игнорировать JAVA_HOME и запускать компилятор из подходящего JDK, найденного в системе. Поэтому после изменения версии Java в конфигурации сборки необходимо убедиться, что соответствующий JDK установлен локально и доступен для выбора.

После правок в pom.xml или build.gradle требуется выполнить полную пересборку проекта с очисткой, чтобы исключить влияние старых артефактов, собранных под предыдущей версией Java.

Обновление уровня языка и bytecode в настройках сборки

Уровень языка определяет, какие синтаксические конструкции доступны в проекте, а target bytecode – формат скомпилированных классов, который влияет на совместимость с JVM. Несоответствие этих параметров вызывает ошибки компиляции или runtime, даже если установлен правильный JDK.

В Maven для контроля уровня языка используются свойства maven.compiler.source и maven.compiler.target или maven.compiler.release. Например, при переходе на JDK 17 рекомендуется установить release в 17, чтобы одновременно обновить синтаксис и байткод, исключая необходимость отдельной настройки source/target.

В Gradle параметр sourceCompatibility определяет версию языка, а targetCompatibility – формат байткода. При использовании toolchain рекомендуется одновременно задать java.toolchain.languageVersion для привязки компилятора к установленной версии JDK, иначе Gradle может выбрать неверный компилятор.

После изменения этих значений требуется пересборка проекта с очисткой clean build, чтобы старые class-файлы с предыдущим байткодом не влияли на результат. Это особенно важно при использовании модулей, где несовпадение версии bytecode может приводить к IncompatibleClassChangeError или ошибкам загрузки классов.

Если проект использует плагины, генерирующие код (например, Lombok или JAXB), необходимо убедиться, что их конфигурация совместима с новым уровнем языка. В противном случае скомпилированные классы будут содержать некорректный байткод или синтаксис, не поддерживаемый JVM.

Проверка сборки и запуска проекта после смены JDK

После изменения JDK необходимо убедиться, что проект компилируется и запускается без ошибок. В первую очередь следует выполнить полную пересборку с очисткой всех артефактов: mvn clean install для Maven или gradle clean build для Gradle. Это исключает влияние старых class-файлов с предыдущей версии bytecode.

Следующий шаг – проверка совместимости зависимостей. Многие библиотеки, включая Spring, Hibernate и JDBC-драйверы, требуют минимальной версии JDK. Если проект использует устаревшие версии, на этапе запуска появятся ошибки UnsupportedClassVersionError или проблемы с загрузкой модулей.

Необходимо протестировать весь функционал проекта с использованием автоматических тестов. Юнит- и интеграционные тесты позволяют выявить несовместимости нового JDK с существующим кодом, особенно при переходе на Java 17 или 21, где изменились API и строгие правила модульности.

Дополнительно проверяется работа скриптов и сборочных плагинов. Плагины Maven Compiler, Spring Boot или Shadow Gradle должны использовать ту же версию JDK, что и проект. Несовпадение версий компилятора и запуска приводит к ошибкам упаковки и запуску приложения.

Если проект разворачивается в Docker или CI/CD, следует убедиться, что контейнеры и агенты используют обновлённый JDK. Например, образ openjdk:21 или соответствующая версия в pipeline должны совпадать с локальной сборкой, иначе возникнет расхождение поведения между средами.

Вопрос-ответ:

Как узнать, какая версия JDK используется в проекте на Maven?

Для Maven версия JDK определяется настройками плагина компилятора в файле pom.xml. Проверяйте свойства maven.compiler.source и maven.compiler.target или maven.compiler.release. Если указан release, именно эта версия определяет доступные API и формат байткода, а значения source и target игнорируются. Дополнительно можно выполнить команду mvn -v в терминале, чтобы увидеть, какой JDK используется для запуска Maven.

Как правильно установить новую версию JDK на Windows и Linux для проекта?

На Windows рекомендуется установить JDK в каталог без пробелов, например C:\Java\jdk-21, чтобы скрипты сборки корректно распознавали путь. На Linux лучше распаковать архив JDK в /usr/lib/jvm. После установки необходимо проверить наличие папок bin, lib и jmods, так как их отсутствие означает, что установлен не полный JDK. Также нужно обновить переменную JAVA_HOME и перезапустить терминал, чтобы система и сборочные инструменты начали использовать новую версию.

Что делать, если IntelliJ IDEA продолжает использовать старый JDK после смены переменной JAVA_HOME?

IDE хранит отдельные настройки проекта и сборки. Нужно открыть Project Structure и проверить Project SDK и Project language level. Также следует убедиться, что в разделе Build Tools выбран нужный JDK для Maven или Gradle. После внесения изменений рекомендуется пересобрать индекс проекта и перезапустить IDE, чтобы все внутренние компиляторы и автодополнение начали работать с новой версией.

Как обновить уровень языка и bytecode в Gradle при смене JDK?

В Gradle параметры sourceCompatibility и targetCompatibility определяют уровень языка и формат байткода. При использовании toolchain дополнительно нужно задать java.toolchain.languageVersion, чтобы Gradle выбирал компилятор из нужного JDK. После изменения этих параметров выполняется команда gradle clean build, чтобы удалить старые class-файлы и гарантировать совместимость нового bytecode с JVM.

Как проверить, что проект полностью работает после смены JDK?

Необходимо выполнить полную сборку с очисткой артефактов и запуск всех тестов. Юнит- и интеграционные тесты помогут выявить несовместимости новой версии JDK с кодом и библиотеками. Также важно проверить скрипты запуска, плагины сборки и контейнеры Docker/CI, чтобы убедиться, что они используют ту же версию JDK. Ошибки типа UnsupportedClassVersionError или сбои компиляции укажут на несовпадение версий между средами.

Почему проект продолжает компилироваться старым JDK после смены JAVA_HOME?

Переменная JAVA_HOME влияет на инструменты сборки, но IDE и сборочные плагины могут использовать собственные настройки. В IntelliJ IDEA нужно проверить Project SDK и Build Tools SDK, в Eclipse — Installed JREs и Execution Environment. Если они указывают на старую версию, сборка будет использовать её, несмотря на обновлённый JAVA_HOME. После исправления этих настроек требуется пересобрать проект и перезапустить IDE.

Как убедиться, что библиотеки и плагины совместимы с новой версией JDK?

Некоторые библиотеки и плагины не поддерживают новые версии Java. Для проверки следует просмотреть требования к JDK на странице проекта или в документации плагинов. Затем нужно выполнить полную сборку с очисткой артефактов и прогон тестов. Ошибки типа UnsupportedClassVersionError или сбои компиляции сигнализируют о несовместимости. При необходимости версии зависимостей обновляются в pom.xml или build.gradle, чтобы соответствовать новой платформе.