Repository navigation
Java version 18.0.1.1 not supported as input value #326
Description
Activity
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 ?Could you please try to specify it as 18.0.1+1 ?
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 ?
Reacted by Rene LeonhardtCould 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 ?
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.
Reacted by Michael Ernst, Klemen, Rene Leonhardt and Christian SteinHello @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.- added a commit that references this issue
on Jul 9, 2026
Description:
As https://github.com/actions/setup-java/blob/main/README.md#supported-version-syntax states:
This definition and examples seem to support
18.0.1.1as 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.$PATCHhere: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/Runtime.Version.html
Task version:
v3Platform:
Runner type:
Repro steps:
Run a
distribution: jdkfile-based installation and passjava-version: 18.0.1.1input.See oracle-actions/setup-java#25 for repro steps and details of failing runs.
Expected behavior:
An exact/specific version like
18.0.1.1is supported.Actual behavior: