Temurin 21.0.6+7.0.LTS does not satisfy 21.0.6+7

[simon-jobrad]

Description:
The JDK download fails for the current LTS release if the build number is specified, but not completely provided. For the current LTS release, 21.0.6+7 does not work: One has to specify the full build number, which is 21.0.6+7.0.LTS.
This is especially annoying (and not this great project's fault) because all other releases follow the simple scheme with an integer build number, also Temurin's Docker image tags do.

Task version:
4.7.1

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:

1. Create a file .java-version with content:

   temurin-21.0.6+7
   

2. Configure a job with the following step:

   - name: Setup JDK
     uses: actions/setup-java@v4.7.1
     with:
       distribution: 'temurin'
       java-version-file: .java-version
   

Expected behavior:
The most recent available distribution of JDK 21.0.6+7 is found and used, which is 21.0.6+7.0.LTS.

Actual behavior:
The action fails with

Trying to resolve the latest version from remote
  Error: Could not find satisfied version for SemVer '21.0.6+7'. 
  Available versions: 24.0.1+9, 24.0.0+36, 23.0.2+7, 23.0.1+11, 23.0.0+37, 22.0.2+9, 22.0.1+8, 22.0.0+36, 21.0.7+6.0.LTS, 21.0.6+7.0.LTS, 21.0.5+11.0.LTS, 21.0.4+7.0.LTS, 21.0.3+9.0.LTS, 21.0.2+13.0.LTS, 21.0.1+12.0.LTS, 21.0.0+35.0.LTS, 20.0.2+9, 20.0.1+9, 20.0.0+36, 19.0.2+7, 19.0.1+10, 19.0.0+36, 18.0.2+101, 18.0.2+9, 18.0.1+10, 18.0.0+36, 17.0.15+6, 17.0.14+7, 17.0.13+11, 17.0.12+7, 17.0.11+9, 17.0.10+7, 17.0.9+9, 17.0.8+101, 17.0.8+7, 17.0.7+7, 17.0.6+10, 17.0.5+8, 17.0.4+101, 17.0.4+8, 17.0.3+7, 17.0.2+8, 17.0.1+12, 17.0.0+35, 16.0.2+7, 11.0.27+6, 11.0.26+4, 11.0.25+9, 11.0.24+8, 11.0.23+9, 11.0.22+7, 11.0.21+9, 11.0.20+101, 11.0.20+8, 11.0.19+7, 11.0.18+10, 11.0.17+8, 11.0.16+101, 11.0.16+8, 11.0.15+10, 11.0.14+101, 11.0.14+9, 11.0.13+8, 11.0.12+7, 8.0.452+9, 8.0.442+6, 8.0.432+6, 8.0.422+5, 8.0.412+8, 8.0.402+6, 8.0.392+8, 8.0.382+5, 8.0.372+7, 8.0.362+9, 8.0.352+8, 8.0.345+1, 8.0.342+7, 8.0.332+9, 8.0.322+6, 8.0.312+7, 8.0.302+8

[mahabaleshwars]

Hi @simon-jobrad,
Thank you for creating this issue. We will investigate it and provide feedback as soon as we have some updates.

[gowridurgad]

Hi @simon-jobrad, Thanks for reporting this! Let us clarify the situation for you.
JDK 21 is an LTS release, as indicated on the official Adoptium site. Since it's an LTS release, Adoptium appends .LTS to the full version string. This behavior can also be observed in their API.
The available version is 21.0.6+7.0.LTS, not 21.0.6+7. Because of this, setup-java cannot resolve the partial version string. It strictly matches the versions provided by the Adoptium API, and the .LTS suffix is required to identify the correct version. Unfortunately, this means there's nothing that can be changed or fixed on the setup-java side.
To resolve the issue, you’ll need to specify the full version string in your .java-version file as follows:
temurin-21.0.6+7.0.LTS
I hope this helps! If you have any additional questions or need further assistance, feel free to reach out.

[simon-jobrad]

Hi @gowridurgad, thank you for taking the time to investigate my bug report. I was aware of the LTS status of version 21 and also that specifying the full version would allow setup-java to find the download. However, I have a question about this:

The available version is 21.0.6+7.0.LTS, not 21.0.6+7. Because of this, setup-java cannot resolve the partial version string.

Is this really a necessary conclusion?
I have just read through the SemVer specification, and according to it, setup-java seems to act formally correct (since the build number has no precedence). Nevertheless, I would suggest that the build number 21.0.6+7.0.LTS also satisfies 21.0.6+7, for the following reasons:

• The version's self designation seems to be OpenJDK Runtime Environment Temurin-21.0.6+7, according to java -version.
• Temurin's Docker images do also use the short variant of the version.
• Imho it's more intuitive to have the satisfaction logic that applies to the first three identifiers of the version also applied to the identifiers of the build number: 21.0.6+7.0.LTS satisfies 21, 21.0, 21.0.6, why not 21.0.6+7?
• It's more convenient for the user - in our case, in the GH workflow, we need to transform/trim the version in .java-version to be able to get the corresponding Docker image tag.

I would be delighted if you could reconsider.

[gowridurgad]

Hi @simon-jobrad, Thank you for your detailed feedback and suggestions! Currently, setup-java strictly follows the SemVer spec, where build metadata (e.g., +7.0.LTS) does not affect version precedence. This means 21.0.6+7.0.LTS and 21.0.6+7 are treated as distinct versions.
Your suggestion to expand the resolution logic for build metadata is valid and could improve user experience, especially for cases like java -version or Docker tags. However, this change involves certain challenges, particularly around preserving SemVer compliance and ensuring consistent version resolution across tools.
We’ll carefully evaluate these factors and consider improvements based on feasibility and user impact. For now, specifying the full version string remains the most reliable approach. Thanks again for your input. please continue sharing your thoughts!

[simon-jobrad]

Thank you @gowridurgad for the detailed reasoning and for considering this as a potential future improvement.
Keep up the great work! ❤