so does homebrew
@shelajev Thanks for submitting the PR to add GraalVM to sdkman. However, when I went about testing it I discovered that your SDK provides the same binary executables as the Java SDK (my bad for not checking first). As a result of this, Java would end up clobbering Graal every time and your executables would never be visible on the shell's path.
As a result, I would like to make a recommendation: as Graal is a drop-in replacement for Java, it would make more sense to add it to the Java candidate on sdkman. In other words, simply provide it as a Java version but with the distinct graalvm qualifier (something like 1.0.0-rc1-graalvm under Java. That means that users could switch between Java and Graal at will.
Does this sound fair to you?
@marc0der, the GraalVM distribution also contains the node and npm executables. Will that result in a conflict with the node.js or the latter is not on the sdkman?
@shelajev we currently don't support native node or npm so this shouldn't pose a problem right now.
If the above is acceptable to you, ping me directly on Gitter if you would like me to set you up with your own credentials for our Vendor API. That will allow you to publish a new version of GraalVM under Java with a simple REST call.
@shelajev I've released 1.0.0-rc-1 as I could no longer hold back the enthusiastic crowds. I've done so under the Java candidate as this does not cause any clashes right now.
I'd still be happy for your team to perform your own releases under the Java candidate going forward though. Let me know your thoughts around this.
@thomaswue, I think we can close this issue. GraalVM CE is available on sdkman. And on jabba as it happens.
Sure. BTW, future releases can be added to sdkman in the same way through PRs on the db migrations project going forward.
Most helpful comment
so does homebrew