Use "22" in outputs.version for EA java versions rather than a hashcode

[vlsi]

Currently, outputs.version is somewhat useless since it results in hashcode of the URI:

Run oracle-actions/setup-java@7a0114d66dbd02646abd345c3395b34c148e6126
  with:
    website: jdk.java.net
    release: EA
    version: latest
    install: true
  env:
    ACTIONS_STEP_DEBUG: true
    ACTIONS_RUNNER_DEBUG: true
    TZ: America/New_York
    JAVA_HOME: /home/pgjdbc/actions-runner/_work/_tool/Java_Oracle_jdk/17/aarch6[4](https://github.com/pgjdbc/pgjdbc/actions/runs/7004394931/job/19052049332#step:5:4)
    JAVA_HOME_17_AARCH[6](https://github.com/pgjdbc/pgjdbc/actions/runs/7004394931/job/19052049332#step:5:6)4: /home/pgjdbc/actions-runner/_work/_tool/Java_Oracle_jdk/1[7](https://github.com/pgjdbc/pgjdbc/actions/runs/7004394931/job/19052049332#step:5:7)/aarch64
    JAVA_HOME_17_X64: /home/pgjdbc/actions-runner/_work/_tool/Java_Oracle_jdk/17/aarch64

=>

  Java configuration:
    Distribution: jdkfile
    Version: 1604803799
    Path: /home/pgjdbc/actions-runner/_work/_tool/Java_jdkfile_jdk/1604803799/arm64

I guess the culprit is

setup-java/src/Download.java

Line 329 in afea155

case "HASH_URI" -> Integer.toString(Math.abs(uri.hashCode()));

Note that Math.abs(Integer.MIN_VALUE) yeilds Integer.MIN_VALUE, so you probably do not want using Math.abs for hash codes.

I suggest using a release version instead, so the users could configure release: ea and then use the actual release (e.g. 22, 23, ...) in their build system configurations.

I can't understand how could I use release: ga with the current action.

[vlsi]

It might probably make sense to have two output variables:

• release -- high level release
• version -- detailed version

It probably makes sense to separate ea => 22; ga => 21 from the list of jdk.java.net-uri.properties. In other words, the current implementation does not provide a way to tell which release stands for ea.

For instance:

releases.ga=21
releases.ea=22
releases.jextract=21
releases.valhalla=21

An alternative option would be parsing filenames. For instance, openjdk-20-valhalla+20-75_windows-x64_bin.zip apparently belongs to Java 20.

[sormuras]

The idea behind using the hash was to not mess with other JDKs based on same feature release numbers.

As noted in https://github.com/actions/setup-java#supported-version-syntax it might be possible to use a suffix to have distinct JDK installation, based on 22 for example: 22+${PROJECT-NAME}