EA tag moves [too early] during ramp down phase ... so EA builds no longer validate the next JDK release?

[rbygrave]

3 days ago the EA tag moved from version 23 to 24, noting that JDK 23 is not actually released until Sept 17th - approx 2 months away.

This means that from now until Sept 17 any project building using the EA tag is not actually validating the next JDK to be released which is JDK 23 and still 2 months away (as builds using EA are instead now building against 24-EA).

Q: Is this 2 month gap / window in terms of EA build validating the next released version an issue?

Q: Was the EA tag moved too early to 24-EA meaning that project builds against EA are not actually validating against JDK 23 for the next 2 months until the next release?

Q: Should there be another version tag that is like EA but would not actually change until the actual release date?

[sormuras]

The symbolic EA and GA tag names (read: values for the release input of this action) work as intended: they point to the latest-and-greatest JDK offered by the website selected by the workflow. In case of jdk.java.net this means the versions right next to the colon of the frontpage of https://jdk.java.net/

Ready for use: JDK 22, JavaFX 22, JMC 9
Early access: JDK 24, JDK 23, JavaFX 23, Jextract, Loom, & Valhalla

• 22 for GA
• 24 for EA

[sormuras]

If you want to ensure a specific JDK is used, please specify the feature release number explicitly. Here, this action doesn't make a difference between the status of the JDK. For example, 24 stays 24 - no matter if it is in early-access, rampdown, or general-availability state.

This workflow show-cases how to configure this action "across various well-known JDK version": https://github.com/junit-team/junit5/blob/abf5ac3f2e17911bd932f020d2726b01d3c68a6b/.github/workflows/cross-version.yml#L2

[...]
jobs:
  openjdk:
      matrix:
        jdk: [ 22, 23, 24 ]
    runs-on: ubuntu-latest
    steps:
[...]
      - name: 'Set up JDK ${{ matrix.jdk }}'
        uses: oracle-actions/setup-java@v1
        with:
          website: jdk.java.net
          release: ${{ matrix.jdk }}
          version: latest
[...]

[sormuras]

Q: Should there be another version tag that is like EA but would not actually change until the actual release date?

Suppose there was such a RD tag. What would be its value for when there is no JDK in rampdown phase?

    Last week: EA=23  RD= ?  GA=22
        Today: EA=24  RD=23  GA=22
On 2024-09-17: EA=24  RD= ?  GA=23

If we introduced a RD tag, what about a RC tag for release candidates?

[SentryMan]

What if there was a sort of EA-main tag that tracks the mainline and a regular EA that tracks the mainline until RD and RC.

It would behave like

Last week: EA-main=23  EA=23  GA=22
Today: EA-main=24  EA=23  GA=22
On 2024-09-17: EA-main=24  EA=24  GA=23

If you want to ensure a specific JDK is used, please specify the feature release number explicitly.

We have an action on all our repositories that periodically test with GA/EA versions. It's quite the hassle to change all those repos every time something goes into RD/RC and additionally when that non-LTS version becomes EOL.

We want to be able to automatically test with the current mainline and any JDK that is in RD/RC. In this way, we would be empowered to provide useful feedback during those phases without needing to constantly keep changing every single one of our repositories.

[rbygrave]

If you want to ensure a specific JDK is used, please specify the feature relase number explitely.

Just to add that we just have too many builds/libraries to manually adjust the version for a ramp down phase. That is, all our libraries have their own EA build and so I'm talking probably 25+ builds (avaje libraries and ebean orm libraries). The EA and GA tags in this respect are great, moving these versions ourselves across all our builds isn't actually practical.

So yes I think we are really hoping for another tag that is most of the time the same as EA (so there is probably a lot of overlap there) but then follows the version that is about to be released.

FWIW I personally don't mind if there is "overlap" like EA and EA-main point to the same thing 75% of the time. I'm just aware that all our builds are now in that "gap" and are not actually testing 23 and won't actively be testing 23 until it becomes GA. Having this ~2 month "gap" does not sound right.

Suppose there was such a RD tag. What would be its value for when there is no JDK in rampdown phase?

It would match the EA version. The primary goal is to be actively building and testing against that next version to be released so that matches the EA version up to ramp down and then sticks to the next released version.

what about a RC tag for release candidates?

I think a RC tag is probably what we are looking for.

[rbygrave]

To imagine the ideal scenario, our GitHub workflow EA/GA builds would somehow detect when they are in a ramp down period and now they build against both EA (which is now 24-EA) and the release candidate (which is now 23). So in this period they perform that extra build.

If RC != EA then run a build using the RC.

[sormuras]

Support for R (with: website:'jdk.java.net' release:'R') ...

• ... 22 was added on 2023-06-11 and it is still valid.
• ... 23 was added on 2023-12-08 and it will be valid for almost a year.
• ... 24 was added on 2024-06-08 and it will be valid for over a year.

Those time frames usually span over a year and are large enough to be considered quasi-stable; especially as the JDK project
uses a shorter, namely 6 month, release cadence. Thus, you get what you specify. I hesitate to introduce another symbolic name to this action for a slightly different meaning for "EA" with respect to RD and RC phases; as the backing website dictates the underlying anyway. And it would open the door for adding even more names for other scenarios and combinations: https://www.java.com/releases/fullmatrix/

To imagine the ideal scenario, our GitHub workflow EA/GA builds would somehow [...]

An interesting idea! So, what about setting up custom values for your GitHub workflow matrix like shown above?

For maintaining a few workflow definitions and for use-cases that target specific releases, it's okay to specify hard-coded values:

jobs:
  my-jdk-ea-tests:
      matrix:
        jdk: [ 22, 23, 24 ]

Now replace with [ 22, 23, 24 ] with something like {{ NUMBERS }} and let NUMBERS be either [ 23 ] or [ 23, 24 ] or anything else you want, for example include the latest-and-greatest loom early-access builds via [ 23, 24, loom ].

Get matrix values from an env variable (or an external source such as a file)

[sormuras]

Having said that and looking at the composed keys defined in jdk.java.net-uri.properties ...

#
# Early-Access Releases (Alias)
#
...
23,latest,windows,x64=https://download.java.net/java/early_access/jdk23/26/GPL/openjdk-23-ea+26_windows-x64_bin.zip
...
24,latest,windows,x64=https://download.java.net/java/early_access/jdk24/1/GPL/openjdk-24-ea+1_windows-x64_bin.zip
...
ea,latest,windows,x64=https://download.java.net/java/early_access/jdk24/1/GPL/openjdk-24-ea+1_windows-x64_bin.zip

... I do see a better chance to introduce support for a ea,stable,... combination that would keep pointing to the early-access build in all phases until it goes GA. Any ideas for a better name than "stable"? 🤔

ea,stable,windows,x64=https://download.java.net/java/early_access/jdk23/26/GPL/openjdk-23-ea+26_windows-x64_bin.zip

Usage would look like this:

      - name: 'Set up stable EA JDK'
        uses: oracle-actions/setup-java@v1
        with:
          website: jdk.java.net
          release: ea
          version: stable

[sormuras]

@rbygrave and @SentryMan can you please give version: stable a try?

[rbygrave]

Yes, all working @sormuras - thanks !!

...
- name: Set up Java
  uses: oracle-actions/setup-java@v1
  with:
    website: jdk.java.net
    release: ea
    version: stable
...

  mvn --version
 ...
Java version: 23-ea, vendor: Oracle Corporation, runtime: /opt/hostedtoolcache/Java_jdkfile_jdk/1346531910/x64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "6.5.0-1021-azure", arch: "amd64", family: "unix"