[GR-46219] Remove the GraalVM Updater

[fniephaus]

TL;DR

We plan to remove the GraalVM Updater and provide GraalVM language plugins and other GraalVM extensions in new ways.

Goals

• Installed applications and runtimes are supposed to stay immutable. GraalVM Updater modified the installation, making it hard to work with systems and package managers requiring immutability. We, therefore, will remove GraalVM Updater and find replacements for its use cases with the GraalVM for the JDK 21 release.

• For polyglot embedding, all languages should be usable as Maven dependency.

• Language launcher users should be guided to use standalone distributions instead of using the launchers installed by gu.

All non-language components and their migration:

Component ID	Component Name	How to use in GraalVM for JDK 21+
jipher	Jipher JCE Provider	to be included in Oracle GraalVM (not available in GraalVM CE)
llvm-toolchain	LLVM.org toolchain	Build from source or usable as part of the Ruby standalone
native-image-llvm-backend	Native Image LLVM backend	Build from source
visualvm	VisualVM	GitHub release (VisualVM standalone)

Non-Goals

• Remove any of the components themselves
• Introduce a new component installer or rework gu

[Glavo]

Sounds like good news.

So after completing this change, can you provide an apt/yum repository to provide GraalVM CE/Oracle GraalVM? I think this will be very helpful to users.

[fniephaus]

So after completing this change, can you provide an apt/yum repository to provide GraalVM CE/Oracle GraalVM? I think this will be very helpful to users.

I'm not sure the deprecation of gu is a prerequisite for this, maybe we could provide apt/yum repos sooner.

[Glavo]

I'm not sure the deprecation of gu is a prerequisite for this

I think maybe it is. gu will modify GraalVM itself, which is very unfriendly to the package manager.

[fniephaus]

You could be right, let us check anyway. :)

[rubyFeedback]

(This is just info, in the event it may be useful to the GraalVM devs.)

In the past I used the openjdk download; since perhaps 2 years (or
a bit less than that) I use the GraalVM release as-is, such as here:

https://github.com/graalvm/graalvm-ce-builds/releases

For both linux and windows. Linux is my main dev platform though;
I try to make sure my java and ruby code works on windows.

I avoid all kind of automatic updaters in general, always doing the
manual way of downloading (or downloading via a set of ruby
scripts, e. g. I compile from source and batch-download via these
scripts, e. g. "update kde" to download all new KDE source releases,
then "compile kde" where update and compile point to the .rb file
that handles the compile/install-logic. This is kind of one big reason
why I default to a single downloadable file (perhaps that also provides
a bit more context to my older suggestion for "fat downloads" - I
just find it easier to have everything that is useful for, say, 95% of
the devs or so, available in one place. Since GraalVM seems to work
perfectly fine I kind of replaced openjdk with it, since I also get
native-image with it, which is nifty.)

[ezzarghili]

I'm not sure the deprecation of gu is a prerequisite for this

I think maybe it is. gu will modify GraalVM itself, which is very unfriendly to the package manager.

Yum packages are already available publically for community and we are looking into adding the new Oracle GraalVM too (now available only for customers and OCI users)
i.e https://yum.oracle.com/repo/OracleLinux/OL7/graalvm/community/x86_64/
And in this implementation gu is removed to not impact the package installed with in place updates.