Eclipse timurin jdk что это

Eclipse Temurin: A New Distribution of OpenJDK

It’s incredible that, twenty-six years after it was first released, Java is still one of, if not the most, popular software platforms in the world. One reason that has helped drive its success over the last few years is the change to a time-based six-month release cadence for the OpenJDK. As a result, we’ve seen more features added to the Java platform more quickly than ever before.

At the same time, changes to licensing have resulted in broad adoption of OpenJDK in general, and in a growing set of options that users can choose from for distributions of OpenJDK.

Today, that choice became even wider with the release of Eclipse Temurin (that’s an anagram of Runtime, if you hadn’t noticed) as part of the Eclipse Adoptium project.

What is Eclipse Temurin?

Eclipse Temurin is a free OpenJDK distribution produced as part of the multi-vendor Eclipse Adoptium Project and Working Group, of which Azul is a founding member.

Eclipse Temurin Support

To assist those who wish to deploy the Eclipse Temurin distribution of OpenJDK in enterprise environments, Azul now includes commercial support for Temurin as part of Azul Platform Core OpenJDK support subscriptions. This commercial support offering addresses the needs of users who have to comply with specific regulations or governance and those who require dependable support services for their OpenJDK deployments, backed by contractual SLAs.

The combination of Eclipse Temurin builds of OpenJDK and Azul’s industry-leading engineering and support organization is a winning combination.

See How Temurin Compares

Find out more about Eclipse Temurin
and how it stacks up to other
Java alternatives

Name already in use

temurin-build / README.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

32 contributors

Users who have contributed to this file

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Repository for code and instructions for building OpenJDK binaries, defaulting to Eclipse Temurin™

These scripts can be used to build OpenJDK anywhere but are primarily used by Eclipse Adoptium members (vendors) to build binaries. The scripts default to the use case of building Eclipse Temurin binaries which occurs on the build farm at https://ci.adoptium.net. Those binaries are then made available for consumption at https://adoptium.net and via the API https://api.adoptium.net.

NOTE In the future, adoptium.net will transition to being a marketplace for other qualifying vendors as well Eclipse Temurin.

Where can I find the release status of Eclipse Temurin™ binaries?

TL;DR: I want to build a JDK NOW

Build jdk natively on your system

To do this you will need to have your machine set up with a suitable compiler and various other tools available. We set up our machines using ansible playbooks from the openjdk-infrastructure repository. You can also look at the dockerfile generator for a list of required packages for Ubuntu.

Once you’ve got all of the prerequisites installed, clone this openjdk-build repository ( git clone https://github.com/adoptium/temurin-build and kick off a build a follows with this script. The -J parameter specifies the «boot JDK» which should generally be one major version prior to the one you are building (although one of the same major version will also work). Note that the build variant defaults to HotSpot if omitted which builds from the same repositories as Temurin.

How do I build OpenJDK in a docker image?

If you do not want to set up your machine with all the prerequisites for building OpenJDK, you can use our docker images under the [docker] directory as follows (first version builds HotSpot, second builds J9 — the final parameter can be adjusted to build whichever version you want as long as we can generate valid dockerfile for it):

We test these dockerfiles on a regular basis in the Dockerfilecheck job to ensure they continue to work in a stable fashion.

This repository contains several useful scripts in order to build OpenJDK personally or at build farm scale.

1. The build-farm folder contains shell scripts for multi configuration Jenkins build jobs used for building Adoptium OpenJDK binaries.
2. The docker folder contains tools for generating dockerfiles which can be used as part of building OpenJDK inside a Docker container.
3. The git-hg folder has now been moved to it’s own separate repository. See openjdk-mirror-scripts.
4. The pipelines folder has now been moved to a separate repo: https://github.com/adoptium/ci-jenkins-pipelines.
5. The sbin folder contains the scripts that actually build (Temurin). build.sh is the entry point which can be used stand alone but is typically called by the native-build.sh or docker-build.sh scripts (which themselves are typically called by makejdk-any-platform.sh ).
6. The security folder contains a script and cacerts file that is bundled with the JDK and used when building OpenJDK: the cacerts file is an important file that’s used to enable SSL connections.

The makejdk-any-platform.sh script

makejdk-any-platform.sh is the entry point for building (Adoptium) OpenJDK binaries. Building natively or in a docker container are both supported. This script (and its supporting scripts) have defaults, but you can override these as needed. The scripts will auto detect the platform and architecture it is running on and configure the OpenJDK build accordingly. The supporting scripts will also download and locally install any required dependencies for the OpenJDK build, e.g. The ALSA sound and Freetype font libraries.

Many of the configuration options are passed through to the configure and make commands that OpenJDK uses to build binaries. Please see the appropriate README-builds.html file for the OpenJDK source repository that you are building.

NOTE: Usage can be found via makejdk-any-platform.sh —help . Here is the man page re-formatted for convenience.

The main script to build OpenJDK is makejdk-any-platform.sh , which itself uses and/or calls configureBuild.sh , docker-build.sh and/or native-build.sh .

The structure of a build is:

1. Configuration phase determines what the configuration of the build is based on your current platform and and optional arguments provided
2. Configuration is written out to config/built_config.cfg
3. Build is kicked off by either creating a docker container or running the native build script
4. Build reads in configuration from built_config.cfg
5. Downloads source, dependencies and prepares build workspace
6. Invoke OpenJDK build via make
7. Package up built artifacts

• Configuration phase is primarily performed by configureBuild.sh and makejdk-any-platform.sh.
• If a docker container is required it is built by docker-build.sh otherwise native-build.sh.
• In the build phase sbin/build.sh is invoked either natively or inside the docker container. sbin/build.sh invokes sbin/prepareWorkspace.sh to download dependencies, source and perform general preparation.
• Rest of the build and packaging is then handled from sbin/build.sh

Building OpenJDK from other locations

Building OpenJDK from a non-Adoptium repository

These scripts default to using Adoptium as the OpenJDK source repository to build from, but you can override this with the -r flag. If you want to run from a non-default branch you can also specify -b e.g.

Building in a custom directory

This would clone OpenJDK source from https://github.com/adoptium/openjdk-jdk11u to $HOME/openjdk-jdk11u/src , configure the build with sensible defaults according to your local platform and then build OpenJDK and place the result in /home/openjdk/target/MyOpenJDK11.tar.gz .

Alongside the built assets a metadata file will be created with info about the build. This will be a JSON document of the form:

The Metadata class is contained in the Metadata.groovy file and the Json is constructed and written in the openjdk_build_pipeline.groovy file.

It is worth noting the additional tags on the SemVer is the build number.

Below are all of the keys contained in the metadata file and some example values that can be present.

• vendor: Example values: [ Eclipse Adoptium , Alibaba ]

This tag is used to identify the vendor of the JDK being built, this value is set in the build.sh file and defaults to «Adoptium».

• os: Example values: [ windows , mac , linux , aix , solaris ]

This tag identifies the operating system the JDK has been built on (and should be used on).

• arch: Example values: [ aarch64 , ppc64 , s390x , x64 , x86-32 , arm ]

This tag identifies the architecture the JDK has been built on and it intended to run on.

• variant: Example values: [ hotspot , openj9 , corretto , dragonwell , bisheng ]

This tag identifies the JVM being used by the JDK. «dragonwell» and «bisheng» itself are HotSpot based JVMs but are currently considered their own variants for the purposes of build. WARN: This will be changed at a later date when we split out JVM from vendor.

• variant_version:

This tag is used to identify a version number of the variant being built, it currently is exclusively used by OpenJ9 and has the following keys:

major: Example values: [ 0 , 1 ]

minor: Example values: [ 22 , 23 , 24 ]

security: Example values: [ 0 , 1 ]

tags: Example values: [ m1 , m2 ]

• version:

This tag contains the full version information of the JDK built, it uses the VersionInfo.groovy class and the ParseVersion.groovy class.

It contains the following keys:

minor: Example values: [ 0 ]

security: Example Values: [ 0 , 9 , 252 272 ]

pre: Example values: [ null ]

adopt_build_number: Example values: [ 0 ]
If the ADOPT_BUILD_NUMBER parameter is used to build te JDK that value will appear here, otherwise a default value of 0 appears.

major: Example values: [ 8 , 11 , 15 , 16 ]

version: Example values: [ 1.8.0_272-202010111709-b09 , 11.0.9+10-202010122348 , 14.0.2+11-202007272039 , 16+19-202010120348 ]

semver: Example values: [ 8.0.202+8.0.202008210941 , 11.0.9+10.0.202010122348 , 14.0.2+11.0.202007272039 , 16.0.0+19.0.202010120339 ]
Formed from the major, minor, security, and build number by the formSemver() function.

build: Example values: [ 6 , 9 , 18 ]
The OpenJDK build number for the JDK being built.

Eclipse timurin jdk что это

Автор этого материала — я — Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML — то есть могу доработать ваш сайт или помочь с веб-программированием. Пишите сюда.

статьи IT, java, Java App Dev, Средства разработки, jdk

• JDK Temurin: https://adoptium.net/index.html
• Средство сборки и запуска задач Gradle: https://gradle.org/
• Среда разработки Kotlin-приложений IDEA Ultimate: https://www.jetbrains.com/idea/

• IDEA Community: https://www.jetbrains.com/idea/
• Eclipse IDE: https://www.eclipse.org/
• Visual Studio Code: https://code.visualstudio.com/
• GNU Emacs: https://www.gnu.org/software/emacs/
• Vim: https://www.vim.org/

adoptium/temurin-build

These scripts can be used to build OpenJDK anywhere but are primarily used by Eclipse Adoptium members (vendors) to build binaries. The scripts default to the use case of building Eclipse Temurin binaries which occurs on the build farm at https://ci.adoptopenjdk.net. Those binaries are then made available for consumption at https://adoptium.net and via the API https://api.adoptium.net.

NOTE In the future, adoptium.net will transition to being a marketplace for other qualifying vendors as well Eclipse Temurin.

Where can I find the release status of Eclipse Temurin™ binaries?

TL;DR: I want to build a JDK NOW

Build jdk natively on your system

To do this you will need to have your machine set up with a suitable compiler and various other tools available. We set up our machines using ansible playbooks from the openjdk-infrastructure repository. You can also look at the dockerfile generator for a list of required packages for Ubuntu.

Once you’ve got all of the prerequisites installed, clone this openjdk-build repository ( git clone https://github.com/adoptium/temurin-build and kick off a build a follows with this script. The -J parameter specifies the «boot JDK» which should generally be one major version prior to the one you are building (although one of the same major version will also work). Note that the build variant defaults to HotSpot if omitted which builds from the same repositories as Temurin.

How do I build OpenJDK in a docker image?

If you do not want to set up your machine with all the prerequisites for building OpenJDK, you can use our docker images under the [docker] directory as follows (first version builds HotSpot, second builds J9 — the final parameter can be adjusted to build whichever version you want as long as we can generate valid dockerfile for it):

We test these dockerfiles on a regular basis in the Dockerfilecheck job to ensure they continue to work in a stable fashion.

This repository contains several useful scripts in order to build OpenJDK personally or at build farm scale.

1. The build-farm folder contains shell scripts for multi configuration Jenkins build jobs used for building Adoptium OpenJDK binaries.
2. The docker folder contains tools for generating dockerfiles which can be used as part of building OpenJDK inside a Docker container.
3. The git-hg folder has now been moved to it’s own separate repository. See openjdk-mirror-scripts.
4. The pipelines folder has now been moved to a separate repo: https://github.com/adoptium/ci-jenkins-pipelines.
5. The sbin folder contains the scripts that actually build (Temurin). build.sh is the entry point which can be used stand alone but is typically called by the native-build.sh or docker-build.sh scripts (which themselves are typically called by makejdk-any-platform.sh ).
6. The security folder contains a script and cacerts file that is bundled with the JDK and used when building OpenJDK: the cacerts file is an important file that’s used to enable SSL connections.

The makejdk-any-platform.sh script

makejdk-any-platform.sh is the entry point for building (Adoptium) OpenJDK binaries. Building natively or in a docker container are both supported. This script (and its supporting scripts) have defaults, but you can override these as needed. The scripts will auto detect the platform and architecture it is running on and configure the OpenJDK build accordingly. The supporting scripts will also download and locally install any required dependencies for the OpenJDK build, e.g. The ALSA sound and Freetype font libraries.

Many of the configuration options are passed through to the configure and make commands that OpenJDK uses to build binaries. Please see the appropriate README-builds.html file for the OpenJDK source repository that you are building.

NOTE: Usage can be found via makejdk-any-platform.sh —help . Here is the man page re-formatted for convenience.

The main script to build OpenJDK is makejdk-any-platform.sh , which itself uses and/or calls configureBuild.sh , docker-build.sh and/or native-build.sh .

The structure of a build is:

1. Configuration phase determines what the configuration of the build is based on your current platform and and optional arguments provided
2. Configuration is written out to config/built_config.cfg
3. Build is kicked off by either creating a docker container or running the native build script
4. Build reads in configuration from built_config.cfg
5. Downloads source, dependencies and prepares build workspace
6. Invoke OpenJDK build via make
7. Package up built artifacts

• Configuration phase is primarily performed by configureBuild.sh and makejdk-any-platform.sh.
• If a docker container is required it is built by docker-build.sh otherwise native-build.sh.
• In the build phase sbin/build.sh is invoked either natively or inside the docker container. sbin/build.sh invokes sbin/prepareWorkspace.sh to download dependencies, source and perform general preparation.
• Rest of the build and packaging is then handled from sbin/build.sh

Building OpenJDK from other locations

Building OpenJDK from a non-Adoptium repository

These scripts default to using Adoptium as the OpenJDK source repository to build from, but you can override this with the -r flag. If you want to run from a non-default branch you can also specify -b e.g.

Building in a custom directory

This would clone OpenJDK source from https://github.com/adoptium/openjdk-jdk11u to $HOME/openjdk-jdk11u/src , configure the build with sensible defaults according to your local platform and then build OpenJDK and place the result in /home/openjdk/target/MyOpenJDK11.tar.gz .

Alongside the built assets a metadata file will be created with info about the build. This will be a JSON document of the form:

The Metadata class is contained in the Metadata.groovy file and the Json is constructed and written in the openjdk_build_pipeline.groovy file.

It is worth noting the additional tags on the SemVer is the build number.

Below are all of the keys contained in the metadata file and some example values that can be present.

• vendor: Example values: [ Eclipse Adoptium , Alibaba ]

This tag is used to identify the vendor of the JDK being built, this value is set in the build.sh file and defaults to «Adoptium».

• os: Example values: [ windows , mac , linux , aix , solaris ]

This tag identifies the operating system the JDK has been built on (and should be used on).

• arch: Example values: [ aarch64 , ppc64 , s390x , x64 , x86-32 , arm ]

This tag identifies the architecture the JDK has been built on and it intended to run on.

• variant: Example values: [ hotspot , openj9 , corretto , dragonwell , bisheng ]

This tag identifies the JVM being used by the JDK. «dragonwell» and «bisheng» itself are HotSpot based JVMs but are currently considered their own variants for the purposes of build. WARN: This will be changed at a later date when we split out JVM from vendor.

• variant_version:

This tag is used to identify a version number of the variant being built, it currently is exclusively used by OpenJ9 and has the following keys:

major: Example values: [ 0 , 1 ]

minor: Example values: [ 22 , 23 , 24 ]

security: Example values: [ 0 , 1 ]

tags: Example values: [ m1 , m2 ]

• version:

This tag contains the full version information of the JDK built, it uses the VersionInfo.groovy class and the ParseVersion.groovy class.

It contains the following keys:

minor: Example values: [ 0 ]

security: Example Values: [ 0 , 9 , 252 272 ]

pre: Example values: [ null ]

adopt_build_number: Example values: [ 0 ]
If the ADOPT_BUILD_NUMBER parameter is used to build te JDK that value will appear here, otherwise a default value of 0 appears.

major: Example values: [ 8 , 11 , 15 , 16 ]

version: Example values: [ 1.8.0_272-202010111709-b09 , 11.0.9+10-202010122348 , 14.0.2+11-202007272039 , 16+19-202010120348 ]

semver: Example values: [ 8.0.202+8.0.202008210941 , 11.0.9+10.0.202010122348 , 14.0.2+11.0.202007272039 , 16.0.0+19.0.202010120339 ]
Formed from the major, minor, security, and build number by the formSemver() function.

build: Example values: [ 6 , 9 , 18 ]
The OpenJDK build number for the JDK being built.

Preface

Open Java Development Kit (OpenJDK) is a free and open-source implementation of the Java Platform, Standard Edition (Java SE). Eclipse Temurin is available in three LTS versions: OpenJDK 8u, OpenJDK 11u, and OpenJDK 17u.

Packages for Eclipse Temurin are made available on Microsoft Windows and on multiple Linux x86 Operating Systems including Red Hat Enterprise Linux and Ubuntu.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

Chapter 1. Support policy for OpenJDK

Red Hat will support select major versions of OpenJDK in its products. For consistency, these versions remain similar to Oracle JDK versions that are designated as long-term support (LTS).

Red Hat supports a major version of OpenJDK for a minimum of six years from the time Red Hat first introduces OpenJDK.

OpenJDK 17 is supported on Microsoft Windows and Red Hat Enterprise Linux until November 2027.

RHEL 6 reached the end of life in November 2020. Due to this, OpenJDK is not supporting RHEL 6 as a supporting configuration..

Additional resources

Chapter 2. Eclipse Temurin overview

Eclipse Temurin is a free and open source implementation of the Java Platform, Standard Edition (Java SE) from the Eclipse Temurin Working Group. Eclipse Temurin is based on the upstream OpenJDK 8u, OpenJDK 11u, and OpenJDK 17u projects and includes the Shenandoah Garbage Collector from version 11 and later versions.

Eclipse Temurin does not vary structurally from the upstream distribution of OpenJDK. Eclipse Temurin shares the following similar capabilities as OpenJDK:

• Multi-platform — Red Hat offers support of Eclipse Temurin on Microsoft Windows, RHEL and macOS, so that you can standardize on a single Java platform on numerous environments, such as desktop, data center, and hybrid cloud.
• Frequent releases — Eclipse Temurin delivers quarterly updates of JRE and JDK for the OpenJDK 8, OpenJDK 11, and OpenJDK 17 distributions. These updates are available as RPM, MSI, archive files, and containers.
• Long-term support (LTS) — Red Hat supports the recently released Eclipse Temurin 8, Eclipse Temurin 11, and Eclipse Temurin 17. For more information about the support lifecycle, see OpenJDK Life Cycle and Support Policy.

Chapter 3. Downloading Eclipse Temurin distributions

You can download Eclipse Temurin distribution from numerous sources, such as the Eclipse Adoptium website.

Both the Eclipse Adoptium main web page and the Eclipse Temurin web page include several download buttons for downloading different Eclipse Temurin distribution.

Procedure

Choose one of the following options to download an Eclipse Temurin distribution:

From the Adoptium home web page or from the Eclipse Temurin project page , click one of the following buttons from the web page:

• Latest LTS Release button that preselects OpenJDK 17 for the platform that it detects you are using and immediately begins downloading that selection.
• Other platforms and versions button that directs to a selection of all platform and version options, where you can choose the distribution that best suits your needs from the various formats such as archives, JRE archives and installers.
• Release archive button that directs to a selection of latest releases, older releases, and nightly beta releases. Eclipse Adoptium provides older releases and beta releases for development purposes only. Beta releases contain the most recent changes delivered into OpenJDK, which you’ll find useful for verifying fixes in development mode. Beta releases are not considered production ready and are not directly supported by Red Hat.

Additional resources

• Adoptium home web page (Adoptium)
• Eclipse Temurin (Adoptium)

Chapter 4. Distribution selection

Eclipse Temurin produces several distributions of OpenJDK. Red Hat provides support for a subset of these distributions.

All Eclipse Temurin distributions of OpenJDK contain the JDK Flight Recorder (JFR) feature. This feature produces diagnostics and profiling data that can be consumed by other applications, such as JDK Mission Control (JMC).