Add *early access* version for eager developers to adopt new Java

[hantsy]

Personally, I hope add openjdk and oracle as alternative providers.

And provide early access build of OpenJDK for eager developers.

Originally posted by @hantsy in #229 (comment)

[giltene]

Early access versions are already available (in distros that provide them) by stating it in the version. E.g. stating 17-ea gets you the latest 17 ea version, and 17.0.0-ea.2 gets you a specific ea version. Per Semver rules, an EA version would only be used if specifically requested (I.e. saying “16” will get you a 16 GA’ed version of a given distro if one is available, but will not give you an EA version..and 16-ea will get you the latest EA version, not the GA versions).

“OpenJDK” is a source code project that feeds into many distributions, it is not a distribution and not a place you get binaries and updated versions of those binaries from on an ongoing basis. Most (currently all) distros you can specify under “distribution” are builds of OpenJDK. (much like Ubuntu, CentOS, RHEL, Fedora, Debian, Alpine, Rocky Linux, AlmaKinux, etc. are linux distributions)

Oracle does make a distro of OpenJDK available on a routine basis. And adding it as a distro option certainly makes sense (just like adding corretto, dragonwell, sapmachine, liberica, Microsoft build of OpenJDK, etc. makes sense). See #69.

A good name for the Oracle distribution of openjdk would probably be oracle-openjdk (to distinguish it from the 9+ other OpenJDK distros). Different distros may cover different versions and update levels, and that covered range and continued availability of binaries and updates may vary (track records, plans, and commitments vary and can change). If/when updates are posted also varies by distro. E.g. Thus far the oracle-openjdk distro’s first available Java version was based on OpenJDK 9, and it has consistently provided two updates (a X.0.1 and a X.0.2) for each Java version “X” since (9,10,11,12,13,14,15,16) in a timely manner. But it also consistently stopped posting binaries after the 2nd update (about 4 months after first GA) for each of those versions, choosing not to continue releasing updates as the various versions in the OpenJDK updates projects keep updating (with bug fixes, security updates, backports, etc.). e.g. at the time of this posting, 11’s current update level in OpenJDK 11u (and available from most distros) is 11.0.12. e.g. the current update level in OpenJDK 8u is 8.0.302. e.g. the current update level in OpenJDK 15u is 15.0.4. At the time of this posting, those are not the update levels currently available in the Oracle OpenJDK distribution.

Separately, there is the Oracle Java distribution (separate from the Oracle OpenJDK distribution). Historically, obtaining the binary for this distribution required some sort of click-through acknowledging the license requirements, and thus far (until yesterday, and since early 2019) those license requirements prohibited e.g. commercial use without a contract that allowed it. But things may have changed yesterday with Oracle’s announcements about Oracle Java 17, which may make e.g. an oracke-java distribution a viable option as well.

[dmitry-shibanov]

Hello @hantsy. Thank you for your report. It looks like we have the similar feature requests about adding Oracle OpenJDK.
Thank you for the fast response @giltene !
For now I'm closing the issue as a duplicate.

[karussell]

Does this still work for the latest 19 ea? We tried 19-ea but it failed with some SunCertPathBuilderException when fetching packages from maven:

Failed to read artifact descriptor for org.codehaus.plexus:plexus-utils:jar:3.0: Could not transfer artifact org.codehaus.plexus:plexus-utils:pom:3.0 from/to central (https://repo.maven.apache.org/maven2): transfer failed for https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.0/plexus-utils-3.0.pom: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

See https://github.com/graphhopper/graphhopper/runs/6172054216?check_suite_focus=true

The JDK 18 in the same job works properly.

[dmitry-shibanov]

Hello @karussell. Thank you for your comment. I think the root cause of the issue is from java itself because the step with installation was without issues.

[karussell]

You mean the 19-ea could have an issue like missing certificates?

But using 19-ea from adoptium.net directly works fine in our case:
https://github.com/graphhopper/graphhopper/blob/47febfc6278e6eebf15f2940e5bac0c77c0034b5/.travis.yml#L28

See the travis build for this case (it uses jdk-19+19) https://app.travis-ci.com/github/graphhopper/graphhopper/jobs/568206333

[dmitry-shibanov]

Could you please try to change maven version to 3.6.3 and disable caching. If it does not help, could you please create a separate issue.

[karussell]

I already disabled the cache for this job (will disable the cache for the other job too). How can I change the maven version? I am using the default of setup-java I think. Or do I have to change runs-on: ubuntu-20.04 for that?

If it does not help, could you please create a separate issue.

Sure, thanks!

[dmitry-shibanov]

I already disabled the cache for this job (will disable the cache for the other job too). How can I change the maven version? I am using the default of setup-java I think. Or do I have to change runs-on: ubuntu-20.04 for that?

If it does not help, could you please create a separate issue.

Sure, thanks!

I think you can try to use this community action to change maven version.