Eclipse Temurin, Amazon Corretto или Liberica JDK для VDS

Выбор OpenJDK для VDS редко сводится к сравнению скорости виртуальных машин. Eclipse Temurin, Amazon Corretto и BellSoft Liberica JDK основаны на OpenJDK, проходят проверку совместимости с Java SE и используют HotSpot. Поэтому при одинаковых версии Java, архитектуре и настройках приложения их базовые возможности близки.

На практике важнее другие вопросы: как долго поставщик выпускает исправления, насколько удобно обновлять JDK на Debian- или RHEL-based системе, есть ли подходящие ARM64-сборки и контейнерные образы, можно ли получить поддержку по SLA и не исчезнут ли диагностические инструменты из облегчённого runtime.

Для новых долгоживущих сервисов обычно рассматривают актуальную на момент внедрения LTS-ветку Java. Java 25 относится к LTS-релизам, а Java 21 остаётся распространённым вариантом для зрелых систем. Перед выбором необходимо сверить текущий статус ветки, даты обновлений и условия сопровождения непосредственно у выбранного поставщика JDK.

Краткий вывод

• Eclipse Temurin — универсальный нейтральный выбор для большинства VDS, особенно если нужны бесплатные сборки, DEB/RPM-пакеты и официальные контейнерные образы.
• Amazon Corretto — логичный вариант для инфраструктуры, уже связанной с AWS, Amazon Linux, публичным Amazon ECR или корпоративным AWS Support.
• BellSoft Liberica JDK — сильный кандидат, если нужны прямая коммерческая поддержка производителя, расширенный выбор комплектаций JDK, длительный контрактный жизненный цикл или контейнерная экосистема BellSoft.

Если у команды нет специальных требований, Temurin на актуальной поддерживаемой LTS-ветке — разумная отправная точка. Для консервативной эксплуатации уже работающего приложения можно оставить Java 21, если её возможностей и срока поддержки достаточно. Corretto и Liberica стоит выбирать не ради абстрактного прироста производительности, а ради конкретных преимуществ каналов доставки и поддержки.

Для запуска Java-приложения административный доступ не обязателен: JDK можно разместить в домашнем каталоге пользователя и запускать приложение без системной установки. Однако root- или sudo-доступ потребуется для рассматриваемого варианта эксплуатации на VDS: подключения системных репозиториев, установки DEB/RPM-пакетов, управления systemd-службами и настройки общесистемных каталогов. Подходящий VPS-сервер с административным доступом позволяет параллельно установить несколько JDK, закрепить версию за службой и проверить обновление до переключения production-нагрузки.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Что именно сравнивается

Все три продукта — дистрибутивы OpenJDK, а не отдельные реализации языка Java. Приложение, корректно работающее на стандартном HotSpot без зависимости от внутренних API, обычно переносится между ними без перекомпиляции. Однако это не отменяет тестирования: поставщики могут применять разные наборы исправлений, собирать пакеты с отличающимися компонентами и публиковать обновления в разное время.

Как выбирать версию Java

Актуальная LTS для новых развёртываний

Для нового сервиса обычно подходит актуальная LTS-ветка, поскольку у неё больше оставшийся срок сопровождения и меньше вероятность скорой плановой миграции. Java 25 может быть подходящим выбором, если приложение, библиотеки и средства наблюдаемости уже входят в её матрицу совместимости.

Переходить на новую LTS только по номеру версии не следует. Нужно проверить библиотеки, агенты мониторинга, JNI-зависимости, драйверы и параметры запуска JVM. Особое внимание уделяют устаревшим флагам: параметр, принятый в Java 17 или Java 21, в более новой версии может выводить предупреждение либо препятствовать запуску.

Java 21 как консервативный вариант

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

Для нового проекта Java 21 имеет смысл выбирать, когда более новая версия пока не входит в матрицу совместимости критичной библиотеки, коммерческого агента или внутренней платформы компании. Такое решение лучше сопровождать датой пересмотра, иначе временная мера легко превращается в многолетнее отставание.

Java 17, 11 и 8 — при явных ограничениях

Старые LTS-ветки могут продолжать получать обновления у отдельных поставщиков, но это не делает их равноценными новым LTS для нового сервиса. Их оправданно использовать для существующих приложений, которые нельзя быстро обновить из-за несовместимых зависимостей, требований сертификации или высокой стоимости миграции.

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

Поддержка LTS и выпуск обновлений

Eclipse Temurin

Adoptium ориентируется на график OpenJDK и публикует обновления поддерживаемых веток. Проект заявляет поддержку LTS-релизов в рамках собственной политики выпуска и доступности сборок. Для Java-команды это прозрачная модель, но она не равна договорному обязательству с индивидуальным SLA.

Temurin хорошо подходит организациям, которые самостоятельно отвечают за эксплуатацию JVM и могут обращаться в сообщество или отдельно заключить договор с компанией-партнёром. Сам проект Eclipse Adoptium не выступает службой поддержки конкретного приложения и не гарантирует время реакции на инцидент.

Amazon Corretto

AWS публикует для Corretto плановые обновления и может выпускать внеплановые исправления, в том числе для срочных проблем безопасности. При выборе следует проверить официальную страницу жизненного цикла именно для нужной версии Java: сроки поддержки разных веток не совпадают.

Преимущество Corretto заметнее в AWS: если у компании уже есть подходящий AWS Support Plan, обращения по Corretto могут обслуживаться через существующий канал. Для VDS у другого провайдера нельзя автоматически считать, что тот же объём помощи распространяется на любое окружение. До внедрения необходимо проверить условия конкретного плана, допустимые платформы и границы ответственности AWS.

BellSoft Liberica JDK

BellSoft сочетает бесплатные сборки с прямой коммерческой поддержкой. Для LTS-версий компания предлагает планы сопровождения с определяемым договором сроком доступа к исправлениям. Конкретные поддерживаемые версии, даты и уровень сервиса необходимо сверять с действующей дорожной картой и условиями выбранного контракта.

Коммерческие планы могут включать SLA и внеплановые исправления. При выборе не стоит делать вывод о будущей периодичности обновлений только по отдельным релизам или заявлениям поставщика: важнее фактическая история выпусков, условия договора и процесс получения критических патчей.

x86_64 и ARM64 на VDS

Все три дистрибутива доступны для Linux x86_64 и ARM64, поэтому сам факт поддержки архитектуры не определяет победителя. Проверять нужно не только архив JDK, но и всю цепочку поставки:

• наличие DEB или RPM для нужной версии Java и архитектуры;
• поддержку ARM64 конкретным тегом контейнерного образа;
• совместимость JNI-библиотек и нативных агентов;
• наличие ARM64-версий профилировщиков и средств мониторинга;
• одинаковый состав доверенных сертификатов и системных библиотек в образах;
• возможность воспроизводимо собирать multi-arch контейнеры в CI/CD.

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

На ARM64-VDS сравнивать производительность нужно на реальном типе виртуального процессора. Результат с локального x86_64-сервера или ноутбука Apple Silicon ничего не говорит о поведении приложения на конкретной виртуальной платформе. Также следует сверить лимиты CPU и памяти, размеры страниц памяти и доступные наборы инструкций.

Установка на Debian- и RHEL-based VDS

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

Debian-based системы

Temurin, Corretto и Liberica предлагают DEB-пакеты и каналы установки через APT. Перед подключением стороннего репозитория нужно проверить, поддерживает ли он конкретный выпуск Debian или Ubuntu, и сохранить ключ в отдельном keyring. Устаревший механизм apt-key не следует использовать в новой конфигурации только потому, что он встречается в старых инструкциях.

Если на VDS установлено несколько JDK, команда java может указывать не на тот дистрибутив, который использует systemd-служба. Проверять нужно и системную альтернативу, и фактический путь процесса:

uname -m
java -version
readlink -f "$(command -v java)"
java -XshowSettings:properties -version 2>&1 | grep -E 'java.home|os.arch'

Для production-службы надёжнее зафиксировать JAVA_HOME или полный путь к java в unit-файле либо отдельном environment-файле, чем полагаться на глобальную альтернативу. Тогда установка другого JDK для тестирования не переключит рабочее приложение неожиданно.

RHEL-based системы

На RHEL, Rocky Linux, AlmaLinux и совместимых системах доступны RPM-пакеты. Corretto предоставляет собственный YUM-репозиторий, Temurin и Liberica также распространяют RPM-сборки и репозитории. Но совместимость RPM-формата не гарантирует официальную поддержку любого выпуска дистрибутива: матрицу платформ нужно проверять отдельно.

При параллельной установке нескольких версий следует учитывать механизм alternatives. Как и на Debian-based VDS, systemd-службу лучше привязать к конкретному пути. Перед удалением старой JDK необходимо убедиться, что ни одна служба, задача cron или сборочный агент её не использует.

Контейнерные образы

Temurin: нейтральные и разнообразные базовые системы

Temurin публикуется как официальный образ Docker. Доступны варианты на базе Ubuntu, Alpine и Red Hat UBI, а также полные JDK- и runtime-образы для поддерживаемых версий. Это удобно, когда организации требуются и Debian-подобные, и RHEL-совместимые контейнеры без смены поставщика Java.

Ubuntu-вариант обычно проще для универсального применения. Alpine уменьшает базовый слой, но использует musl вместо glibc, что может повлиять на нативные библиотеки и инструменты. UBI удобен для компаний, стандартизировавших контейнерную среду на продуктах Red Hat.

Corretto: интеграция с AWS

Официальные образы Corretto доступны через публичный Amazon ECR и Docker Hub. Это удобно для сборочных процессов в AWS и сред, где уже применяются Amazon Linux и инфраструктурные средства Amazon. Alpine-варианты необходимо тестировать с теми же оговорками относительно musl и нативных компонентов.

Размещение образа в ECR само по себе не делает его быстрее на VDS. Преимущество состоит в согласованности источника, инфраструктуры доставки и поддержки, а не в особом режиме работы JVM.

Liberica: комплектации и runtime-контейнер

У Liberica есть несколько вариантов поставки. Standard ориентирован на обычное серверное применение, Full включает дополнительные компоненты, а Lite уменьшает состав runtime. BellSoft также развивает Liberica Runtime Container и собственную контейнерную экосистему.

Для типичного headless-сервиса Full обычно не нужен. Lite или минимальный runtime может сократить образ, но перед выбором необходимо проверить наличие модулей, кодировок, сертификатов и диагностических утилит. Экономия нескольких десятков мегабайт не оправдывает ситуацию, когда во время инцидента в контейнере нет jcmd или возможности снять JFR.

Что важнее названия образа

При сравнении контейнеров нужно фиксировать не только поставщика JDK, но и базовую ОС. Сравнение Temurin на Ubuntu с Corretto на Alpine одновременно измеряет различия JDK, libc, системных пакетов и размера образа. Корректный тест использует максимально близкие базовые условия.

Production-образ следует закреплять по конкретному patch-тегу, а при строгих требованиях — по digest. Плавающий тег вроде 25 удобен для знакомства, но способен незаметно изменить JDK и базовый слой при следующей сборке. Безопасная схема включает регулярное обновление digest, сканирование образа, smoke-тесты и контролируемое развёртывание.

Диагностика и эксплуатационные инструменты

В полной JDK всех трёх поставщиков доступны стандартные средства OpenJDK: jcmd, jstack, jmap, jstat, heap dump и Java Flight Recorder. Поэтому в большинстве инцидентов решающим фактором будет не бренд JDK, а состав установленного пакета и права пользователя.

Базовую проверку можно выполнить так:

java -version
jcmd -l
jcmd PID VM.version
jcmd PID VM.flags
jcmd PID GC.heap_info

Вместо PID указывают идентификатор процесса JVM. Команды следует запускать от того же системного пользователя, которому принадлежит Java-процесс, либо с корректно настроенными правами. Не стоит включать удалённые диагностические интерфейсы без аутентификации и сетевых ограничений.

Для записи JFR можно использовать jcmd:

jcmd PID JFR.start name=incident settings=profile duration=5m filename=/var/tmp/incident.jfr
jcmd PID JFR.check

Путь должен быть доступен пользователю приложения, а на файловой системе должно хватать места. Файл JFR может содержать сведения о структуре и поведении приложения, поэтому его нужно хранить и передавать как диагностические данные ограниченного доступа.

Для аварий JVM полезно заранее задать каталог error log и убедиться, что процесс может в него писать:

-XX:ErrorFile=/var/log/myapp/hs_err_pid%p.log

Core dump зависит не только от JDK, но и от лимитов systemd, параметров ядра и свободного места. Эти настройки необходимо проверять отдельно на конкретном VDS. Если приложение запускается из урезанного JRE или созданного через jlink runtime, часть утилит может отсутствовать. Возможные стратегии — оставить полную JDK в production, использовать отдельный диагностический контейнер с совместимой JDK или подготовить расширенный аварийный образ.

Производительность и потребление ресурсов

Нет универсального основания считать один из трёх дистрибутивов самым быстрым для любого VDS. Они используют общую кодовую базу HotSpot, а результат значительно сильнее зависит от версии Java и patch-релиза, размера heap, лимита памяти, сборщика мусора, числа виртуальных CPU, архитектуры, профиля нагрузки, нативных библиотек и базовой ОС контейнера.

Сначала нужно подобрать дистрибутив по жизненному циклу и эксплуатации, затем провести тест на своём приложении. Минимальный план сравнения включает холодный старт, время готовности сервиса, задержки после прогрева, throughput, RSS, паузы GC и поведение при ограничении памяти.

Нельзя запускать один вариант утром, другой вечером и сравнивать средние значения: на VDS могут меняться нагрузка соседних виртуальных машин и частота процессора. Для полезного результата нужны повторные серии на одном тарифе, одинаковый образ приложения, одинаковые параметры JVM и контроль фоновой нагрузки.

Если обнаружена большая разница между дистрибутивами одной версии, сначала стоит проверить параметры запуска и состав образов. Часто причиной оказывается другой heap, иной контейнерный лимит, отсутствующий системный пакет, дополнительный агент или различие между glibc и musl, а не код поставщика JDK.

Коммерческая поддержка: три модели

Temurin через партнёра

Temurin удобен как vendor-neutral основа, но договор поддержки заключается не с проектом Adoptium. Компания выбирает стороннего поставщика, который поддерживает Temurin, и отдельно согласовывает платформы, версии, время реакции и условия выпуска исправлений.

Corretto через AWS

Corretto особенно удобен организациям, у которых уже есть процессы эскалации в AWS. Однако перед размещением на стороннем VDS следует письменно уточнить, покрывает ли действующий план конкретную ситуацию. AWS может помочь с Corretto, но не обязан администрировать чужую виртуальную машину, исправлять пользовательский код или диагностировать сторонний гипервизор.

Liberica напрямую у BellSoft

BellSoft предлагает прямую поддержку Liberica JDK с различными уровнями SLA, внеплановыми исправлениями и длительными сроками сопровождения LTS. Это понятная модель для команды, которой нужен один ответственный поставщик runtime. Коммерческий контракт полезен, если простой сервиса дороже стоимости поддержки, отраслевые требования требуют фиксированной матрицы ПО или приложение должно долго оставаться на старой Java.

Практическая матрица решения

Безопасная смена JDK на работающем VDS

Хотя этот материал является обзором, при выборе важно понимать стоимость миграции. Не следует заменять рабочую JDK удалением старого пакета. Безопаснее установить новую версию параллельно, явно переключить тестовую службу и сохранить возможность отката.

1. Зафиксировать текущие java -version, путь к Java, параметры JVM и переменные окружения.
2. Проверить резервную копию конфигурации службы и данных приложения.
3. Установить новый JDK рядом со старым, не меняя глобальную альтернативу без необходимости.
4. Запустить staging-копию приложения на том же типе VDS и архитектуре.
5. Проверить старт, health check, логи, JFR, heap dump и агенты мониторинга.
6. Провести нагрузочный тест с production-подобным профилем.
7. Переключить одну реплику или выполнить короткое контролируемое развёртывание.
8. Оставить старую JDK до завершения периода наблюдения.

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

Итог

Для большинства Java-команд Eclipse Temurin остаётся универсальным выбором для VDS: он не привязывает инфраструктуру к облаку, поддерживает x86_64 и ARM64, удобно устанавливается на Debian- и RHEL-based системы и предлагает широкий набор контейнерных баз.

Amazon Corretto стоит предпочесть, когда эксплуатационные процессы уже построены вокруг AWS и команда действительно получает пользу от ECR, Amazon Linux и AWS Support. BellSoft Liberica JDK особенно интересна организациям, которым нужны прямой контракт на поддержку JVM, расширенный срок сопровождения или разные комплектации runtime.

Для нового сервиса следует выбирать LTS-ветку Java, подтверждённую матрицей совместимости приложения и жизненным циклом поставщика. Java 21 разумно сохранять для проверенных систем, а Java 17, 11 и 8 — только при явных ограничениях. Окончательное решение принимают после проверки полного пути: пакета или образа, архитектуры, обновлений, наличия диагностики, условий SLA и результатов теста на том типе VDS, где будет работать приложение.