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.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: https://github.com/actions/setup-java/issues/13#issuecomment-535765089

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.

[giltene]

FYI, with the latest updates just integrated into v1.3 (https://github.com/actions/setup-java/releases/tag/v1.3.0), EAs for both OpenJDK 14 and OpenJDK 15 are now live, and will continue to be regularly populated in the Zulu community CDN on a regular basis. In addition, EA builds can now be distinguished by EA version, and the supported ways to "spell" the EA versions include e.g.: 14-ea 14.0.0-ea 14.0.0-ea.28

So both

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

and

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

now work.'

README updates will follow.

Happy New Year!

[kwin]

Now the adoptopenjdk api allows even to download the official RedHat binaries for Open JDK (https://github.com/AdoptOpenJDK/openjdk-api-v3).

[giltene]

Now the adoptopenjdk api allows even to download the official RedHat binaries for Open JDK (https://github.com/AdoptOpenJDK/openjdk-api-v3).

To clarify, those are not “the official Red Hat Binaries for OpenJDK”:

1. They are not “official binaries” OpenJDK is a source code project that has no official binaries. Instead, there are several binary distributions of various versions of OpenJDK available from multiple sources. And, of course, one can build their own directly from the released sources. OpenJDK distributions are available from e.g. Azul, Amazon, Red Hat, Adopt, SAP, Bellsoft, Alibaba, and Oracle, and none of them are “official OpenJDK binaries”. The different distributions make different choices about which versions they build and make available (e.g. across the current spectrum of 7, 8,9,10,11,12,13,14-ea,15-ea), where and how long those binaries remain available, etc. They make different curation choices about contents, packaging, and features (e.g. JDK? JRE? Include FX libraries, or not? Fonts? Certificates? Crypto libraries and algos? Linux? Alpine? Windows? MacOS?). The menu is large, there are lots of good choices, but none are “the official OpenJDK” anything...

2. They not the RedHat OpenJDK builds Red Hat has a distribution of OpenJDK, but the binaries the above api refers to are not the RedHat OpenJDK distribution binaries. They are OpenJDK 8u and 11u upstream project builds built by the project leads of 8u and 11u using Red Hat infrastructure. The Red Hat OpenJDK builds are at e.g. https://developers.redhat.com/products/openjdk/download for Windows and available in RHEL repos for RHEL. Those Red Hat builds differ in several material ways from the project leads’ direct builds of the upstream project sources. Differences have included e.g. “Elliptic Crypto implementation in RH OpenJDK 8 includes only 3 most popular elliptic curves - NIST P-256, NIST P-384 and NIST P-521.”, differences in available fonts, differences in timezone data. differences in Garbage Collector options and settings, etc.

[kwin]

Sorry, but I beg to differ: https://adoptopenjdk.net/upstream.html. The AdoptOpenJdk API really optionally distributes the official RedHat Open JDK Update builds (for Java8 and Java11!). And as RedHat took over ownership of the Java8 and Java11 updates you can refer to those as the official ones I guess (https://www.redhat.com/en/about/press-releases/leadership-openjdk-8-and-openjdk-11-transitions-red-hat).

[giltene]

And as RedHat took over ownership of the Java8 and Java11 updates you can refer to those as the official ones

Let us be VERY clear: Red Hat has no ownership of the Java 8 and Java 11 updates. That never happened. Red Hat themselves never said that. And saying that would be (and is) highly offensive to the multitude of contributors working on those projects.

Red Hat contributes significantly to those projects, along with several others (most of the distros mentioned above do significant upstream contributions and work together in the collaborative community projects that are 8u and 11u). The very well respected individual who is the project lead for 8u and 11u happens to be a Red Hat employee. Several other Red Hat employees participate in those projects as well, as do employees of several other companies, and as do other individuals. Red Hat per se has no official capacity in those projects.

The link you point to literally says “...binaries are built by Red Hat on their infrastructure on behalf of the OpenJDK jdk8u and jdk11u projects”. Red Hat kindly provided infrastructure for producing those builds. The signatures on those builds are the project lead’s (not Red Hat’s), and as I note, the binaries Red Hat actually ship as their OpenJDK distribution are dramatically different from the ones you will find at that link (download and compare for yourself).

[fniephaus]

RE naming schemes for distros: Why not follow SDKMAN!'s naming conventions (see https://sdkman.io/jdks)? Maybe it even makes sense to use SDKMAN! as part of this action?

[giltene]

The current SDKMAN naming convention places the java version part and the distro name shorthand (zulu, sapmchn, librca, amzn, adpt, ...) in a single version spec. This has multiple downsides. The shorthand unnecessarily obfuscates the names of some distros. In addition, it does not currently include some distros (e.g. Red Hat, Dragonwell).

Having a separate “distro” field that lets you spell out the distro name fully is cleaner, and let’s the java version be specified in a common way across distros.

As to using SDKMAN directly: it’s a good project, but it is missing a whole bunch of versions in the current spectrum (6,7,8,9,10,11,12,13,14,15-ea) of possible versions that people actually test against. It also lags sometimes in getting updates into its database (e.g. on quarterly releases) because it’s database needs to be updated ( to my understanding, it doesn’t currently scrape CDNs or use REST APIs in the various distros to look up versions).

IMO, If/as we add distro options, we should have logic to find the requested versions directly in each distro’s CDN or other mechanism (REST API, scraping GitHub releases, whatever, they vary by distro) so that once a version is posted by a distro, it is immediately available for use without waiting for an intermediary action by a 3rd party. This becomes especially important 4 times a year when security updates are posted, as CI testing is often the long pole in adopting the new versions.

In addition, the ability to locate things in a “stable” fashion Is critical for CI. I.e. the ability to still able to locate the same thing (without changing the workflow file) N months or years from now, so that everyone’s CI won’t suddenly break when e.g. OpenJDK 14 is EOL’ed and moved from a “current” location to an archive location (this has actually happened to Travis CI for both Java 9 and java 10, and turned lots of tests red all over GitHub). This requires either a stable CDN (has a policy of not removing old stuff) or a stable API (that knows where to find something it found in the past, even if it moved), or some preemptive coordination with the action code here ahead of moving bits that had been previously accessible..

[msgilligan]

I would like to see GraalVM in the list. it's becoming an important use/test case.

[gdams]

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)

@giltene I'd be happy to work with you this solution. I do feel that making Zulu default on here wouldn't make sense though. As mentioned by previous people this action shouldn't endorse one vendor over another. My proposal would be to use the openjdk binaries built by Red Hat as the default (purely because they reference implementation builds and contain no vendor-specific patches).

We should then offer Zulu, adopt, GraalVM and whoever else wants to add their distribution.

How does that sound to you?

[giltene]

I do feel that making Zulu default on here wouldn't make sense though. As mentioned by previous people this action shouldn't endorse one vendor over another. My proposal would be to use the openjdk binaries built by Red Hat as the default

??

[See earlier comments about the relationship between binary builds of OpenJDK and the source code in the OpenJDK project. OpenJDK holds and maintains source code projects, it does not hold or build updated JDK binaries.]

All JDK binaries are a distro of some sort, built and hosted outside of OpenJDK. If you really want to use the term “vendor” when referring to one the longest standing free community builds available under the same permissive OpenJDK license, then keep in mind that all JDK binaries build from OpenJDK sources are “vendors binaries”.

Unfortunately, a default has to choose one binary distro over others, leaving the others as possible options. And all the binary distros (Zulu builds, Red Hat builds, the five+ others I mention earlier in this thread, and probably others too) are possible choices for a default. We can discuss the merits of each and suggest a change to the default, I guess, but you’d probably need to make a stronger argument than “I prefer vendor X over vendor Y for the Linux versions of OpenJDK >=8.0.232 and OpenJDK >=11.0.3”. And at the very least, we’d need to make sure a change won’t break any of the thousands of CI tests that already use existing versions.

The current default (Zulu) has consistently provided free and stable builds and updates of OpenJDK 6,7,8,9,10,11,12,13.14, and 15-EA at a consistent location over a period of ~7 years now. AFAIK it is the only place that consistently holds a wide range OpenJDK builds over time. I don’t currently know of anywhere else where you can pick up 8.0.144, 9.0.4, 10.0.2, 11.0.1, 12.0.2, 7.0.262, 8.0.252, 11.0.7, 13.0.3, 14.0.1, and 15.0.0-ea.21 , for Linux, Windows, and MacOS at one place. Do you?

[gdams]

@giltene what I am referring to is the fact that Red Hat provides those builds with no additional patches (a pure reference implementation build). I am not putting a personal preference on one vendor here (JDK14 binaries should come from http://jdk.java.net/14/) (JDK13 should come from Azul if the plan to support it as a mid-term release).

Plenty of surveys have shown that Zulu is far from no.1 in the OpenJDK ecosystem for developers (it has its place but I don't personally believe it should be served up by default).

[giltene]

@giltene what I am referring to is the fact that Red Hat provides those builds with no additional patches (a pure reference implementation build).

As noted earlier, those few builds only cover a tiny part of the version, platform, and package type spectrum used by setup-java users. They are far from being the commonly used thing, and certainly not enough to cover current CI uses.

I am not putting a personal preference on one vendor here (JDK14 binaries should come from http://jdk.java.net/14/)

That would be “nice”, except that doing exactly that with the default for 9 and 10 in the past broke tons of Travis CI builds when the binaries were removed from their original,location at the end of the 6 month period (see e.g. https://github.com/travis-ci/travis-ci/issues/8608) This is why the default install JDK for Travis used to support testing on 9 and 10 by default, and had to stop.

Zulu binaries consistently stay where they are (and have for years), specifically to make sure stable CI tests and various scripts or tools (like Jabba) that somehow evolved by scraping directory indexes or hard coding urls don’t break. It’s why the Zulu team takes care to populate the CDN even during the “overlap with Oracle-OpenJDK 6 months of builds” period and even for EA builds, in a consistent auto-discoverable manner, so that there will not be a need to change the default distro selection based on version, or edit action code when new versions come out.

Plenty of surveys have shown that Zulu is far from no.1 in the OpenJDK ecosystem for developers

And plenty of surveys show the opposite... Many people don’t even realize that Zulu is the OpenJDK distro they use. They just say “OpenJDK”. And that’s fine. We’re all OpenJDK...

(it has its place but I don't personally believe it should be served up by default).

I can understand why, as the TSC chair for AdoptOpenJDK, you may feel this way. And you can probably understand why I (and many others) may feel differently. It’s good that we can work together here and elsewhere to support options for multiple distros and provide people with choice. I see no need or benefit in attacking other OpenJDK distros.

The Zulu team has worked hard to provide a consistent and reliably delivered set of free, 100% OSS binaries for CI systems for many years now (since long before some of the other distros have started, many with our mentorship and help). It has worked hard to keep actions/setup-java working and to work around issues in the past (e.g. by adjusting CDN contents to make version choices match code assumptions until the code could be fixed). If you can point to an alternative, better place to get the full currently-available spectrum of OpenJDK 6,7,8,9,20,11,12,13,14,15-EA builds (and their history) we can have that argument. But until then, changing the default distro choice implicitly by version (to cover missing parts of the spectrum) seems pointless when there is a place dedicated and committed to reliably delivering all of them, to watching and keeping setup-java working, and has a solid track record of actually doing so.

[kwin]

IMHO neither the CTO of Azul (https://www.linkedin.com/in/giltene/) nor the chair of TSC for Adopt (https://www.linkedin.com/in/gdams) should decide on the default. The default should be chosen by someone from Github (owning/maintaining this action) or there should be no default at all (i.e. every consumer always has to specify a distro/vendor).

[karianna]

@kwin - I'm associated with AdoptOpenJDK as well. This is a challenging one for sure :-). I'll add that from my personal perspective that in an ideal world, the Reference Implementation (RI) binaries would be used (note, that's not the adopt ones).

• For Java 6 and 7 that would be the RI binaries which happen to be built by Azul today
• For Java 8 and 11 that would be the RI binaries built by Red Hat today
• For Java 9, 10 and 12-14 that would be the RI binaries built by Java 14 built by Oracle today

I understand there was an issue with the 9 and 10 binaries being moved, but I think we could talk to Oracle about that and get them to add an API (much like Adopt and Azul have today) and/or commit to not moving them in the future. Alternatively, Adopt would be happy to extend its API to surface the RI builds no matter which vendor was building those at the time. We do this already for Java 8 and 11 (the RI builds which happen to be by Red Hat today).

[sormuras]

[...] talk to Oracle about that and get them to add an API (much like Adopt and Azul have today) and/or commit to not moving them in the future.

Tried to trigger something similar two years ago: https://mail.openjdk.java.net/pipermail/web-discuss/2018-May/000533.html

/cc @robilad

[carimura]

@karianna @sormuras -- I'll [re]open the discussion at Oracle.

[joschi]

IMO, If/as we add distro options, we should have logic to find the requested versions directly in each distro’s CDN or other mechanism (REST API, scraping GitHub releases, whatever, they vary by distro) so that once a version is posted by a distro, it is immediately available for use without waiting for an intermediary action by a 3rd party. This becomes especially important 4 times a year when security updates are posted, as CI testing is often the long pole in adopting the new versions.

We should then offer Zulu, adopt, GraalVM and whoever else wants to add their distribution.

I'll just leave this here:

https://github.com/joschi/java-metadata/#readme https://joschi.github.io/java-metadata/

[giltene]

... I'll just leave this here:

https://github.com/joschi/java-metadata/#readme https://joschi.github.io/java-metadata/

@joschi that is really cool!

[giltene]

@karianna The RI is not the latest update of an OpenJDK updates project build by someone downstream or (sometimes) by a project lead. There is only one Reference Implementation (RI) for each Java version, and it is a frozen in time thing. It serves as a golden build to do comparative TCK testing against and to use for reference purposes when building other implementations of the same spec. Generally, the RI will only rev when there is a JSR rev with e.g. a spec change. RIs are (since Java SE 7) based on a specific update version of OpenJDK (usually the first GA versions, but sometimes a later update when the spec is rev'd).

For obvious reasons, people generally would not seek to run on the RI in production (and usually not in CI), because it is by definition stale and full of already fixed bugs.

Specifically: The RI for Java SE 8 is 8u41, 8u is currently at 8u252. The RI for Java SE 11 is 11, 11u is currently at 11.0.7 The RI for Java SE 13 is 13, 13u is currently at 13.0.3

Each OpenJDK update project produces source code releases on a regular basis (usually at least once per quarter). The projects do not produce official update binaries. Binaries are all downstream things. There are many distros that build those binaries, and none of them hold any special status.

For convenience, some project leads will at times build binaries from project sources and post about them, but those binaries are in no way meant to convey any special status. The words "official", "reference", "blessed", etc. are carefully and intentionally avoided, as using those terms would work strongly against the very purpose of the projects (which is to act as a common place for all distros to collaborate, coordinate, and contribute to a common upstream code base).

[karianna]

@karianna The RI is not the latest update of an OpenJDK updates project build by someone downstream or (sometimes) by a project lead. There is only one Reference Implementation (RI) for each Java version, and it is a frozen in time thing. It serves as a golden build to do comparative TCK testing against and to use for reference purposes when building other implementations of the same spec. Generally, the RI will only rev when there is a JSR rev with e.g. a spec change. RIs are (since Java SE 7) based on a specific update version of OpenJDK (usually the first GA versions, but sometimes a later update when the spec is rev'd).

For obvious reasons, people generally would not seek to run on the RI in production (and usually not in CI), because it is by definition stale and full of already fixed bugs.

Specifically: The RI for Java SE 8 is 8u41, 8u is currently at 8u252. The RI for Java SE 11 is 11, 11u is currently at 11.0.7 The RI for Java SE 13 is 13, 13u is currently at 13.0.3

Each OpenJDK update project produces source code releases on a regular basis (usually at least once per quarter). The projects do not produce official update binaries. Binaries are all downstream things. There are many distros that build those binaries, and none of them hold any special status.

For convenience, some project leads will at times build binaries from project sources and post about them, but those binaries are in no way meant to convey any special status. The words "official", "reference", "blessed", etc. are carefully and intentionally avoided, as using those terms would work strongly against the very purpose of the projects (which is to act as a common place for all distros to collaborate, coordinate, and contribute to a common upstream code base).

Reference Implementation was indeed a poor choice. In that case, I wonder if the most vendor-neutral binaries should be chosen as the default, or no default chosen at all.

[brunoborges]

IMO, there shouldn't be a default in the action. This action aims at helping developers both when using the GitHub Hosted Virtual Environments as well as user-hosted environments.

Because of the dual use case, it would not make sense to force a developer to unknowingly using a JDK on their private/on-prem/custom environment without knowing who's vendor is.

And therefore, in my opinion the user should be forced to define both a version and a distribution. No default should be provided, and I do believe that two parameters are not that hard to fill in :-)

[gdams]

IMO, there shouldn't be a default in the action. This action aims at helping developers both when using the GitHub Hosted Virtual Environments as well as user-hosted environments.

@brunoborges I agree that this is the ideal setup but that would be considered a breaking change, I don't know how many people are using this action but I imagine it's a pretty large number!

[ibauersachs]

Well, this action in its current form just became useless for me. When running ubuntu-latest and requesting Java 8 or 11 I definitely don't expect getting a Zulu JDK, but the packages provided by Ubuntu. As a random developer I now consider Zulu the worst choice here because it obviously differs to other OpenJDK builds by backporting features, not just bugfixes. Having e.g. additional cryptographic primitives available that would otherwise only be present on newer JDKs is causing harm and not good. I'm not even able to just look at the source to verify that. Needing to send an e-mail to request it is so 1990.

(I don't get why there have to be so many differing builds. The accusations by an Oracle employee that IBM secretly took over Adopt and hides behind Eclipse, Amazon doing its thing, Azul another and claiming its the best, Red Hat something else. It's just childish. The discussion above proves it.)

[brunoborges]

Hi @ibauersachs, what exactly got backported by Azul Systems in their JDK 8 build that ended up breaking your build?

[giltene]

@ibauersachs unfortunately, while a common denominator set exists, the full set of crypto primitives supported by a specific update and variant of 8u can vary over time, and across distros during times of flux. E.g. the Red Hat builds of OpenJDK have differed in their set of supported elliptic curves for years.

While various (most?) builds will seek to align on the set of crypto primitives supported, flux does exist when the actual spec changes, and there is a current flux across 8u252, 8u262, and 8u272 (for both Oracle 8 and OpenJDK 8 builds) with added crypto-related changes driven by the actual Java SE 8 spec changes approved earlier this year (https://jcp.org/en/jsr/detail?id=337 , https://jcp.org/aboutJava/communityprocess/mrel/jsr337/index3.html) aimed in part (and mostly?) to facilitate the eventual addition of TLS 1.3 support to 8u. Additional crypto primitives have been added subsequently in various 8u updates in preparation for that step, and more changes are coming in 8u262 and 8u272.

These differences and current flux will hopefully settle by 8u272, with TLS 1.3 support included across all 8u variants by then. Until then, you may find some builds lagging others. E.g. Oracle 8u262 may add some things earlier than some OpenJDK 8u builds will, leaving you with no "one precise set" that all 8u builds support. At least for a while. A common denominator exists, but assuming that all builds have the same precise set is not a safe assumption, and never was.

Note that all these 8u builds [presumably] still strictly adhere to the same Java SE 8 spec, and that while a common denominator of supported primitives may be expected, the spec intentionally does not limit the set of crypto primitives, precisely in order to allow existing spec'ed Java versions to adapt their set of built-in or pluggable primitives to follow the evolving security landscape, as is happening right now.

[martin-g]

It is not just about crypto. Few months ago I had a problem with the time zones. A fix in Java 13 related to parsing a date changed the timezone from UCT to UTC. Then soon after Azul backported this fix in their Java 11 line and caused us problems.

[ibauersachs]

@brunoborges The build was not broken, it passed when it shouldn't have. The signature type NONEwithDSAinP1363Format is available in Zulu, but not in jdk8u. And jdk8u is what Debian etc. ship, so I expect using/requesting this algorithm to fail on a GitHub-installed Java 8 build.

@giltene This is not about TLS 1.3 and new algorithms introduced for it. If a crypto algorithm (or anything else for that matter) is not in the jdk8u repository (see this jdk8u search vs. jdk11u search), it should not be available in a GitHub provided action. I know that an algorithm might be available somewhere, or in newer versions, or in a JRE config that has BouncyCastle available by default, and that is fine. However, I need to be able to test against the lowest common base, and that is plain jdk8u, like building it myself by cloning the Mercurial repo(s), or using a JRE provided by e.g. AdoptOpenJDK or Debian.