Convert Figma logo to code with AI

adoptium logotemurin-build

Eclipse Temurin™ build scripts - common across all releases/versions

1,022
249
1,022
265

Top Related Projects

Eclipse Temurin™ build scripts - common across all releases/versions

GraalVM CE binaires built by the GraalVM community

Community builds using source code from OpenJDK project

Quick Overview

Temurin-build is the build infrastructure for Eclipse Temurin, an open-source distribution of the OpenJDK. This repository contains scripts, tools, and documentation for building, testing, and packaging Temurin binaries across various platforms and architectures.

Pros

  • Supports multiple platforms and architectures, ensuring wide compatibility
  • Provides a standardized build process for consistent and reliable OpenJDK builds
  • Includes extensive testing and quality assurance measures
  • Offers transparency and community involvement in the build process

Cons

  • Complex build system may have a steep learning curve for new contributors
  • Requires significant computational resources for full builds across all platforms
  • Dependency on external tools and libraries may introduce potential vulnerabilities
  • Maintenance of cross-platform compatibility can be challenging and time-consuming

Getting Started

To get started with Temurin-build:

  1. Clone the repository:

    git clone https://github.com/adoptium/temurin-build.git
    
  2. Install prerequisites (varies by platform, see documentation)

  3. Run a build:

    ./makejdk-any-platform.sh --version <jdk_version> --jvm <variant>
    
  4. For more detailed instructions and options, refer to the project's README and documentation.

Competitor Comparisons

Eclipse Temurin™ build scripts - common across all releases/versions

Pros of temurin-build

  • Established project with a longer history and more contributors
  • More comprehensive documentation and build instructions
  • Wider platform support and build configurations

Cons of temurin-build

  • Potentially more complex build process due to broader scope
  • May have more dependencies and requirements for building

Code Comparison

temurin-build:

#!/bin/bash
set -eu
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source "$SCRIPT_DIR/common/common.sh"

temurin-build>:

#!/bin/bash
set -eu
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source "$SCRIPT_DIR/common/common.sh"

The code snippets are nearly identical, with only minor formatting differences. Both repositories likely share similar build scripts and structures, which is expected given they are related projects within the Adoptium ecosystem.

Note: The comparison between temurin-build and temurin-build> is not possible as they appear to be the same repository. The ">" character at the end of the second repository name might be a typo or formatting issue. Without a valid second repository for comparison, the pros and cons listed above are based on general observations of the temurin-build repository itself.

GraalVM CE binaires built by the GraalVM community

Pros of GraalVM CE Builds

  • Supports polyglot programming with multiple languages
  • Offers ahead-of-time compilation for faster startup and lower memory usage
  • Includes advanced tools like the Truffle framework for language implementation

Cons of GraalVM CE Builds

  • Larger download size due to additional language runtimes and tools
  • May have compatibility issues with some existing Java applications
  • Steeper learning curve for developers new to GraalVM concepts

Code Comparison

Temurin Build (OpenJDK-based):

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

GraalVM CE Builds:

import org.graalvm.polyglot.*;

public class PolyglotHello {
    public static void main(String[] args) {
        Context context = Context.create("js");
        context.eval("js", "console.log('Hello from JavaScript!');");
    }
}

The Temurin Build example shows a standard Java "Hello, World!" program, while the GraalVM CE Builds example demonstrates polyglot capabilities by running JavaScript code within a Java application.

Community builds using source code from OpenJDK project

Pros of ojdkbuild

  • Specialized focus on Windows builds, potentially offering better Windows-specific optimizations
  • Longer history of providing OpenJDK builds for Windows users
  • May have more Windows-specific documentation and community support

Cons of ojdkbuild

  • Less frequent updates compared to Temurin-build
  • Smaller community and contributor base
  • Limited platform support (primarily Windows-focused)

Code Comparison

While both projects are build systems for OpenJDK, their approaches differ. Here's a simplified example of how they might handle version information:

temurin-build:

VERSION_STRING=$(git describe --tags --always --dirty)
echo "Building OpenJDK version: $VERSION_STRING"

ojdkbuild:

$version = (Get-Content .\VERSION)
Write-Host "Building OpenJDK version: $version"

These snippets illustrate the different scripting languages and approaches used by each project. Temurin-build often uses bash scripts for cross-platform compatibility, while ojdkbuild primarily uses PowerShell for Windows-centric builds.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

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?

Go to the Eclipse Adoptium Top Level Project repository for release tracking.

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.

./makejdk-any-platform.sh (-J /usr/lib/jvm/jdk-xx) (--build-variant <hotspot|openj9|corretto|SapMachine|dragonwell|bisheng>) <jdk8u|jdk11u|jdk16u|jdk>

e.g.

./makejdk-any-platform.sh -J /usr/lib/jvm/jdk-10.0.2 --build-variant hotspot jdk11u

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):

./makejdk-any-platform.sh --docker --clean-docker-build jdk8u
./makejdk-any-platform.sh --podman --clean-docker-build --build-variant openj9 jdk11u

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

Repository contents

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.

USAGE

./makejdk-any-platform [options] version

Please visit https://www.adoptium.net for further support.

VERSIONS

jdk8u - Build Java 8, defaults to https://github.com/adoptium/jdk8u
jdk11u - Build Java 11, defaults to https://github.com/adoptium/jdk11u
jdk16u - Build Java 16, defaults to https://github.com/adoptium/jdk16u
jdk - Build Latest Java (Alpha/Beta), defaults to https://github.com/adoptium/jdk

OPTIONS

-b, --branch <branch>
specify a custom branch to build from, e.g. dev.
For reference, Adoptium GitHub source repositories default to the dev
branch which may contain a very small diff set to the master branch
(which is a clone from the OpenJDK mercurial forest).

-B, --build-number <build_number>
specify the OpenJDK build number to build from, e.g. b12.
For reference, OpenJDK version numbers look like 1.8.0_162-b12 (for Java 8) or
9.0.4+11 (for Java 9+) with the build number being the suffix at the end.

--build-variant <variant_name>
specify a OpenJDK build variant, e.g. openj9.
For reference, the default variant is hotspot and does not need to be specified.

-c, --clean-docker-build
removes the existing docker container and persistent volume before starting
a new docker based build.

-C, --configure-args <args>
specify any custom user configuration arguments, using 
temporary_speech_mark_placeholder in the place of any speech marks.

--clean-git-repo
clean out any 'bad' local git repository you already have.

--create-debug-image
create a debug-image archive with the debug symbols.

--create-jre-image
create the legacy JRE image in addition to the JDK image.

--create-sbom
create the CycloneDX System Bill of Materials (JSON artifact).

-d, --destination <path>
specify the location for the built binary, e.g. /path/.
This is typically used in conjunction with -T to create a custom path
/ file name for the resulting binary.

-D, --docker, --podman
build OpenJDK in a docker/podman container. -D will autodetect, using podman if found, docker otherwise.

--cross-compile
use this if you are cross compiling - it will skip the java -version checks at the end

--debug-docker
debug OpenJDK build script in a docker container. Only valid if -D is selected.

--disable-shallow-git-clone
disable the default fB--depth=1 shallow cloning of git repo(s).

-f, --freetype-dir
specify the location of an existing FreeType library.
This is typically used in conjunction with -F.

--freetype-build-param <parameter>
specify any special freetype build parameters (required for some Operating Systems).

--freetype-version <version>
specify the version of freetype you are building.

-F, --skip-freetype
skip building Freetype automatically.
This is typically used in conjunction with -f.

-h, --help
print the man page.

-i, --ignore-container
ignore the existing docker container if you have one already.

-J, --jdk-boot-dir <jdk_boot_dir>
specify the JDK boot dir.
For reference, OpenJDK needs the previous version of a JDK in order to build
itself. You should select the path to a JDK install that is N-1 versions below
the one you are trying to build.

-k, --keep
if using docker, keep the container after the build.

--make-exploded-image
creates an exploded image (useful for codesigning jmods). Use --assemble-exploded-image once you have signed the jmods to complete the packaging steps.

--custom-cacerts <true|false>
If true (default), a custom cacerts file will be generated based on the Mozilla list of CA certificates (see folder security/). If false, the file shipped by OpenJDK will be used. 

-n, --no-colour
disable colour output.

-p, --processors <args>
specify the number of processors to use for the docker build.

-r, --repository <repository>
specify the repository to clone OpenJDK source from,
e.g. https://github.com/karianna/openjdk-jdk8u.

-s, --source <path>
specify the location to clone the OpenJDK source (and dependencies) to.

-S, --ssh
use ssh when cloning git.
In case of docker build add github.com to ~/.ssh/known_hosts (e.g.: ssh github.com)
if your ssh key has a passphrase, add it to ssh-agent (e.g.: ssh-add ~/.ssh/id_rsa)

--sign
sign the OpenJDK binary that you build.

--sudo
run the docker container as root.

-t, --tag <tag>
specify the repository tag that you want to build OpenJDK from.

-T, --target-file-name <file_name>
specify the final name of the OpenJDK binary.
This is typically used in conjunction with -D to create a custom file
name for the resulting binary.

--tmp-space-build
use the temp directory for performing the build

-u, --update-version <update_version>
specify the update version to build OpenJDK from, e.g. 162.
For reference, OpenJDK version numbers look like 1.8.0_162-b12 (for Java 8) or
9.0.4+11 (for Java 9+) with the update number being the number after the '_'
(162) or the 3rd position in the semVer version string (4).
This is typically used in conjunction with -b.

--use-adoptium-devkit <Adoptium DevKit release tag>
Download and use the given DevKit from https://github.com/adoptium/devkit-binaries/releases.
The DevKit is downloaded and unpacked to WORKSPACE_DIR/WORKING_DIR/devkit
and will add the configure arg --with-devkit=WORKSPACE_DIR/WORKING_DIR/devkit.

--use-jep319-certs
Use certs defined in JEP319 in Java 8/9. Deprecated, has no effect.

--user-openjdk-build-root-directory <openjdk build root path>
Use a user specified openjdk build root directory, rather than the OpenJDK git source directory.
The directory must be empty, or not exist (in which case it gets created).

-v, --version
specify the OpenJDK version to build e.g. jdk8u.  Left for backwards compatibility.

-V, --jvm-variant <jvm_variant>
specify the JVM variant (server or client), defaults to server.

Example usage:

./makejdk-any-platform -D jdk8u
./makejdk-any-platform -T MyOpenJDK10.tar.gz jdk10

Script Relationships

Build Variant Workflow

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

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.

./makejdk-any-platform.sh -r https://github.com/sxa/openjdk-jdk8u -b main -J /usr/lib/jvm/java-1.7.0 jdk8u

Building in a custom directory

Example Usage

./makejdk-any-platform.sh -J /usr/lib/jvm/jdk-10.0.2 -s $HOME/openjdk-jdk11u/src -d $HOME/openjdk-jdk11u/build -T MyOpenJDK11.tar.gz jdk11u

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.

Metadata

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

{
    "vendor": "Eclipse Adoptium",
    "os": "mac",
    "arch": "x64",
    "variant": "openj9",
    "variant_version": {
        "major": "0",
        "minor": "22",
        "security": "0",
        "tags": "m2"
    },
    "version": {
        "minor": 0,
        "security": 0,
        "pre": null,
        "adopt_build_number": 0,
        "major": 15,
        "version": "15+29-202007070926",
        "semver": "15.0.0+29.0.202007070926",
        "build": 29,
        "opt": "202007070926"
    },
    "scmRef": "<output of git describe OR buildConfig.SCM_REF>",
    "buildRef": "<build-repo-name/build-commit-sha>",
    "version_data": "jdk15",
    "binary_type": "debugimage",
    "sha256": "<shasum>",
    "full_version_output": "<output of java --version>",
    "configure_arguments": "<output of bash configure>"
}

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.

  • opt: Example values: [202008210941, 202010120348, 202007272039]


  • scmRef: Example values: [dragonwell-8.4.4_jdk8u262-b10, jdk-16+19_adopt-61198-g59e3baa94ac, jdk-11.0.9+10_adopt-197-g11f44f68c5, 23f997ca1]

A reference the the base JDK repository being build, usually including a GitHub commit reference, i.e. jdk-16+19_adopt-61198-g59e3baa94ac links to https://github.com/adoptium/openjdk-jdk/commit/59e3baa94ac via the commit SHA 59e3baa94ac.

Values that only contain a commit reference such as 23f997ca1 are OpenJ9 commits on their respective JDK repositories, for example 23f997ca1 links to the commit https://github.com/ibmruntimes/openj9-openjdk-jdk14/commit/23f997ca1.


  • buildRef: Example values: [openjdk-build/fe0f2dba, openjdk-build/f412a523]
    A reference to the build tools repository used to create the JDK, uses the format repository-name/commit-SHA.

  • version_data: Example values: [jdk8u, jdk11u, jdk14u, jdk]

  • binary_type: Example values: [jdk, jre, debugimage, testimage]

  • sha256: Example values: [20278aa9459e7636f6237e85fcd68deec1f42fa90c6c541a2dfa127f4156d3e2, 2f9700bd75a807614d6d525fbd8d016c609a9ea71bf1ffd5d4839f3c1c8e4b8e]
    A SHA to verify the contents of the JDK.

  • full_version_output: Example values:
openjdk version \"1.8.0_252\"\nOpenJDK Runtime Environment (Alibaba Dragonwell 8.4.4) (build 1.8.0_252-202010111720-b06)\nOpenJDK 64-Bit Server VM (Alibaba Dragonwell 8.4.4) (build 25.252-b06, mixed mode)\n`

The full output of the command java -version for the JDK.


  • configure_arguments: The full output generated by configure.sh for the JDK built.