Repository navigation
Java version 18.0.1.1 not supported as input value #326
Description
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.
Activity
dmitry-shibanov commentedon May 5, 2022
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 commentedon May 9, 2022
Sure. I went with passing
18.0.1instead of18.0.1.1as a workaround.But, shouldn't an action setting up Java support the version pattern specified and used by Java ?
mogarohan commentedon May 28, 2022
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 commentedon May 30, 2022
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 commentedon Jun 1, 2022
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.
Reduce Java version to x.y.z due to actions/setup-java#326
Support multi-field Java versions like 18.0.1.1 (actions#1092)