От переводчика: Решение перевести эту статью пришло не само собой — скорее это вынужденная мера :). К нам, как к вендорам фреймворка CUBA, обращаются с этим вопросом с завидной регулярностью. Безусловно, для нас это тоже крайне важная тема, и в ответ на последние изменения мы подняли тестовые стенды как на Oracle JDK, так и на OpenJDK — эта мера на данный момент ограждает наших пользователей от непредвиденных лицензионных трат. Однако, эта тема еще не закрыта, и мы продолжаем внимательно следить за развитием событий, и, кто знает, возможно нам придется добавлять стенды для еще каких сборок JDK уже в следующем году...
Статья под катом подкупает тем, что она лаконично описывает проблематику и наиболее популярные JDK с их особенностями.
Недавно Oracle заявили, что эволюция Java координально изменится благодаря переходу на "Release Train" — новому подходу к выкатыванию версий. Это изменение также повлекло за собой перемены в плане поддержки версий, которая теперь будет осуществляться не для всех, а только для LTS версий. Сообщество Java чемпионов разъяснило вводимые новшества, детальный документ доступен в сети.
Даже с учетом этих новостей остаются вопросы: какие билды JDK сейчас доступны? Будут ли они бесплатными или коммерческими? Прежде чем ответить на этот вопрос, важно понять, какие требования предъявляются к JDK как продукту. Фактически, есть только один основной исходный код JDK. Он находится здесь. Кто угодно может использовать исходный код для построения собственной сборки и размещения ее где-то в сети. Однако есть отдельная процедура сертификации, которая должна быть пройдена, чтобы сборка JDK считалась валидной. Сертификация осуществляется Java Community Process (JCP), который предоставляет Technology Compatibility Kit (TCK). Если какая-либо организация создает новую сборку OpenJDK, которая отвечает TCK, она считается "совместимой с Java SE".
Имейте в виду, что сборка не может называться "Java SE", если компания, осуществившая сборку, не приобрела коммерческую лицензию от Oracle. Например, сборки AdoptOpenJDK, которые проходят TCK, не являются "Java SE", но являются "Java SE compliant". Также нужно учитывать, что сертификация сейчас основывается “на честном слове” — результаты не отсылаются в JCP/Oracle для верификации и являются закрытой информацией. Короче говоря, каждый вендор, взявший исходники OpenJDK и собравший версию, порождает еще одну отдельную сборку JDK.
Итак, без лишних слов, рекомендуем ознакомиться со следующими готовыми к использованию JDK:
Oracle JDK
Это главный поставщик Java 11 (релиз уже состоялся). Это коммерческая версия с платной поддержкой. Ее можно бесплатно скачивать и использовать только непосредственно для разработки. Использовать ее в продакшене, не заплатив Oracle, нельзя (так что для многих не интересующихся вопросами лицензирования это ловушка). Oracle планирует предоставлять платную поддержку до 2026 года и далее. В отличие от того, как было раньше, сборка Oracle JDK ничем не “лучше” OpenJDK (по стольку по скольку оба находятся на одном и том же уровне security patch level).
OpenJDK Build от Oracle
Существует бесплатные не-брендовые версии OpenJDK, распространяемые по лицензии GPL с Classpath Extension (подходит для коммерческого применения). Эти версии сборки доступны только в течение 6 месяцев после релиза. Для Java 11 ожидается выход версии Java 11.0.0 и два security -патча, 11.0.1 и 11.0.2. Чтобы продолжать использование версии OpenJDK и его патчей от Oracle, необходимо перейти на Java 12 не позднее, чем через месяц после запуска. Обратите внимание, что порядок обеспечения security-патчей отличается от порядка предоставления поддержки, которая включает в себя оплату обработки отчетов об ошибках.
AdoptOpenJDK
Это тоже бесплатные и не-брендовые сборки OpenJDK, распространяемые по лицензии GPL с Classpath Extension, только в отличие от билдов OpenJDK от Oracle эти версии сборки будут действовать в течение более длительного времени для основных версий, таких как Java 11. Версии Java 11 будут выпускаться в течение 4 лет через год после следующего основного релиза. AdoptOpenJDK ориентируется на сообщество. Пока другие команды создают и публикуют исправления безопасности для исходного репозитория OpenJDK, они будут выпускать билды. И IBM, и Red Hat обозначили, что намерены выпускать такие патчи.
AdoptOpenJDK OpenJ9
Вдобавок к стандартным сборкам OpenJDK AdoptOpenJDK будет также предоставлять версии с OpenJ9 вместо HotSpot. OpenJ9 изначально была JVM от IBM, но сейчас OpenJ9 имеет открытый исходный код. И, кстати говоря, эта опция наиболее достойная изучения.
Red Hat OpenJDK
Red Hat предоставляет версии сборки OpenJDK на Red Hat Enterprise Linux (RHEL), являющемся коммерческим продуктом с платной поддержкой. Red Hat очень неплохо справляются с исправлениями безопасности в OpenJDK. В прошлом Red Hat отвечали за security-апдейты Java 6 и 7. Сборка от Red Hat более интегрирована с операционной системой, так что ее нельзя назвать типичным билдом OpenJDK (отсутствует JDK конечного пользователя).
Azul Zulu
Zulu — брендированная версия OpenJDK с платной коммерческой поддержкой. К тому же, хотя Azul предоставляет некоторые элементы Zulu бесплатно в рамках "Zulu Community", они не несут никаких особых обязательств по доступности этих сборок. У Azul довольно масштабный план по поддержке Zulu, включающий поддержку Java 9, 13 и 15, в отличие от других поставщиков.
Amazon Corretto
Это новейшая из всех описанных опций. Corretto — бесплатная версия сборки OpenJDK с долгосрочной поддержкой, проходящая TCK. Она распространяется по стандартным условиям лицензирования всех версий OpenJDK: GPL + CE. Amazon создаст собственные патчи и запустят Corretto на AWS, так что он будет использоваться довольно активно (и уже добавлен в некоторые продукты). Поддержка Java 8 планируется по меньшей мере до июня 2023.
В процессе преобразования исходного OpenJDK в различные версии сборки производитель может добавлять различные утилиты или брендировать продукт, если это не препятствует сертификации (TCK). Например, нельзя добавить новый public-метод в API или новые языковые ресурсы.
Есть и другие реализации JDK, такие как IBM и SAPMachine. Однако эти версии сборки не так часто используются, поэтому они не упомянуты в этой статье. Более подробную информацию можно найти здесь и здесь.
Заключение
Лично я особой проблемы в наличие нескольких версий JDK не вижу, так как всем им нужно проходить сертификацию (TCK). Чем действительно стоит обеспокоиться — это использование одной из проприетарных JDK и бесплатной версии сборки от Oracle, во избежание головной боли в будущем. Если вы используете только базовые функции (например, ваш бизнес не особо зависит от секьюрити-апдейтов), вам больше подойдут сборки OpenJDK от Oracle (НЕ OracleJDK), т.к. они постоянно обновляются (в течение 6 месяцев после релиза), и вы можете использовать JDK в продакшене без особых проблем. Если в вашем бизнесе задействованы облачные сервисы (или с AWS), хорошим выбором будет AWS Corretto, который уже пригоден к использованию на Amazon Linux и Docker.
Комментарии (18)
Dmitry88
29.12.2018 15:19«Есть и другие реализации JDK, такие как IBM и SAPMachine. Однако эти версии сборки не так часто используются, поэтому они не упомянуты в этой статье.»
Что-то казалось, что JDK от IBM стояли штатно в SLES. Или показалось?Gutt
29.12.2018 15:44Нет, не показалось, сборка OpenJDK от IBM там.
Dmitry88
29.12.2018 23:02То есть помимо Power еще и x86 c популярным SLES. Отчего же тогда не часто?
aleksey-stukalov Автор
29.12.2018 23:05Ждал вопроса, для ответа даже сделал опрос, в котором и видно ответ :)
Miron11
30.12.2018 01:47Полезный обзор. Может это не совсем по теме, но даже самый поверхностное перечисление ведущих пакетов ПО с версией Java VM, чтобы просто понять, как продвигается восприятие Java от 9 и дальше, было бы исключительно интересно.
Девятке второй год или больше. Но у меня складывается ощущение, что платформу встретили с интересом, но переходить на неё, мягко говоря, не спешат. Не знаю, если это интересует автора, но было бы очень интересно. Никаких мыслей о холивар или политике. Просто срез ведущих пакетов ПО — версия VM для осмысления.APXEOLOG
30.12.2018 03:16Spring, Hibernate, да и практически все-все-все уже поддерживают Java 11. Сейчас уже отстутсвие поддержки Java 11 вызовет удивление, а не наоборот.
Для моих личных проектов переход с Java 8 сильно тормозился тем, что Lombok не поддерживал новые версии языка. В итоге я решил эту проблему перейдя на Kotlin (опять же на основе Java 11), чем вполне доволен. На 12ю планирую переходить как только она релизнется
pmcode
30.12.2018 07:32Мне в AdoptOpenJDK понравилось что они делают также сборку JRE. Поскольку сообщество и большинство разработчиков библиотек дружно положило болт на поддержку Jigsaw, планы Oracle, что каждый будет собирать свой собственный runtime image вряд ли сбудутся раньше чем через 2-3 года. Даже стабильного Maven плагина для jlink еще нет. А без поддержки Jigsaw сообществом Java 11 ? Java 8 + несколько приятных улучшений в стандартной библиотеке. Имхо, рано Oracle слился. Надо было дождаться пока Jigsaw станет стандартом не на словах.
d_ilyich
30.12.2018 14:40А вот STM32CubeMX, судя по всему, работает только с Oracle'вскими JRE. Во всяком случае, под Windows мне не удалось подружить Adopt и Cube. Сам патчить/собирать не пробовал.
Sap_ru
31.12.2018 18:40+1Пусть они со своим Jigsaw…
Пример. У меня есть четыре десктоп-приложения, которые могут устанавливаться раздельно или вместе. Но это различные приложения. Мне теперь нужно тянуть сотню метров дополнительного с каждым? И при обновлении приложения пользователь должен всё это заново перекачивать и переустанавливать. И памяти они теперь тоже будут жрать кратно больше.
Зашибись перспектива!
Как-то упорно забыли, что десктоп-приложения для Windows.
Harrix
30.12.2018 22:28Глупый вопрос: для Android проектирования использование официального JDK не означает же, что нужно Oracle потом платить, когда будет распространяться приложение? Эта же ситуация подходит под «можно бесплатно скачивать и использовать только непосредственно для разработки»?
chemtech
Спасибо за статью.
Как проверить какая Java/OpenJDK используется по умолчанию в CentOS? (наверное от Redhat — но все же).
Как проверить именно Java/OpenJDK используется по умолчанию в Ubuntu/Debian?
Задам по другому вопрос:
mirror.centos.org/centos/7.6.1810/os/x86_64/Packages/java-1.8.0-openjdk-1.8.0.181-7.b13.el7.x86_64.rpm — Скорее всего это OpenJDK от Redhat — но как проверить?
security.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jdk_8u191-b12-0ubuntu0.18.04.1_amd64.deb — как проверить что эта реализация от Oracle?
foxyrus
Разве JDK предустанавливается?
aleksey-stukalov Автор
На сколько я знаю JDK по умолчанию не предустанавливается. Но все же есть «умолчальный» зверь, который ставится как:
>
apt-get install default-jdk
aleksey-stukalov Автор
Не сильно приходилось использоваться CentOS, так что не буду врать. Что касается Ubuntu/Debian, чтобы не быть голословным официальная информация есть тут.
Попробуйте вот так
>
java -XshowSettings:properties -version
apangin
OpenJDK 64-Bit Server VM (25.191-b12) for linux-amd64 JRE (1.8.0_191-b12), built on Nov 19 2018 16:07:16 by "mockbuild" with gcc 4.8.5 20150623 (Red Hat 4.8.5-36)
Ещё тому подтверждение, что в JDK от Red Hat есть сборщик мусора Shenandoah. Можно проверить флагом
java -XX:+UseShenandoahGC
.Плохо, что в статье так и не раскрыто, чем же всё-таки сборки отличаются друг от друга. Вот, в Red Hat как раз Shenandoah GC. А, например, в Amazon Coretto по сравнению со стоковой OpenJDK такой список патчей.
Все производные от OpenJDK в той или иной степени «от Oracle». На самом деле, в Ubuntu своя собственная сборка от Canonical.