JDK 21 EA API request doesn't return latest build

[jerboaa]

Describe the bug
When I attempt to get the latest nightly, then the API returns a 3-weeks old release. This one:
https://github.com/adoptium/temurin21-binaries/releases/jdk-21.0.1%2B12-ea-beta/

However, there has been newer builds since. For example this one from two days ago:
https://github.com/adoptium/temurin21-binaries/releases/jdk21u-2023-11-08-15-55-beta

To Reproduce
Steps to reproduce the behavior:

$ curl -v https://api.adoptium.net/v3/binary/latest/21/ea/linux/x64/jdk/hotspot/normal/eclipse 2>&1 | grep Location
< Location: https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.1%2B12-ea-beta/OpenJDK21U-jdk_x64_linux_hotspot_ea_21-0-1-12.tar.gz

Expected behavior
Return a redirect to:
https://github.com/adoptium/temurin21-binaries/releases/download/jdk21u-2023-11-08-15-55-beta/OpenJDK21U-jdk_x64_linux_hotspot_2023-11-08-15-55.tar.gz

[jerboaa]

/cc @johnoliver @sxa

[xavierfacq]

Hi,

Meanwhile, I think that you can use the asset search instead: https://api.adoptium.net/q/swagger-ui/#/Assets/searchReleases

curl -X 'GET' \ 'https://api.adoptium.net/v3/assets/feature_releases/21/ea?architecture=x64&heap_size=normal&image_type=jdk&jvm_impl=hotspot&os=linux&page=0&page_size=1&project=jdk&sort_method=DEFAULT&sort_order=DESC&vendor=eclipse' \ -H 'accept: application/json'

Then get the link attribute from the first result.

Hope it helps.

[jerboaa]

Thanks!

While that works, I'm looking for a standard process that will work long-term. My understanding is that we had "fixed" JDK 21 ea releases available through the API prior GA and that is now biting us. So I'm looking for a solution that will work for the "tagged" EA release as well as nightly EA releases. Or at least look for documentation as to how this works. Hope that makes some sense.

[jerboaa]

Perhaps the reason for this behaviour is Oracle still leading that project and no new 21.0.2+<N> tags are available just yet (only after 21.0.2 GA).

[sxa]

Yeah the reason we've enabled regular nightlies is because of the lack of jdk-21.0.2+<N> tags (which would be our preferred mechanism of producing new builds) but something (probably the ordering) means the ea-beta ones are showing up as newer than the nightlies (which would normally be a good thing, but not in this case where we don't have the tags being publicly visible)

[johnoliver]

The issue is that the versions are:

        "version_data": {
            "build": 12,
            "major": 21,
            "minor": 0,
            "openjdk_version": "21.0.1-beta+12-202312271138",
            "optional": "202312271138",
            "pre": "beta",
            "security": 1,
            "semver": "21.0.1-beta+12.0.202312271138"
        }

vs

        "version_data": {
            "build": 12,
            "major": 21,
            "minor": 0,
            "openjdk_version": "21.0.1-beta+12-ea",
            "optional": "ea",
            "pre": "beta",
            "security": 1,
            "semver": "21.0.1-beta+12.0.ea"
    },

sorting will typically put the optional of ea after 202312271138 in the sort order so it will be viewed as more recent, I think the only way to fix this would be to add some sort of special casing to the sort order that puts specifically the optional of ea as lower than numbers, this is somewhat of a special casing that would make sorting rules less intuitive, but not sure there is a better option here unless the version format on EAs is changed

[sxa]

Interesting ... Thanks for the analysis @johnoliver ... In which case the API is doing what I'd expect, but the obvious question is why the latest builds are still identifying themselves as 21.0.1 instead of 21.0.2.
Which is quite probably because the tag is being detected as 21.0.1+12 because that's the latest available and the build scripts don't know any better.
FYI @andrew-m-leonard

[andrew-m-leonard]

@sxa As jdk21u is currently Oracle managed, there are no jdk-21.0.2 tags, and won't be until Oracle publish them all on release day. Hence the most recent tag is "jdk-21.0.1+12"

Hence, why we currently build jdk21u via "HEAD" as a weekend Weekly build.

Once jdk21u is taken over by whichever organization is managing it, and regular builds/tags for the following release appear (jdk-21.0.3+), then it can change to being "tag build driven"

[sxa]

Yep aware of all that - but we really need a solution to let people get the latest nightlies. Perhaps we need to override it to 21.0.2 or something else instead of using the tag in this situation.

[andrew-m-leonard]

So we could achieve that by manually tagging are mirror with something? but we can't chose a tag name that will eventually appear from Oracle (ie.jdk-21.0.2+1/2/3/4)

At the moment the jdk21u repo HEAD is essentially jdk-21.0.2 targeted "public" commits with jdk-21.0.1+12 merged in.

[andrew-m-leonard]

Can't we just wait 2 week?

[sxa]

Oracle (ie.jdk-21.0.2+1/2/3/4)

jdk-21.0.2+0? Gut feel is that it's not ideal to label these nightlies 21.0.1 when they are effectively early builds of 21.0.2.

Can't we just wait 2 week?

We could, but we ought to have some idea of how to handle it in the future. For the evaluation platforms I expect we'll continue to have such a tag that we make available (i.e. jdk-21.0.2+xx-ea-beta, and this problem would block subsequent nightlies from being visible.

[andrew-m-leonard]

jdk-21.0.2+0 already exists, it's actually the old Oracle branch point for jdk-21.0.2, so is quite old

[jerboaa]

The issue is that the versions are:

        "version_data": {
            "build": 12,
            "major": 21,
            "minor": 0,
            "openjdk_version": "21.0.1-beta+12-202312271138",
            "optional": "202312271138",
            "pre": "beta",
            "security": 1,
            "semver": "21.0.1-beta+12.0.202312271138"
        }

vs

        "version_data": {
            "build": 12,
            "major": 21,
            "minor": 0,
            "openjdk_version": "21.0.1-beta+12-ea",
            "optional": "ea",
            "pre": "beta",
            "security": 1,
            "semver": "21.0.1-beta+12.0.ea"
    },

sorting will typically put the optional of ea after 202312271138 in the sort order so it will be viewed as more recent, I think the only way to fix this would be to add some sort of special casing to the sort order that puts specifically the optional of ea as lower than numbers, this is somewhat of a special casing that would make sorting rules less intuitive, but not sure there is a better option here unless the version format on EAs is changed

Would changing optional of 202312271138 to ea_202312271138 for nightly builds work?