[Request] New Oracle GraalVM and GraalVM Community for JDK 17.0.7 and JDK 20.0.1

[azmankudus]

Package Request

Criteria

For a package to be acceptable in the Java bucket, it should be:

• a runtime environment or software development kit for Java
• a reasonably well-known and widely used developer tool (e.g. if it's a GitHub project, it should have at least 500 stars and 150 forks)
• the latest stable version of the program
• the full version i.e. not a trial version
• a fairly standard install (e.g. uses a version-specific download URL, no elaborate pre/post install scripts)
• downloadable without having to sign in or use user-dependant cookies

Information

Name: Oracle GraalVM

Description: GraalVM compiles your Java applications ahead of time into standalone binaries that start instantly, provide peak performance with no warmup, and use fewer resources.

Homepage: https://www.graalvm.org

Download link(s):
https://www.graalvm.org/downloads
https://github.com/graalvm/graalvm-ce-builds/releases/tag/jdk-20.0.1
https://github.com/graalvm/graalvm-ce-builds/releases/tag/jdk-17.0.7

Some indication of popularity/repute: GitHub stars 18.4k

License: GPLv2

[NuclearMissile]

GraalVM CE is already in current scoop https://scoop.sh/#/apps?q=graalvm

The new Oracle GraalVM should be added: https://www.graalvm.org/downloads/# ,maybe it is better to switch to this new build from version graalvm23

[he3als]

The new Oracle GraalVM used to be called GraalVM Enterprise, and it offers much better performance over GraalVM Community Edition.

It should be switched to over CE.

[NuclearMissile]

@he3als I agree, the new Oracle GraalVM includes close-sourced optimizations from graalvm EE and now its version is 23.0.0.

[Small-Ku]

It seems hard to check its version when they only providing a latest URL.

[azmankudus]

It seems hard to check its version when they only providing a latest URL.

Not hard actually as they also release in their ce build github. As i shared the links in my first comment.

Btw, sdkman already release with -graal and -graalce.

sdk install java 20.0.1-graal
sdk install java 17.0.7-graal
sdk install java 20.0.1-graalce
sdk install java 17.0.7-graalce

[he3als]

It seems hard to check its version when they only providing a latest URL.

You can use APIs

[Small-Ku]

I mean that they seems only providing URLs that specify java version of 20/17, but not specify their graalvm version.
The current graalvm in this bucket is checking graalvm version.
If the link is just always like https://download.oracle.com/graalvm/20/latest/graalvm-jdk-20_windows-x64_bin.zip, it seems that it will not work well with scoop with features like cache and hash checking, like when they updated graalvm in the same java version.

[he3als]

You can see how my script does it, not sure if it would work for Scoop or if there's a better option.

https://github.com/he3als/graalvm-downloader

[Small-Ku]

Your script still downloading something this:
https://download.oracle.com/graalvm/20/latest/graalvm-jdk-20_windows-x64_bin.zip
You can't ensure the graalvm you downloaded and checked hash for is the version you checked from the API.

But even their Github Actions is not specifying graalvm version. It seems the only choice currently.
As a result, I think it might not fulfilling this:

• a fairly standard install (e.g. uses a version-specific download URL, no elaborate pre/post install scripts)

[he3als]

To be fair, it's somewhat complex to get the version, and it's not really an API as I just got the link to that JSON for it from the 'Network' tab of the Oracle GraalVM website.

However, it might be possible other ways.

[Small-Ku]

Made some manifests in my own bucket:
https://github.com/Small-Ku/turbo-bucket/blob/442dedecdda3c3fe54efa53f3e536ff2b862347a/bucket/graalvm.json
https://github.com/Small-Ku/turbo-bucket/blob/442dedecdda3c3fe54efa53f3e536ff2b862347a/bucket/graalvm-jdk17.json
It seems Oracle GraalVM is already updated at least once but did not mentioning it in release notes.
In release note: 20.0.1+8
Current: 20.0.1+9.1

[SPC-code]

It seems like Oracle create a page specifically for tools like scoop: https://www.oracle.com/java/technologies/jdk-script-friendly-urls/

[Small-Ku]

It seems like Oracle create a page specifically for tools like scoop: oracle.com/java/technologies/jdk-script-friendly-urls

My manifests actually using it. They still don't have a quick way to check their version updates.

[lread]

This is hinted at in the comments above, but maybe it helps to spell it all out.

It's all a bit confusing because the Graal team changed the versioning scheme on us and made a new variant available.

The versioning scheme is now simply the JDK version.
So we no longer have for example 22.3.1 jdk 17, we just have for example jdk 17.0.8.

And we no longer only have only the Community Edition, we now also have GraalVM Oracle.

For the new versioning scheme, as I think @azmankudus suggested, we might want to follow some sdkman-like scheme.

Maybe graalvm-ce and graalvm-oracle to clearly distinguish the new scheme and variant.

I think we should include both ce and oracle variants because licensing is different for these and maybe folks need to use one over the other for that reason.

So if I understand existing patterns.... maybe?:

Maybe:

• graalvm-ce-jdk latest available community edition
• graalvm-ce-17jdk latest available community edition jdk17
• graalvm-ce-20jdk latest available community edition jdk20
• graalvm-oracle-jdk latest available Oracle graalvm
• graalvm-oracle-17jdk latest available Oracle graalvm jdk17
• graalvm-oracle-20jdk latest available Oracle graalvm jdk20

As for the existing graalvm, these can be used for the legacy versioning scheme if there is an interest/want/need to keep them around. FWIW, sdkman chose not to list these legacy versions.

Let me know what you think of the above, and, if you'd like any help.

BTW, I don't know if the scoop java bucket takes advantage of the disco api at all.
I know that sdkman does so to automate updating its record of java releases.

[Small-Ku]

Seems disco api is nice for checkver, but it is still difficult to auto-update the extract_dir value aside from using a checkver script extracting the zip once since the "+9.1" seems come from nowhere

https://github.com/Small-Ku/turbo-bucket/blob/main/bucket/graalvm-jdk.json
https://github.com/Small-Ku/turbo-bucket/blob/main/bucket/graalvm17-jdk.json
https://github.com/Small-Ku/turbo-bucket/blob/main/bucket/graalvm20-jdk.json