adoptopenjdk / install-jdk

Github action that installs SDKs served up by the AdoptOpenJDK API

install-jdk

An action to download and install JDKs for use in workflows.

This action is based on the actions/setup-java action by GitHub which works perfectly fine for simple workflows but does not scale and lacks configurability.

JDKs are downloaded from AdoptOpenJDK.

Usage

See action.yml

Basic

steps:
- uses: actions/checkout@v1
- uses: AdoptOpenJDK/install-jdk@v1
  with:
    version: '13'
    architecture: x64

Multiple JDKs

Some projects may require multiple JDK versions to build. install-jdk supports installing JDKs to one (or more) given target environment variables.

- uses: AdoptOpenJDK/install-jdk@v1
  with:
    version: '8'
    architecture: x64
- uses: AdoptOpenJDK/install-jdk@v1
  with:
    version: '13'
    architecture: x64
    targets: 'JDK_13'

Configuration:

Parameter	Default
version
architecture	x64
source	releases
sourceType
archiveBasePath	/Contents/Home/ (macOS only)
useArchiveBasePath	true
archiveExtension
targets	JAVA_HOME
impl	hotspot

version

The Java version to install a JDK for. (Supported values are: 1.8, 8, 9, 10, 11, 12, 13, ...)

By default, this action will try to install the latest JDK release for the specified version from AdoptOpenJDK. Alternatively, a source can be specified explicitly.

The version key should be set accordingly for custom downloads since it is used to cache JDKs which are used multiple times during the workflow.

architecture

The target architecture of the JDK to install.

Defaults to x64.

source

A custom source for a JDK. (See sourceType for supported values.)

sourceType

The type of the source parameter. Supported source types are:

• url - HTTP and HTTPS URL sources
• file - local directories, or compressed archives
• buildType - AdoptOpenJDK build types ("nightly", or "releases".)

The parameter may be set to empty, to automatically infer the type. The inferred type is:

1. url, if source starts with "http://" or "https://",
2. file, if source resembles a valid local file path and the file exists,
3. or buildType otherwise.

archiveBasePath

install-jdk expects a single top-level folder in archive packages. This parameter may be used to specify the subdirectory of said folder in which the JDK resides. This must be empty, or a /-separated path.

By default, this parameter is set to /Contents/Home/ on macOS only to support OpenJDK builds from Oracle, and OpenJDK and OpenJ9 builds from AdoptOpenJDK out of the box.

When using builds from other sources, it may be necessary to disable use of this parameter since the action cannot differentiate between empty and unspecified parameters. (See useArchiveBasePath.)

useArchiveBasePath

Disables use of the archiveBasePath parameter. This must be a boolean value.

Build archives from custom other may have different directory structures for which the default configuration would fail. E.g.: For Azul's Zulu builds it should be set to false (useArchiveBasePath : 'false').

archiveExtension

The extension of the JDK archive. (Supported values are: .zip, .tar, .7z)

Specifying this parameter is required when a custom source is set.

targets

A semicolon-separated list of environment variables which will be set up to point to the installation directory of the JDK.

By default, this is set to JAVA_HOME. Keep in mind that this is overwritten when specifying targets explicitly. Thus, if you want to make a JDK available from - say - JDK_X and JAVA_HOME, you would need to specify:

targets: 'JDK_X;JAVA_HOME'

impl

JVM implementation. (Supported values are: hotspot, openj9)

install-jdk's Issues

AdoptOpenJDK vendor not used/detected after install

I recently started using the maven-enforcer-plugin to warn if AdoptOpenJDK as a Java vendor wasn't being used, which works locally, but after the first pipeline run, it detected a different vendor in use as you can see here:

1247  Warning:  Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVendor warned with message:
1248  Eclipse Foundation is not an included Required Java Vendor

The expectation is that this would not throw a warning because I use AdoptOpenJDK/[email protected] before this step with the following configuration:

- name: Install AdoptOpenJDK
  uses: AdoptOpenJDK/[email protected]
  with:
    version: '16'
    architecture: x64
    impl: hotspot

Is something in the environment not being set by this action that causes Eclipse Foundation to be the detected vendor that my project is compiling against?

I will be testing soon to see if using actions/setup-java produces the same result as this action is now more configurable with import features like configuring the global settings.xml file for automated deployments to maven central, however, for regular build workflows, I still prefer to use AdoptOpenJDK/install-jdk.

Support Eclipse Temurin distribution

As AdoptOpenJDK has been transferred to Adoptium, I suggest following the upstream project and introduce a configuration parameter distribution for the new Eclipse Temurin runtime.

Automatically determine the archiveExtension based on the source URL

Instead of requiring the archiveExtension parameter to be specified if the source is a URL, determine the archiveExtension automatically in code based on the source URL.

Download JDKs from AdoptOpenJDK nightly builds ( EA)

The AdoptOpenJDK API provides a way to consume AdoptOpenJDK releases and nightly builds. Current only download releases(GA) JDKs is supported. Nice to also support download nightly (EA) JDKs.

https://github.com/AdoptOpenJDK/install-jdk/blob/master/src/installer.ts#L66

Which would be consistent with AdoptOpenJDK/openjdk-tests story. I.E. sdk source: nightly, releases, customized, upstream.

nightly --> AdoptOpenJDK V3 API EA
releases --> AdoptOpenJDK V3 API GA
customized --> A custom source location of a JDK. A local directory, a compressed file, or a url.
upstream --> AdoptOpenJDK/build-jdk action or could be included in customized as a local
compressed file

Redirect source URLs are not handled

URL sources which redirect are not handled by the action.
Example SDK source: https://corretto.aws/downloads/latest/amazon-corretto-8-x64-linux-jdk.tar.gz

Node.js 12 actions are deprecated.

As title...
When I use this action I get this warning from GitHub.

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: AdoptOpenJDK/[email protected]

Can you fix it please before they shut down node js 12 please?

Thanks.

[Feature request] settings.xml

Hi all,
this is a feature request, is it possible to implement the creation of the settings.xml for maven as in the
setup-java action described here:
https://docs.github.com/en/free-pro-team@latest/actions/guides/publishing-java-packages-with-maven

using the AdoptOpenJDK/install-jdk@v1 action

      - name: Set up AdoptOpenJDK 15
        uses: AdoptOpenJDK/install-jdk@v1
        with:
          version: '15'
          architecture: x64

Thanks for your support and for your great project.

Add flags for TEST_IMAGES_REQUIRED and DEBUG_IMAGES_REQUIRED

Similarly to the Jenkins Grinder, there should be options for setting the flags TEST_IMAGES_REQUIRED and DEBUG_IMAGES_REQUIRED

The `set-env` command is deprecated and will be disabled soon.

Using the adopt install jdk action returns a warning

      - name: Set up AdoptOpenJDK 15
        uses: AdoptOpenJDK/install-jdk@v1
        with:
          version: '15'
          architecture: x64

this is the warning with some errors.

Run AdoptOpenJDK/install-jdk@v1
C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -Sta -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command "$ErrorActionPreference = 'Stop' ; try { Add-Type -AssemblyName System.IO.Compression.FileSystem } catch { } ; [System.IO.Compression.ZipFile]::ExtractToDirectory('D:\a\_temp\5dc80748-a307-4a7c-b574-02c961aae42d', 'D:\a\_temp\temp_746465718')"
Warning: The `add-path` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
Warning: The `set-env` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

probably you know it but an issue is just a reminder :)
thank you for your great product.

JDK for Macos download from AdoptOpenJDK aren't installed properly

JDKs for Macos download from AdoptOpenJDK have different directory structure from jdk from Zulu. JDKs Macos from AdoptOpenJDK have extra directory layer /Contents/Home/. That means we can't run java program if we install macos jdk as JAVA_HOME.

We can easily fix this by appending /Contents/Home/ to current JAVA_HOME( this is what run-aqa action does to work around this mac issue, which shouldn't be done at that layer).

Or if we could know the story of this difference between AdoptOpenJDK and Zulu we can make a better decision?