Java version `18.0.1.1` not supported as input value

[sormuras]

Description:

As https://github.com/actions/setup-java/blob/main/README.md#supported-version-syntax states:

Supported version syntax
The java-version input supports an exact version or a version range using SemVer notation:

major versions: 8, 11, 16, 17
more specific versions: 17.0, 11.0, 11.0.4, 8.0.232, 8.0.282+8
early access (EA) versions: 15-ea, 15.0.0-ea, 15.0.0-ea.2, 15.0.0+2-ea

This definition and examples seem to support 18.0.1.1 as an exact version or specific version.

Find the representation of a version string for an implementation of the Java SE Platform described as

• $FEATURE.$INTERIM.$UPDATE.$PATCH

here: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/Runtime.Version.html

Task version:
v3

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted (not tested)

Repro steps:
Run a distribution: jdkfile-based installation and pass java-version: 18.0.1.1 input.
See oracle-actions/setup-java#25 for repro steps and details of failing runs.

Expected behavior:
An exact/specific version like 18.0.1.1 is supported.

Actual behavior:

Run actions/setup-java@v3
  with:
    java-version: 18.0.1.1
    distribution: jdkfile
    jdkFile: /home/runner/.oracle-actions/setup-java/3eac1378/openjdk-18.0.1.1_linux-x64_bin.tar.gz
    java-package: jdk
    architecture: x64
    check-latest: false
    ...
Error: The string '18.0.1.1' is not valid SemVer notation for a Java version.

[dmitry-shibanov]

Hello @sormuras. Thank you for your report. The setup-java action uses SemVer notation to specify version, that is why it throws an error for 18.0.1.1 because it's not valid SemVer notation.
Could you please try to specify it as 18.0.1+1 ?

[sormuras]

Could you please try to specify it as 18.0.1+1 ?

Sure. I went with passing 18.0.1 instead of 18.0.1.1 as a workaround.

But, shouldn't an action setting up Java support the version pattern specified and used by Java ?

[mogarohan]

Could you please try to specify it as 18.0.1+1 ?

Sure. I went with passing 18.0.1 instead of 18.0.1.1 as a workaround.

But, shouldn't an action setting up Java support the version pattern specified and used by Java ?

[giltene]

In support of the general need for a "SemVer-like" format here that support more than 3 elements (x.y.z), the Java version format as specified in JEP322 , can generally have 5 positions in addition to a build number x.y.z.w.v+b . Per the JEP322, the first four positions are reserved for $FEATURE.$INTERIM.$UPDATE.$PATCH , while the fifth position is "...reserved for use by downstream consumers of the JDK code base. The fifth element may be used to, e.g., identify implementor-specific patch releases."

The need for more than 3 number fields in in no way hypothetical. It has been used in OpenJDK at least once already, and is likely to be used and needed again. e.g. the OpenJDK 11.0.9 quarterly update was re-released a few weeks into the quarter (with an urgent fix to a production-degrading bug in 11.0.9)m under the version number 11.0.9.1, adhering to the JEP conventions, and making 11.0.9 and 11.0.9.1 two distinct versions that both need to have a way to be specified.

Bottom line: It would be useful to add support for x.y.z.w.v+b as a version specification format, with the w.z parts following the obvious logical extensions to SerVer's rules for x.y.z.

[e-korolevskii]

Hello @sormuras,

We understand how important it is to have a specific version in some cases. Unfortunately all major setup-actions and toolkit use SemVer notation, so it`s not possible now to change the notation to that Java uses.
We will investigate the possibility of adding this feature in the future.