Java 17 open j9 что это

Представляем Amazon Corretto, бесплатный дистрибутив OpenJDK с долгосрочной поддержкой

Java является одним из самых популярных языков, используемых клиентами AWS, и мы стремимся поддерживать Java, сохраняя эту поддержку бесплатной. Многие наши клиенты стали беспокоиться о том, что они будут вынуждены платить за LTS-версию Java при выполнении своей рабочей нагрузки. В качестве первого шага мы недавно подтвердили долгосрочную поддержку Java в Amazon Linux. Однако, наши клиенты и более широкое Java-сообщество запускает Java на различных платформах, как на AWS, так и вне её. Вот почему мы рады анонсировать предварительную [preview] версию Amazon Corretto — бесплатного, мультиплатформенного и готового к использованию на продакшене дистрибутива OpenJDK от Amazon.

«Amazon имеет долгую и глубокую историю с Java. Я очень рад видеть, что работа нашей внутренней критически важной Java-команды становится доступной для остального мира»
— Джеймс Гослинг [James Gosling, создатель языка Java, работает в AWS с мая 2017 года]

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

Corretto поставляется с поддержкой нескольких платформ, что позволяет запускать его в облаке, на своих серверах или локальной машине. Corretto 8 preview соответствует OpenJDK 8 и доступен в настоящее время для платформ Amazon Linux 2, Microsoft Windows, macOS и в виде Docker-образа. Предварительные сборки можно загрузить с сайта aws.amazon.com/corretto. Общедоступная версия [General Availability] запланирована на первый квартал 2019 года, и будет также включать поддержку платформ Ubuntu и Red Hat Enterprise Linux. Corretto 11, соответствующий OpenJDK 11, на этих платформах выйдет с достаточным запасом по времени для тестирования до апреля 2019 года.

Мы запускаем Technology Compatibility Kit (TCK) [набор тестов для проверки реализации JVM на соответствие спецификации] на каждом релизе Corretto для обеспечения совместимости с платформой Java SE. Corretto разрабатывается как замена любому из дистрибутивов Java SE, если вы не используете функции, отсутствующие в OpenJDK (например, Java Flight Recorder [в действительности, JFR был добавлен Oracle в OpenJDK 11]). После того, как сборка Corretto будет установлена на хост и правильно настроена для запуска ваших Java-приложений (например, используя alternatives на Linux), существующие параметры командной строки, параметры настройки, мониторинг и всё остальное будет продолжать работать по-прежнему.

Amazon будет распространять обновления безопасности на Corretto 8 бесплатно по крайней мере до июня 2023 года, а на Corretto 11 — до августа 2024 года. Corretto включает в себя бэкпорты из более новых версий, а также свежие улучшения от сообщества OpenJDK. Процесс выпуска включает в себя тестирование на тысячах сервисах Amazon, что позволяет выпускать исправления в течение нескольких дней после обнаружения проблем.

Начало работы

Самый простой способ попробовать Corretto — это скачать пакет под выбранную платформу и проверить версию Java:

% java -version openjdk version "1.8.0_192" OpenJDK Runtime Environment (build 1.8.0_192-amazon-corretto-preview-b12) OpenJDK 64-Bit Server VM (build 25.192-b12, mixed mode)

На странице загрузки есть список ссылок на инструкции по установке на все поддерживаемые платформы.

Corretto и OpenJDK

Amazon уже внёс небольшой вклад в OpenJDK 8 и мы с нетерпением ждём возможности тесно сотрудничать с сообществом OpenJDK над будущими улучшениями OpenJDK 8 и 11. Мы переносим исправления, сделанные в OpenJDK, добавляем улучшения на основе нашего собственного опыта и потребностей, а затем создаём сборки Corretto. Если продвижение этих патчей не будут успешными, окажутся отложенными или не подойдут для проекта OpenJDK, мы будем предоставлять их нашим клиентам до тех пор, пока патчи будут иметь ценность для них. Если проблема будет решена в OpenJDK другим образом, мы перейдём к этому решению, как только этот переход будет безопасным. Вы можете найти исходный код Corretto по адресу github.com/corretto.

Мы планируем, что Corretto станет дистрибутивом OpenJDK по умолчанию на Amazon Linux 2 в 2019 году.

Мы призываем вас запускать ваши Java-приложения с использованием Corretto. Загрузите Corretto 8, посетив aws.amazon.com/corretto, и узнайте больше об этом, прочитав документацию на docs.aws.amazon.com/corretto. Не стесняйтесь задавать любые вопросы на StackOverflow или в Твиттере (@awsopen).

Об авторе

Arun Gupta — Principal Open Source Technologist в AWS. Занимается всем связанным с контейнерами и Open Source в AWS. За своими плечами имеет продолжительный опыт работы в Sun, Oracle, Red Hat, Couchbase, а теперь и в AWS. Ведёт популярный твиттер-аккаунт @arungupta, активно выступает на конференциях (в прошлом году выступал на московском JPoint).

Java теперь платная? Развенчиваем слухи (или нет?)

Уже 2 дня как вступили в силу изменения лицензионной политики Oracle на распространение сборок Java SE. В среде разработчиков-слоупоков (я тоже в их числе) начали носиться кошмарные слухи.

Что произошло

В середине 2018 года Oracle объявил, что собирается изменить лицензионную политику. 16 апреля 2019 года изменение вступило в силу. Теперь все опубликованные после этой даты сборки Java SE можно использовать бесплатно только для личных нужд и с целью разработки. Для использования в коммерческих целях (в том числе для продакшена) надо оформить платную подписку у Oracle.

Что-а-а?

Oracle выстрелил себе в ногу и убивает Java? Нет, не убивает. Нет, не выстрелил. Но проблем халявщикамвсем нам подкинул. Давайте быстро разберемся, что это означает в практическом плане, без этих ваших GPL, BCL, WTF…

Зачем они это сделали?

Как известно, Oracle на самом деле собирает и публикует две версии JDK: Oracle JDK (aka Java SE, расположена на java.com) и Open JDK (расположена на openjdk.java.net).
Чтобы понять смысл всей затеи достаточно взглянуть на этот слайд из их презентации:

Для коммерческой сборки поддержка длительная. Для бесплатной – короткая. Т.е. чтобы накатить патчи на бесплатную OpenJDK через полгода надо будет проапгрейдить версию. Oracle JDK будет выпускать патчи еще 5 лет после выпуска. Поэтому она платная.

Что насчет Java 8, 9, 10, 11.

Это касается всех версий.

Это касается JRE?

Нигде отдельно не указывается лицензия на JRE. Считается, что раз JRE является подмножеством JDK, то и лицензионные ограничения такие же. Т.е. — да, это касается JRE.

Это мне надо теперь все снести на продакшене.

Нет. Изменения касаются только новых выпусков (после 16 апреля). Для Java 8 SE первым выпуском с ограничениями стала Update 211. Все что было выпущено ранее, можно использовать дальше без ограничений.

А что теперь делать?

Ставить OpenJDK. Но сам OpenJDK от Oracle не имеет официального виндового установщика (и автоматического апдейта), надо его распаковывать руками.

Если вам важен именно установщик, остается только пользоваться ранними релизами от Oracle (Update 202). А апдейты все равно придется отключить.

UPD: В комментариях подсказали, что существуют бесплатные бинарники с установщиком AdoptOpenJDK, поддерживаемые comunity.
Еще можно обратить внимание на Liberica JDK, которая поддерживается JetBrains.

А от OpenJDK ничего не сломается?

Не должно (с). Отличия в функциональности минимальны и очень мало кого затрагивают. При этом Oracle планомерно уменьшает эти различия, вливая их в OpenJDK или удаляя совсем.

OpenJ9 JCL Preprocessor (JPP) is extended to the extensions for OpenJDK

OpenJ9 has been using the JPP to produce a custom set of libraries from a single JCL codebase since its inception. The customized libraries are used to build OpenJ9 JDKs. Initially, only the OpenJ9 JCL codebase is structured to support various JPP configurations.

Recently the JPP is extended to preprocess some of the JCL code in the extensions for OpenJDK. For the relation between OpenJ9 and the extensions, refer to What is Eclipse OpenJ9?

This blog first gives a short overview of JPP usage, then shows how it is extended to the extensions.

JPP expressions

There are a set of JPP expressions that appear as part of the JCL source code. Each expression evaluates to either true or false. If you are familiar with the use of #ifdef and #if in C compiler pre-processors then this will be recognizable to you.

The JPP expressions are written directly in the source code as comments.

Decide if a file is included

/*[INCLUDE-IF (JAVA_SPEC_VERSION >= 8) & CRIU_SUPPORT]*/

Only include the following code if the condition is met

/*[IF JAVA_SPEC_VERSION >= 11]*/

Only include the following code if the condition is NOT met

/*[ELSE] JAVA_SPEC_VERSION >= 11 */

End a directive

/*[ENDIF] JAVA_SPEC_VERSION >= 11 */

There are other JPP expression usages that are not covered here.

JPP configuration file

jpp_configuration.xml is used to keep configuration information. JPP first reads this file and loads configurations such as output path, flags, parameters, etc. before it builds a customized library.

A sample configuration for Java 17

The set of flags defined by flags= and those inherited from dependencies= are used in JPP expressions. JAVA_SPEC_VERSION is a special variable, always available, that equates to the version being built. Otherwise, only the flags found in the jpp_configuration.xml (and the -tag:define command line option) are valid for use in expressions. Anything else results in an error when pre-processing.

JPP is built from source

JPP is built from the source in each OpenJ9 build.

A sample log output

Building OpenJ9 Java Preprocessor Building /home/jenkins/workspace/Build_JDK17_x86-64_linux_OpenJDK17/build/linux-x86_64-server-release/support/j9tools/jpp.jar

JPP headless

OpenJ9 builds run JPP headless to generate the JCL code for its JDK level. As explained above, the source code is augmented by JPP expressions that define various subsets for the supported java versions and components.

Command line to preprocess OpenJ9 JCL source files

java -cp jpp.jar -Dfile.encoding=US-ASCII com.ibm.jpp.commandline.CommandlineBuilder -verdict -config JAVA17 -baseDir openj9-openjdk-jdk17/openj9/ -srcRoot jcl/ -xml jpp_configuration.xml -dest build/linux-x86_64-server-release/support/j9jcl -tag:define CRIU_SUPPORT;PLATFORM-xa64

The flags defined by -tag:define are added in addition to the flags=»OPENJDK_METHODHANDLES» that is part of the JPP configuration, and also those inherited from dependencies=»JAVA11″ .

Command line to preprocess DDR source files

java -cp jpp.jar -Dfile.encoding=US-ASCII com.ibm.jpp.commandline.CommandlineBuilder -verdict -config GENERIC -baseDir openj9-openjdk-jdk17/openj9/debugtools/DDR_VM/ -srcRoot src/ -xml jpp_configuration.xml -dest build/linux-x86_64-server-release/support/j9jcl/openj9.dtfj/share/classes -tag:define CRIU_SUPPORT;PLATFORM-xa64

JPP Plugin

The JPP Plugin is an Eclipse front-end to the OpenJ9 JCL Preprocessor.

The JPP plugin generates a pConfig Eclipse Java project by using the outputpath of the config i.e. pConfig JAVA17 for the JAVA17 configuration, which contains the preprocessed OpenJ9 Java code for Java 17 .
Any changes in OpenJ9 JCL are preprocessed and the pConfig project is updated as source files are saved.

JPP is extended to the Extensions for OpenJDK for OpenJ9

All source files within the closed folder are preprocessed by JPP.

java -cp jpp.jar -Dfile.encoding=US-ASCII com.ibm.jpp.commandline.CommandlineBuilder -verdict -config JAVA17 -baseDir openj9-openjdk-jdk17/ -srcRoot closed/ -xml jpp_configuration.xml -dest build/linux-x86_64-server-release/support/j9jcl -tag:define CRIU_SUPPORT;PLATFORM-xa64 -includeIfUnsure -noWarnIncludeIf

All source files copied into an overlay folder are preprocessed by JPP.

java -cp jpp.jar -Dfile.encoding=US-ASCII com.ibm.jpp.commandline.CommandlineBuilder -verdict -config JAVA17 -baseDir openj9-openjdk-jdk17/build/linux-x86_64-server-release/support/ -srcRoot overlay/ -xml jpp_configuration.xml -dest build/linux-x86_64-server-release/support/j9jcl -tag:define CRIU_SUPPORT;PLATFORM-xa64 -includeIfUnsure -noWarnIncludeIf

Because JPP doesn’t support the whole OpenJDK codebase, the selected Java files to be preprocessed by JPP are required to be copied using the following script. If you want to preprocess a new file, modify this script code snippet.

$(eval $(call SetupCopyFiles,COPY_OVERLAY_FILES, \ SRC := $(TOPDIR), \ DEST := $(SUPPORT_OUTPUTDIR)/overlay, \ FILES := \ src/java.base/share/classes/java/lang/ClassValue.java \ src/java.base/share/classes/java/security/Security.java \ src/java.base/share/classes/java/util/Timer.java \ src/java.base/share/classes/java/util/TimerTask.java \ src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java \ src/java.base/unix/classes/java/lang/ProcessEnvironment.java \ ))

There is a special case to handle StandardCharsets.java since it is generated from StandardCharsets.java.template separately by GensrcCharsetMapping.gmk .

 $(CP) $(CHARSET_GENSRC_JAVA_DIR_BASE)/StandardCharsets.java $(SUPPORT_OUTPUTDIR)/overlay-gensrc/src/java.base/sun/nio/cs/ $(call RunJPP, JAVA$(VERSION_FEATURE), $(SUPPORT_OUTPUTDIR)/overlay-gensrc, /overlay-result) $(CP) $(SUPPORT_OUTPUTDIR)/overlay-result/java.base/sun/nio/cs/StandardCharsets.java $(CHARSET_GENSRC_JAVA_DIR_BASE)/

java -cp jpp.jar -Dfile.encoding=US-ASCII com.ibm.jpp.commandline.CommandlineBuilder -verdict -config JAVA17 -baseDir openj9-openjdk-jdk17/build/linux-x86_64-server-release/support/ -srcRoot overlay-gensrc/ -xml jpp_configuration.xml -dest build/linux-x86_64-server-release/support/overlay-result -tag:define CRIU_SUPPORT;PLATFORM-xa64 -includeIfUnsure -noWarnIncludeIf

Summary

OpenJ9 JPP is extended to preprocess some selected folders and files within the OpenJ9 extensions of OpenJDK. Note the JPP Eclipse plugin doesn’t preprocess those files yet.

If you need a hand adding java files to be preprocessed by JPP, feel free open an OpenJ9 issue or reach out to me directly.

References:

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Facebook (Opens in new window)
• Click to share on LinkedIn (Opens in new window)

Getting IBM OpenJ9 Java and Setting it as the Default Java for use with IBM i ACS

How to get the IBM OpenJ9 OpenJDK and set it as the workstation’s default Java so that IBM i Access Client Solutions uses that Java.

Steps

1. Go to the IBM Semeru website to download the current IBM Open J9 JDK 11 using this URL:

And make sure that the options for Open JDK11 and Open J9 are selected as shown below. For this example, select the Windows x64 platform as shown.

2. IBM i Access Client Solutions only requires the JRE on Windows so select to download the MSI for that as shown.

3. Save the msi file to the workstation.

4. After saving the file, go to the download location and it will contain the saved msi file. Right click the file and select Properties and check the Unblock option and select Apply and then OK as shown here.

5. Double-click the msi file to launch the setup and select Next.

6. Check to accept the License Agreement and select Next.

7. Make sure all of the features are selected to be installed. If they are not, click the drop-down for the feature and select «Will be installed on local hard drive.» When it is confirmed that all of the features are set to be installed, select Next.

8. Confirm the installation by selecting the Install option.

9. When the installation has completed, select Finish to exit the setup.

10. When IBM i Access Client Solutions is launched, the JAVA_HOME environment variable is investigated and if it is found to point to a valid location and that contains a compatible Java to use, it is used by the IBM i Access Client Solutions launch, as shown by the IBM i ACS Help -> About.

Expected primary expression before token что значит

Как начало рабочей недели

Как удалить таблицу mbr разделов с диска

Как указать относительный путь к файлу в java