`/disco/v3.0/packages/jdks` endpoint with a specific `jdk_version` and `distribution=mandrel` returns packages that do not match the requested version

[zakkak]

When querying the /disco/v3.0/packages/jdks endpoint with a specific jdk_version, the response
includes packages that do not match the requested version.

curl -s -X 'GET' \
  'https://api.foojay.io/disco/v3.0/packages/jdks?jdk_version=21&distribution=mandrel&architecture=x64&&operating_system=linux&latest=per_distro' \
  -H 'accept: application/json' | jq '.result'

Expected Behavior

All returned packages should have java21 in the filename.

Actual Behavior

DISCO API returns old Mandrel packages versioned 21.x (Mandrel version) that are JDK-11 and JDK-17 based.

Additional info

According to graalvm/setup-graalvm#211 this used to work as expected 3-4 days ago.

[zakkak]

FWIW the implementation in this repo seems to be correct (and it has not changed in the past week), see #148 for a unit test. So I am thinking that this might be related to some database or caching issue irrelevant to the code in this repo.

[turing85]

@zakkak So... what are we going to do about this? We have quite some PRs on quarkus-artemis that are waiting to be merged. And I am not sure if upgrading to JDK 25 is feasible since we also need to build for older LTS-versions (based on quarkus 3.20 and 3.27).

[zakkak]

@turing85 I suggest using something like the following as a workaround till this gets fixed.

- name: Set up GraalVM 21
  uses: graalvm/setup-graalvm@v1
  with:
    distribution: 'mandrel'
    version: 'mandrel-23.1.10.0-Final'
    java-version: 23
    github-token: ${{ secrets.GITHUB_TOKEN }}

Important

note that java-version is set to 23 to work-around the issue and it will break once the issue gets resolved which will prompt you to revert the change.

The following seems to do the trick as well but is a bit more "risky" as it might not break once the issue gets resolved:

- name: Set up GraalVM 21
  uses: graalvm/setup-graalvm@v1
  with:
    distribution: 'mandrel'
    version: 'latest'
    java-version: 23
    github-token: ${{ secrets.GITHUB_TOKEN }}

Another approach would be to use the quarkus builder image instead of a local installation (but I suspect you have a good reason you don't).

[turing85]

Hm... I'll give building native images in a container a shot.

[turing85]

Okay, quarkus-artemis moved away from graalvm/setup-graalvm and uses container build for native instead.

[xzel23]

Just stumbled over a similar issue. Querying JDK version 25 returns JDKs with version 26.

Query: https://api.foojay.io/disco/v3.0/packages?package_type=jdk&directly_downloadable=true&archive_type=tar.gz&archive_type=tgz&archive_type=zip&release_status=ga&free_to_use_in_production=true&jdk_version=25.*&operating_system=macos&architecture=aarch64&architecture=arm64&javafx_bundled=true

The returned JDKs range from version8 to 26.

[HanSolo]

Because you used jdk_version=25.* which is not supported, if you select jdk_version=25 instead it will only show you 25. There is also no need to select architecture=aarch64 and architecture=arm64 which will both lead to the same result.

[xzel23]

Ah, my bad. I have "verschlimmbessert" (fixed until broken) my plugin. Sorry for the false report.

[zakkak]

@HanSolo this is still an issue. Do you have any pointers regarding where to look at for fixing it?

[HanSolo]

This needs more work because the problem seems to be a parsing problem, the version number in the filename says 21.3.6.0 which is the one that was parsed but in the beginning of the filename it says java11 or java17. This again is the problem with the graalvm versioning (which btw will change again to a custom scheme). This makes it not easy to parse these numbers, e.g. which java11 or java17 version do we have here??? I really need to think about that and keep in mind that there also is GraalVM community, GraalVM and Liberica NIK which might need different ways to figure out the versioning. Sorry for the inconvenience but I will definitely take a look at it.

[zakkak]

Yes, it's not trivial due to the multiple versioning scheme changes in the upstream project.

What surprised me is that it used to work fine and then it stopped. To my understanding https://github.com/foojayio/discoapi/blob/main/src/main/java/io/foojay/api/distribution/Mandrel.java is responsible for parsing the Mandrel versions and it had not been touched for 3 years, which makes me wonder what caused the issue.

FWIW I added some unit tests for Mandrel and they seem to confirm that the parsing works as expected (at least for Mandrel).

Is there any other place this issue might be coming from?

Thanks for looking into it.