Какую версию Java выбрать: обзор для сервера

На сервере Java почти никогда не нужна сама по себе. Она стоит там потому, что её требует сервер Minecraft, Tomcat, Jenkins или поисковый индекс. Именно поэтому вопрос звучит не «какая Java лучше», а «какую Java ожидает вот это конкретное приложение и получится ли вообще поставить её на вот эту конкретную операционную систему». Статья отвечает на оба вопроса: сроками поддержки, таблицей доступности пакетов, которую мы перемерили в настоящих контейнерах, и практикой параллельной работы нескольких версий.

Коротко: какая версия для какой задачи

Если времени нет, решение выглядит так:

• Новый проект, выбор свободный: Java 21. Это самая широко поддерживаемая на сегодня LTS-линия, она уже готовым пакетом лежит в Debian 13 и во всех актуальных версиях Ubuntu, и практически любое современное серверное ПО на ней работает.
• Minecraft с 1.20.5 по 1.21.11: Java 21. Обязательно, без вариантов.
• Minecraft 26.1 и новее: Java 25.
• Старое приложение, у которого в документации стоит «Java 17»: берите именно Java 17, а не «17 или новее». У модлоадеров и систем плагинов «новее» часто не соответствует действительности.
• Java 8 или 11: только если этого требует унаследованное приложение. И то и другое стоит внести в список того, что надо заменить.
• Java 25: самая свежая LTS-линия, разумный выбор для новых развёртываний, но сначала проверьте, объявил ли ваш фреймворк официальную поддержку.

Для собственно установки у нас есть отдельные руководства: установка Java 17 на Debian и установка Java 21 на Debian. Эта статья — карта над ними.

Что означает LTS и как долго поддерживаются версии

Новая мажорная версия Java выходит каждые полгода. Подавляющее большинство из них мертвы ровно через эти полгода: Java 22, 23, 24 и 26 перестают получать обновления безопасности, как только появляется следующая версия. На сервере такие версии не нужны.

Интерес представляют исключительно LTS-версии (Long Term Support). С 2021 года они выходят раз в два года: 8, 11, 17, 21, 25, а следующей запланирована Java 29 на сентябрь 2027 года. Только эти линии годами получают ежеквартальные обновления безопасности.

Важно различать сборки Oracle и свободные сборки. Для серверной эксплуатации, как правило, берут OpenJDK из пакета дистрибутива или Eclipse Temurin. И то и другое можно использовать бесплатно, а поддержка там местами длится заметно дольше, чем у бесплатной лицензии Oracle.

Строка про Java 17 многих удивляет: всего лишь до октября 2027 года. Java 17 ощущается новой, но это уже предпоследнее поколение LTS. Если система ставится сегодня и должна проработать три года, лучше сразу планировать 21 или 25.

Какая версия Java есть в репозитории вашего дистрибутива

Именно здесь ломается большинство руководств в сети: там пишут «apt install openjdk-17-jre-headless» и исходят из того, что это сработает везде. Не сработает. Мы перемерили состояние пакетов 27.07.2026 в свежих контейнерах.

Столбцы Debian стоит прочитать дважды. Debian 12 знает только Java 17. Debian 13 больше не знает Java 17, зато знает 21 и 25. То есть в официальных источниках Debian нет ни одной версии, которая присутствовала бы в обоих выпусках. Тот, кто пишет скрипт развёртывания сразу под bookworm и trixie, не может опереться на один пакет.

Ubuntu в этом отношении приятнее: там все пять LTS-линий лежат в репозитории рядом, и на 22.04, и на 24.04. Если нужна система, где одновременно работают старое приложение на Java 8 и современный сервис на Java 21, Ubuntu будет коротким путём.

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

apt update
apt-cache policy openjdk-21-jre-headless
apt-cache search openjdk-

Если в строке «Кандидат» (в англоязычной локали «Candidate») стоит (none), значит, в этом дистрибутиве такого пакета нет. В семействе Red Hat (AlmaLinux, Rocky, RHEL, Oracle Linux) пакеты называются иначе, там список выводится так:

dnf list java-\*-openjdk-headless
dnf install -y java-21-openjdk-headless

Для обзора берите dnf list, а не dnf list available. Второй вариант скрывает уже установленные пакеты, поэтому после установки Java 21 она из списка пропадает, и человек начинает искать не там. Ситуация в семействе Red Hat, тоже перемеренная в свежих контейнерах:

То есть AlmaLinux 10 провёл ту же черту, что и Debian 13, и отбросил всё ниже 21. Команда dnf install java-17-openjdk-headless заканчивается там сообщением No match for argument.

headless или нет, JRE или JDK

На сервере всегда берите вариант -headless. Он обходится без графических библиотек и потому не тянет за собой зависимости X11, что на root-сервере экономит десятки лишних пакетов. А -jre-headless достаточно, пока вы только запускаете готовые JAR-файлы. Пакет openjdk-21-jdk-headless понадобится лишь тогда, когда вы компилируете сами или какой-то инструмент вызывает javac.

В семействе Red Hat в этом месте стоит второй раз посмотреть на зависимости. Пакет java-21-openjdk-devel тянет на AlmaLinux 9 удивительно длинную цепочку графических пакетов, среди них webkit2gtk3-jsc, xorg-x11-fonts, xdg-desktop-portal и wireplumber. На сервере без графической оболочки это не нужно. Поэтому заранее проверьте через dnf install --assumeno, что придёт вместе с пакетом, и оставайтесь на java-21-openjdk-headless, пока компилировать ничего не требуется.

Minecraft: версия игры и версия Java

Minecraft — самая частая причина, по которой Java вообще попадает на сервер, и одновременно область с самыми жёсткими требованиями. Соответствие однозначное:

Два замечания к этому, которых нет в большинстве таблиц. Первое: начиная с 26.1 Minecraft ушёл от старой схемы 1.x и перешёл на годовую нумерацию, то есть 26.1 — это первый выпуск 2026 года. Версия 1.21.11 была последней, которой хватает Java 21.

Второе: «или новее» действует для ванильного сервера. Как только в дело вступают модлоадеры, правило перестаёт работать надёжно. Сервер Forge для 1.20.1 собран под Java 17, и перевод его на Java 21 — одна из самых частых причин падения прямо при запуске, хотя число ведь «больше». Для серверов с модами берите ровно ту версию, которую называет автор модпака.

Практическая часть описана в наших руководствах установка сервера Minecraft на Debian и автозапуск сервера Minecraft.

Другие серверные приложения и их требования

За пределами Minecraft действуют примерно такие правила:

• Apache Tomcat: ветка 9.0.x работает начиная с Java 8, 10.1.x требует минимум Java 11, 11.0.x требует минимум Java 17. Все три поддерживаемые сейчас ветки нормально работают на Java 17.
• Elasticsearch и OpenSearch: приносят с собой собственную JVM. Не устанавливайте для них системную Java и не задавайте глобальную переменную JAVA_HOME, которая перекроет поставляемую JVM. Это классический источник ошибок после «уборки» в установленных Java.
• Jenkins: актуальные версии требуют минимум Java 17 и работают на Java 21.
• Keycloak, Kafka, Solr, Nexus: ориентируются на предпоследний LTS. Проверяйте release notes конкретной версии, эти проекты регулярно поднимают нижнюю границу.

Не всякое серверное ПО, которое принято связывать с Java, действительно её требует. Например, сервер TeamSpeak 3 представляет собой нативный бинарный файл и обходится без JVM.

Параллельная работа нескольких версий Java и переключение между ними

На Debian и Ubuntu можно установить сколько угодно пакетов OpenJDK одновременно. Каждый попадает в собственный каталог внутри /usr/lib/jvm/, и друг другу они не мешают:

apt install -y openjdk-21-jre-headless openjdk-25-jre-headless
ls /usr/lib/jvm/

Общий у них ровно один файл: /usr/bin/java. Это символьная ссылка, которой управляет система альтернатив. Посмотреть кандидатов можно так:

update-alternatives --list java
update-alternatives --display java

Такая запись с именем после --list характерна именно для Debian, в семействе Red Hat она выглядит иначе, об этом ниже. Из двух команд важнее вывод --display. Он показывает не только пути, но и режим (auto или manual) и приоритет каждой записи. Переключаться можно интерактивно через update-alternatives --config java с выбором номера, а в скриптах лучше жёстко:

update-alternatives --set java /usr/lib/jvm/java-21-openjdk-amd64/bin/java
java -version

Никогда не переписывайте этот путь из чужого руководства, берите его из вывода update-alternatives --list java. Показанный выше путь относится к OpenJDK из пакета дистрибутива. У того, кто пойдёт по разделу про Temurin ниже, такого каталога вообще нет, там он называется /usr/lib/jvm/temurin-21-jre-amd64/bin/java, и команда прервётся с сообщением alternative path ... doesn't exist.

Если вы ещё и компилируете, то javac надо переключать отдельно. Об этом охотно забывают, и получается абсурдная ситуация: компиляция идёт на Java 25, а запуск на Java 21:

update-alternatives --set javac /usr/lib/jvm/java-21-openjdk-amd64/bin/javac
javac -version

Ловушка, которая обойдётся вам бессонной ночью

Пока java находится в режиме auto, всегда побеждает наивысший приоритет, а наивысший приоритет у самой новой установленной версии. То есть если через несколько месяцев вы доставите openjdk-25, потому что он понадобился другому сервису, ссылка /usr/bin/java при ближайшей операции с пакетами молча переключится на 25. Ваш сервер Minecraft, работавший до этого на 21, после следующей перезагрузки стартует на JVM, которую вы никогда не выбирали.

Команда update-alternatives --set переводит запись в режим manual и тем самым замораживает её. В этом и состоит её настоящее назначение. Вернуться в автоматический режим можно так:

update-alternatives --auto java

Более надёжный путь для сервисов всё равно другой: вообще не полагаться на /usr/bin/java. Пропишите в своём systemd-юните полный путь, тогда выбор версии закреплён за конкретным сервисом и не зависит ни от каких переключений альтернатив:

ExecStart=/usr/lib/jvm/java-21-openjdk-amd64/bin/java -Xms2G -Xmx4G -jar server.jar nogui

Как такой юнит выглядит целиком, описано в статье создание systemd-сервиса. Кстати, именно этот абсолютный путь и есть причина того, что после смены Java сервис иногда не переезжает вместе с ней: update-alternatives его попросту не трогает.

На AlmaLinux, Rocky Linux, RHEL и Oracle Linux инструмент называется alternatives, а update-alternatives там всего лишь символьная ссылка на него. Но работает он не так же: этот --list не принимает аргумент. Скопированная команда update-alternatives --list java выведет там только справку и завершится с кодом возврата 2. Правильной будет одна из этих двух строк:

alternatives --list | grep java
alternatives --display java

Вывод --display тоже отличается: вместо java - auto mode там стоит java - status is auto. Кроме того, в семействе Red Hat пути содержат полный номер версии, например /usr/lib/jvm/java-21-openjdk-21.0.11.0.10-1.el9.x86_64, а не короткую форму Debian java-21-openjdk-amd64. Только AlmaLinux 10 дополнительно создаёт короткую символьную ссылку java-21-openjdk.

И автоматика ведёт себя там не так, как ожидаешь: после установки Java 17 рядом с уже имевшейся Java 21 команда alternatives на AlmaLinux 9 самостоятельно перевела ссылку /usr/bin/java на 17, то есть на более старую версию. Поэтому после каждой доустановки явно задавайте alternatives --set java <путь> и проверяйте результат командой java -version.

Когда нужной версии в дистрибутиве нет: Temurin

Для пробелов в таблице выше есть аккуратный ответ: Eclipse Temurin от Adoptium поставляет пакеты от temurin-8 до temurin-26 для trixie, bookworm, noble и jammy. Так вы получите Java 21 и на Debian 12, и Java 17 на Debian 13, без сторонних PPA и без вручную скопированных архивов в /opt.

Учтите при этом, что apt-key объявлен устаревшим. Ключ должен лежать в /etc/apt/keyrings/ и подключаться через signed-by:

apt install -y wget gnupg ca-certificates apt-transport-https
install -d -m 0755 /etc/apt/keyrings
wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | tee /etc/apt/keyrings/adoptium.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/adoptium.gpg] https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list
apt update
apt install -y temurin-21-jre

Пакеты Temurin тоже регистрируются в системе альтернатив, то есть появляются в выводе update-alternatives --display java и спокойно уживаются с пакетами OpenJDK из дистрибутива. Их каталоги лежат в /usr/lib/jvm/temurin-21-jre-amd64 или под похожим именем.

Сообщения об ошибках дословно и что они означают

E: Unable to locate package openjdk-17-jre-headless
Такой версии в этом дистрибутиве нет. На Debian 13 это обычная ситуация для Java 8, 11 и 17. Дело не в опечатке и не в забытом apt update: берите Temurin или другую версию.

java.lang.UnsupportedClassVersionError: ... has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
Классика жанра. Приложение собрано под более новую JVM, чем та, которую вы запустили. Числа расшифровываются так:

То есть 65.0 против 61.0 означает прямым текстом: программе нужна Java 21, а у вас работает Java 17. На серверах Minecraft начиная с 1.20.5 эту ошибку часто видно в обёртке Error: LinkageError occurred while loading main class net.minecraft.bundler.Main, настоящая причина стоит тогда строкой ниже.

java: command not found
JVM не установлена, либо вы просто распаковали каталог JDK в /opt, не зарегистрировав его. Проверьте ls /usr/lib/jvm/. Если каталоги там есть, а /usr/bin/java нет, зарегистрируйте запись вручную:

update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-amd64/bin/java 2111

update-alternatives: error: no alternatives for java
Система альтернатив не знает ни одного кандидата. Встречается, когда Java устанавливали вручную. Исправляется так же, как выше.

update-alternatives: error: alternative path /usr/lib/jvm/... doesn't exist
Вы задали путь, которого к этому моменту уже нет, обычно после удаления пакета. Учтите, что пути в Debian содержат архитектуру: java-21-openjdk-amd64, а не java-21-openjdk.

Сервис работает, но на неправильной версии.
Скорее всего, в systemd-юните прописан абсолютный путь либо юнит задаёт собственную переменную JAVA_HOME. И то и другое перебивает update-alternatives без какого-либо предупреждения.

Сервер запускается, но через несколько секунд умирает без внятного сообщения.
У приложений на Java это часто не проблема версии, а нехватка памяти: ядро завершает процесс, если -Xmx задан больше, чем объём свободного RAM. К этой теме относятся наши статьи настройка swap против Out of Memory и очистка диска, когда в Linux закончилось место.

Как убедиться, что действительно работает нужная версия

Первая проверка тривиальна, но делайте её всё равно после каждого переключения:

java -version

В выводе должна стоять ожидаемая мажорная версия, например openjdk version "21.0.11". Вторая проверка информативнее, потому что показывает реально разрешённый путь, а значит и то, что вам сейчас досталось: Temurin или OpenJDK из дистрибутива:

readlink -f "$(command -v java)"

Здесь сознательно используется command -v, а не which. which — внешняя программа, и в минимальной установке AlmaLinux 9 и 10, Rocky Linux 9 и Oracle Linux 9 её попросту нет. Вариант с which заканчивается там сообщением which: command not found, за которым следует readlink: missing operand. command -v — встроенная команда оболочки, она работает во всех перечисленных дистрибутивах.

А если хочется узнать, что сама JVM думает о своём доме, потому что приложение читает JAVA_HOME:

java -XshowSettings:properties -version

В выводе интересны java.home и java.version. Если java.home расходится с вашими ожиданиями, значит где-то задана переменная JAVA_HOME, и побеждает она.

Для работающего сервиса в конечном счёте важно только то, что использует сам процесс. Это читается прямо из списка процессов, там стоит полный путь к JVM, с которой он был запущен:

ps -eo pid,args | grep '[j]ava'

Если вы видите там /usr/lib/jvm/java-21-openjdk-amd64/bin/java, вопрос закрыт. Если видите голое java, ваш сервис висит на символьной ссылке системы альтернатив и меняется вместе с ней. Для продуктивного сервиса это худший из двух вариантов.

Если сервер вы всё равно настраиваете с нуля, стоит заранее заглянуть в наш чек-лист для нового root-сервера: Java стоит в конце этого списка, а не в начале, ведь искать причину проблем с JVM приятно только тогда, когда уже работают доступ по SSH, файрвол и часовой пояс.

Итог

Java 21 сегодня — ответ по умолчанию, Java 25 — ответ на перспективу, Java 17 — уходящая натура, а Java 8 и 11 — это долг по миграции. Решает, впрочем, не одно только число, а сочетание приложения и дистрибутива: Debian 12 даёт вам только 17, Debian 13 только 21 и 25, Ubuntu даёт всё. Там, где пакета нет, пробел закрывает Temurin. И как только на машине лежит больше одной версии, действует правило: update-alternatives --set вместо автоматики, а в systemd-юнитах лучше сразу абсолютный путь.