[Request] New Oracle GraalVM and GraalVM Community for JDK 17.0.7 and JDK 20.0.1 about java HOT 21 OPEN

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

from java.

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.

from java.

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

from java.

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

from java.

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

from java.

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

You can use APIs

from java.

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.

from java.

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

from java.

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)

from java.

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.

from java.

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

from java.

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

from java.

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.

from java.

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.

from java.

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

from java.

@Small-Ku, I use scoop, but have never looked into how packages work, so I might be out to lunch here... but...

If the extract_dir is not predictable/described, maybe just extract the entire thing and then perhaps do some extra work under installer -> script? Would something like that work?

from java.

It works, but one of the criteria to be in the Java bucket is:

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

from java.

Ah... @Small-Ku, interesting. Sounds like a reasonable rule/goal in general.

I think the nature of the GraalVM distributions means we need a lil' something to help. And we could propose that:

1. we aren't adding pre_install or post_install scripts (I think?)
2. our installer->script would not be "elaborate", it would be "fairly standard".

Would that do the trick?
Who would we appeal to?

from java.

@Small-Ku
新的 CE 版本似乎不再使用calendar year作为版本号的一部分。

https://www.graalvm.org/release-calendar/
Starting in 2023, GraalVM Community Edition will align with the six-month JDK release cadence. There will be two feature releases per year to support the latest JDK version. A new feature release supersedes all previous releases. GraalVM releases are named for the JDK release they provide, for example, GraalVM for JDK 17.

新的版本号规则应该确定下来了。原本的Github链接稍加修改应该可以使用。可以查看一下tags
https://github.com/graalvm/graalvm-ce-builds/tags
（如果没有看错的话仍然是CE的许可证）

from java.

Sorry for being late to this conversation. I will review and accept the PR if someone creates it with the following content:

1. Manifests with naming from #472 (comment)
2. Elaborate install script, for example:

   Java/bucket/microsoft17-jdk.json

   Lines 17 to 22 in d221270

   	"installer": {
   	"script": [
   	"(Get-ChildItem -Directory \"$dir\\tmp\").FullName | % { Move-Item \"$_\\*\" \"$dir\" }",
   	"Remove-Item -Recurse \"$dir\\tmp\""
   	]
   	},

3. Checkver should not be from any third party repository. Please find a parseable source. You can also use an elaborate approach for the checkver, like in

   Java/bucket/oraclejre8.json

   Lines 22 to 32 in d221270

   	"url": "https://orasites-prodapp.cec.ocp.oraclecloud.com/content/published/api/v1.1/items/COREFA37E773006D4BE183DB8D7F504C5718?channelToken=1f7d2611846d4457b213dfc9048724dc",
   	"script": [
   	"$ver = json_path $page $.fields.json.latest8Version",
   	"$secid = json_path $page $.fields.json.secID",
   	"$win32 = [int](json_path $page $.fields.json.win_offline_bundle) + 1",
   	"$win64 = [int](json_path $page $.fields.json.win_x64_bundle) + 1",
   	"Write-Output \"$ver $win32 $win64 $secid\""
   	],
   	"regex": "(?<long>(?<ver>[\\d.]+)_(?<build>[\\d]+)) (?<win32b>[\\d]+) (?<win64b>[\\d]+) (?<secid>[\\da-f]{32})",
   	"replace": "8u${build}"
   	},

Thanks for the contributions. Please write in the PR your design decisions, for later changes to the manifest.

from java.