https://blogs.oracle.com/java/post/detaching-graalvm-from-the-java-ecosystem-train > • GraalVM Early Adopter technology, including Native Image, is being discontinued for Java SE Product customers. The goals of improving the startup time, time to peak performance, and footprint of Java programs are being pursued further in OpenJDK’s Project Leyden as a standard part of Java. Customers seeking more information should reach out to https://www.oracle.com/support/. This seems bad, right?
In 2022 GraalVM aligned with OpenJDK cadence, I think now they are just going to undo this. I don't think native-image is going away. There will be a stream from GraalVM today on their new release. Oracle GraalVM has been available as a separate download. I didn't even know it had something to do with Java SE, perhaps via a support contract or so
I'll ask in the native image channel on their slack to confirm
https://graalvm.slack.com/archives/CN9KSFB40/p1758026217029569
https://www.reddit.com/r/java/comments/1niamuc/detaching_graalvm_from_the_java_ecosystem_train/
> The quoted message is from the Java team (which the GraalVM team is not part of), that they will discontinue the Graal JIT that was part of OracleJDK. If you were using this setup, you need to switch to GraalVM now. > It does not affect our GraalVM releases; we will continue to work on GraalVM JIT, Native Image, and Languages. We will evaluate how to improve our releases to serve our users and their use cases best.
(from a GraalVM team member)
Yeah reading the post it sounds like this is undoing a small change to releases made in 2022/2023.
And in the slightly bigger picture, if project leyden is eventually capable of delivering startup performance that rivals native image, maybe while relaxing some of the constraints around reflection/dynamics, that might also make JVM clojure more viable as a target for short-lived 'scripts' where startup currently dominates runtime.
I don't think that's realistically where Leyden is going from anything I've seen
Seems like maybe OracleJDK included GraalJIT as an option inside itself. Not something the OpenJDK offered. And that's being removed. But doesn't look like GraalVM is impacted.
I'm actually more concerned by the first bullet point in that blog: > The GraalVM team are transitioning to focus on non-Java Graal Languages including GraalPy and GraalJS. Details are expected to be announced later.
Please respond in thread. From the reactions you can see there is nothing to worry about.
I did read the other thread, and did consider posting there, but this felt sufficiently different. The other thread is focused on the fact that that bullet does not mean GraalVM itself is discontinued, and instead just means it's no longer part of the "Java SE Product". I didn't see anything in that thread that addressed this bullet point.
I did ask about your point in the GraalVM slack now too, so if you're interested you could look there for the reply
Thanks!
is there an option for piping clojure code to bb to get the result back? echo '(+ 1 2)' | bb almost worked but it printed this:
Babashka v1.3.191 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.
user=> 3
user=>I was using this from vim to replace my current text selection with its evaluated result, :'<,'>!bb
You can use -e + load-string
+ slurp on in
So
echo '(+ 1 2)' | bb -e '(load-string (slurp *in*))'TIL about load-string (which I guess is just (comp eval read-string)?)
great, I just saved bb -e '(load-string (slurp *in*))' to ~/bin/bbe. thank you!
looks like load-string does more by reading a sequence of forms instead of just the first one
this would work too, but it doesn’t recognize the function: (load-reader *in*)
Nice didn’t know it existed. Issue welcome
haha, you already added it last month to SCI https://github.com/babashka/sci/commit/927d88071c6dd4a768d7f06bc253e4e3c9cad1b1. just had to download the latest github release and it worked
Oh yes, it sounded familiar, just didn’t remember if I did something at the core or interop level heh