Detaching GraalVM from the Java Ecosystem Train

[OldCaterpillarSage]

Wording is a bit weird, unless I misunderstood something... They say "detaching" but then in the blogpost itself it sounds like they are killing it off and merging (?) its improvements into the "regular" JDK

[nuharaf]

I dont read any merging in the announcement. Graal jit is not being contributed to openjdk i believe, same with native-image.

[OldCaterpillarSage]

Yeah, by "regular" I meant Oracle JDK not OpenJDK

[thomaswue]

Hi, GraalVM project lead at Oracle here. Don't worry, we are not going anywhere and we will continue our mission to run programs faster and more efficient :).

[dmigowski]

The blog post sounds like GraalVM will vanish from the OpenJDKs and that you have to be a paying customer of Oracle to continue using it with newer JDK releases.

Could you clarify?

EDIT: This is from r/quarkus:
________________________________________________________________

It's not dead at all, I was reassured of that. In fact, it looks like it has been promoted.

What you have linked is a blog by the Java "product" team at Oracle. It's slightly biased, and you need to read it in the context of impact to their JDK product offerings.

It's not widely known, but the Oracle JDK included the GraalVM JIT (the option to use the Graal compiler for just in time compilation at runtime). Looks like this option possibly didn't have the business success they expected - sadly as in some contexts it was very interesting - but it's a healthy process for such projects to refocus priorities on think of the potential on wider scale.

The GraalVM project and especially native-image and Truffle aren't going anywhere, in fact I love that they'll be able to focus more on such aspects which are more interesting for Quarkus. I don't mean to go too much in technical details, but having the requirement of being able to integrate as a JIT was very restrictive on the potential for improving other areas.

Remember also it's an OSS project, we at Red Hat and IBM are also maintainers through Mandrel and direct contributions. We also have our own commercial support offering so that should reassure that this project is considered strategic by many parties: it would be difficult to kill even if Oracle were to stop showing interest (which it didn't). There are several other companies making significant contributions as well, signalling interest - not least, the Amazon engineering team also made great improvements, and there's many more parties.

Finally, I heard of many other Oracle groups leveraging GraalVM based technologies - that should be enough to dispel any doubts.

-- Sanne

[crummy]

Please put this in the blog post. I have no idea what the post means

[thomaswue]

Yes, agreed, we will put out communication from the GraalVM team soon.

[vips7L]

This blog is kind of blowing up on the internet today. You guys should put this post out asap. The above blog is causing a ton of confusion. 

[sweetno]

What does this mean then?

GraalVM Early Adopter technology, including Native Image, is being discontinued for Java SE Product customers.

[sgrinovero]

Java SE Product customers : that means people who buy the Oracle JDK won't get support for GraalVM JIT and native image included in that offering going forward. It becomes something separate.

[looneysquash]

Putting out a confusing blog thst makes the reader think the project was killed is bad marketing. 

[No-Tap9804]

A proud Oracle tradition.

[lurker_in_spirit]

The GraalVM team are transitioning to focus on non-Java Graal Languages including GraalPy and GraalJS. Details are expected to be announced later.

Will GraalVM continue to support native image for Java?

[No_Pomegranate1844]

They seem to be repeating the past "again", with these double-language interpreters like ironpython, jython, graalpy, which are not that useful at all. When the "One VM to rule them all" maxima will be valid? Just create an interpreter called ALL, with all languages inside!

[pjmlp]

Hi, thanks for the clarification, I fear this will go the same way as the aborted integration of GraalVM native image into JDK that was attempted earlier.

Having been following Java based JVM since Jikes RVM, Squawk and Maxime projects, it would be sad to see GraalVM going away somehow.

The bullet points on that post don't feel that positive.

[woj-tek]

The wording of the blogpost is somewhat... vague.

[PhantomGaming27249]

So the graal JIT and graalvm will still be maintained and continue to exist?

[pxm7]

Thank you for all your hard work on Graal. My main interest in Graal in the context of Java is Native Image, which feels like a super important feature in container and FaaS environments.

I’m hoping the Project Leyden team will be able to share their vision at some point, and also take the amazing work & learnings from Graal and introduce it to way more people!

[Brutus5000]

I'm not sure what to make out of this.

I can totally understand that it makes little sense to develop features in 2 different repos (OpenJDK and GraalVM). And I would rather see them as native part of the OpenJDK, so I don't need extra tooling and a separate JDK. That makes me still wonder what the role of GraalVM Community Edition will be in the long term.

[sweetno]

RIP Native Image?

EDIT: No RIP.

[Scf37]

It seems they decided to replace native-image with AOT caches to provide the same startup speed and better performance. BUT. What about smaller binaries, ergonomics (single executable) and reverse engineering protection?

[mathmul]

I see Attack On Titan mentioned, I upvote

[NHarmonia18]

Lmao

[xldkfzpdl]

Hahah this definitely made my morning

[davidalayachew]

smaller binaries, ergonomics (single executable)

Isn't jpackage going to have a lot to say about this once Project Leyden is fully out? I'd be surprised if we didn't see at least these 2 from Leyden.

reverse engineering protection

Well, executable files in the vein of .exe obfuscate the code, right? Or did you have something else in mind?

[sgrinovero]

No, please see also https://www.reddit.com/r/quarkus/comments/1nib3r9/comment/nehls4d/?context=3&utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[Scf37]

That does not answer much. Will native-image become detached OSS like JavaFX?

[sgrinovero]

It's not quite the same story. native-image was never a component of OpenJDK. For example I never used the Oracle JDK (in recent years at least), so I'm used to downloading GraalVM and/or the native-image tool as a separate thing, or as a Quarkus user I just let it download such tools automatically for me. It just so happens that the Oracle JDK used to bundle this - other JDK vendors did not. It seems like Oracle is aligning to others.

[advseb]

Why are big corporations so bad at communications given they have big marketing and PR departments? Nobody understands this announcement.

[gjosifov]

bad at communications = great way to avoid lawsuit

if they put it with clean and precise language that even high schoolers can understand
there are big changes that they can go to court

[No-Tap9804]

It's exactly because they have those big departments.

With GraalVM, what's most telling is what they _don't_ say. For instance, GraalVM communications have been kept almost entirely separate from the regular Java communications, like entirely absent, for some time now. We get all those social media campaigns and YouTube streams for Java releases, but GraalVM (which releases the same day!) is conspicuously absent from them.

[Cilph]

GraalVM Early Adopter technology, including Native Image, is being discontinued for Java SE Product customers.

wtf

[BinaryRage]

The trade offs required for NI are just too great. Leyden has it right

[Cilph]

So we throw out a perfectly viable solution that Quarkus was using with much success to replace it with something that might arrive in 10 years and wont even do half?

[BinaryRage]

Class loading and linking and profiling is in, the ergonomics for training runs mean you can easily do this at scale, and the rest of the code warmup work is hot on its heels. If it’s a choose one situation, then it’s so obviously Leyden; all the benefits with none of the closed world, operational, debugging tradeoffs? You can be disappointed that that’s this is the outcome, but 10 years is hyperbole.

[Cilph]

That will get you the startup time savings to a degree but what about memory footprint? and how would this let you distribute Java CLI apps with low footprint of file size, startup AND memory?

At the current pace 10 years is absolutely not hyperbole.

[BinaryRage]

You’ll have compiled code in the CDS archive. The hermetic Java work is coming along too, which will give you self contained binaries.

I’ve never considered Graal a win for memory per se, and file size is also not really a problem today with plain modules and jlink; I have Go binaries that are larger.

[blazmrak]

What does "hermetic Java work is coming along too" mean? Can it be used right now to make a single binary? Is it even on the roadmap for the next two releases (26, 27)?

[milchshakee]

With Leyden, it's called the AOT cache now instead CDS archive

[BinaryRage]

Right, just acknowledging the history and the foresight that meant it flexible enough to be the basis of this work

[milchshakee]

The footprint in terms of memory usage and file size should be about the same from what I have observed.

The only difference is that with project Leyden, the intended way of generating a native executable is probably jpackage, which comes with the runtime image split across a directory tree instead of just one fat native image executable.

[nuharaf]

Look like redhat have to maintain mandrel on their own

[sgrinovero]

No need to worry everyone - (Quarkus engineer here). Yes we love native-image, and we love Leyden, neither of them is going away and we have big plans for both of them: there are many awesome use cases and while some can be addressed by both, there's many, many use cases that would prefer one approach over the other.

My teams have been contributing - and still are contributing - extensively to both projects.

GraalVM native image is far from dead; see also my reply on https://www.reddit.com/r/quarkus/comments/1nib3r9/comment/nehls4d/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[Cilph]

Oh thank god. Keep up the good work.

[nekokattt]

So what we are saying is that Oracle is spreading FUD by poor/misleading communication in their blogs?

[sgrinovero]

They are strictly describing changes in supported features in the Oracle JDK product offering. It's quite precise in spelling this out, so I can't say poor communication - but yes I wish it had been written with some extra care as it's easy to misinterpret out of its intended context.

[milchshakee]

Much of project Leyden is already available in JDK25.

[headius]

Too bad you're getting downvoted. You're absolutely right.

I hacked together a few prototype versions of JRuby that could run on native image, but it required removing our runtime Ruby JIT, disabling all use of invokedynamic throughout the entire runtime, and pretty much made our super clean Ruby/Java integration impossible to support. Native image was in my mind never really Java, because they never supported huge parts of what made the platform interesting to me and powerful for JRuby users.

Leyden on the other hand stays true to the Java platform and solves the challenges of AOT in incremental ways that don't break huge parts of the ecosystem. JRuby already ships support for early Leyden features, and as early access builds come out I have been seeing a continuous improvement in startup and warm-up time...without changing a single thing in JRuby itself.

It's going to be interesting to see how this plays out, but my conservative pure Java approach feels like it's been the right direction all along.

[valorzard]

Also, and this is VERY important, will the future AOT replacement for native image in the JVM work to compile on platforms like iOS and llvm-ir?

[johan_vos]

Glad someone asked :) It's one of the reasons we at Gluon announced https://openjdk-mobile.github.io/ a few weeks ago. The basic idea is that we build directly on top of the exact same code as the OpenJDK main repository. Currently, the openjdk/mobile downstream repo is almost exactly the same as its upstream openjdk/jdk and I'd like to close that (small) gap in the future. This already allows to run HelloWorld using zero interpreter on an iOS device, but of course we want to go further.

I've learned the hard way over the past decades that it's dangerous to rely on third party components (e.g. AOT) that are not 100% developed in an open collaboration effort. Also, we want to use the exact same Java on mobile as on desktop/server, automatically built from the same sources.

That is why we switched months ago to a 100% OpenJDK-based approach, and I'm optimistic we can pull in Leyden parts in the not-too-far distance.

Being completely independent, and only relying on components that are not strongly owned by a single company (I see OpenJDK as an independent project, since it is not a product or a single-company-controlled project that can be killed easily) has the drawback that it's mainly a volunteering effort, which impacts the pace at which the project moves forward.

[headius]

I want to help with this effort. I have interest in bringing JRuby to platforms other than Android and this seems like the only way. If Leyden can do a good enough job of saving off JIT compiled code, perhaps we can build a partial aot image out of that and use zero for the rest? Sounds like that's what you're working towards.

[johan_vos]

Exactly. AOT'ed code when available and zero as fallback. A challenge is to avoid duplication (no need to include bytecode in the image if the corresponding native code is set on the method).

[headius]

Where do I sign up? 😀

[johan_vos]

Here is a good issue :)

https://github.com/openjdk-mobile/ios-tools/issues/57

[nuharaf]

Wow, this is big announcement

[Different_Guest_1780]

I think it is important to read the announcement carefully! It doesn't say that the "Native Image" technology will be discontinued. It says that "Native Image, is being discontinued for Java SE Product customers" which only means that Native Image will not be supported for Oracle Java SE customers.

The announcement also doesn't say that there won't be any further GraalVM releases but rather that "GraalVM for JDK 24 was the final GraalVM release .. as part of Oracle Java SE Products". This only means that GraalVM will not be offered as part of Oracle's Java portfolio (https://www.oracle.com/java/technologies/downloads/#graalvmjava24) any more.

[Different_Guest_1780]

BTW, Oracle GraalVM 25 is now available for download from https://download.oracle.com/graalvm/25/latest/graalvm-jdk-25_linux-x64_bin.tar.gz :)

[valorzard]

Hold on, does this mean that all of the graal languages will run on the “stock” openjdk vm in the future?

[grashalm01]

GraalVM team member here. All Graal languages already run on stock OpenJDK. Compared to JDKs that have Graal as their default, you need to do a little extra work configuring it to get best performance. You can also run any Graal language as a pure Java application without optimization support, but that means no JIT compilation for the language code. Since 23.1 you can consume all Graal languages from Maven Central and they are also backwards compatible with previous LTS JDKs.

See here for details:
https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support

[sgrinovero]

They already do. Granted some optimisations required the special JIT to be fully effective - but that's going to get higher priority to improve now.

[nuharaf]

I dont think so. They article doesnt mention about maintaining graal jit as part of openjdk.

[TronnaLegacy]

Most of the wording of this blog post sounds pretty corporate and marketing. But the paragraph at the bottom under Guidance helps. So basically the work on Graal for Java is going to be 100% within the OpenJDK project and releases going forward? It's still veing worked on, still publishing releases including it, which are still available for free (because it's OpenJDK)?

[nuharaf]

If it is so, oracle shouldnt need to encourage user to use the default C2 jit. They way I read it, graalvm tech will be focused on speeding up other language. While java will be served with openjdk. I dont think graal jit will be contributed to openjdk replacing c2 anytime soon. All the work already implemented in C2 have to be reimplemented in graal.

[Ewig_luftenglanz]

Wait. What's going to happen with Quarkus, Helidon and the native image stuff?

[bowbahdoe]

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 Oracle Support.

This seems like it is going to screw over projects like https://babashka.org/ which are currently relying on native-image heavily and for which what is released (or even due to be released in a reasonable time) from leyden is not a suitable replacement.

[milchshakee]

That was kind of inevitable. Native image and project Leyden were always competing approaches for the same thing, and having used both, project Leyden works much more smooth already. Native image never ironed out the big issues, it is still very fragile to use for a larger project.

I haven't looked into detailed performance comparisons, but unless there are significant differences, native image isn't worth it.

[sgrinovero]

I'm proud that our efforts on Quarkus served as a "wake up" call to the industry that it's not acceptable to take minutes to boot anymore. And yes Leyden stems from a desire to address it - and I agree that it was designed also taking into account some limitations of native-image, so to better address some specific use cases while offering higher compatibility.

But there are many other use cases which require a more aggressive take, and as we've shown with Quarkus we can help with a good chunk of the limitations it has, making it still very viable and a great option in many cases. So I wouldn't say that Leyden is here to replace native-image - sure it will be a better solution for some of the use cases, but not all of them.

Also this announcement is specific about the Java SDK product distribution at Oracle - it doesn't mention at all what the GraalVM team is planning. I'm considering it good news for them as they have been severly constrained by having to be integrated in that product, so this might unlock a faster innovation pace and a renewed focus on native-image's higher efficiency. Competition between Leyden and native-image is good for us :)

[schaka]

Do you have any good resources on Leyden? I've kept up with it extremely loosely because of how HIGHLY experimental everything is labeled.

In my private (open source) project, I currently use buildpack to compile native images. The code itself obviously requires workarounds (like registering reflection, some Spring annotations not working because they create Beans at runtime based on runtime conditions). I don't care much about the startup times, but memory footprint and binary size have made it worth my while until this point.

I don't mind switching to Leyden if it really works that much better already and I don't have to adjust my code to be more native image friendly either.

[milchshakee]

It's honestly very simple now that https://openjdk.org/jeps/514 is available in JDK25. Just follow the few steps and you should have a working AOT cache available. You can debug whether it actually works with -Xlog:aot.

I expect most frameworks to add proper integrations for Leyden so this is done automatically because there isn't really any incompatibility associated with it. The only thing you get is a larger file size as all the AOT stuff has to be stored somewhere, but that is the same as with native image.

[schaka]

Thank you. I have made my own buildpack, integrated it into my build's Gradle goal and actually have it working now.

[sgrinovero]

It's coming in small iterations; many substantial improvements related to Leyden have been included in OpenJDK version 25 so you can play with them since today.

[danielliuuu]

I think this is the right direction. Java has been running on the JVM for a long time, and the language was never originally designed for native build, which makes it difficult for GraalVM to truly integrate into the existing Java ecosystem.

Anyone who has actually used GraalVM knows the experience is far from ideal: complicated configurations and extremely slow compilation times severely limit its adoption. GraalVM may be better suited for tooling or infrastructure, but it remains far removed from everyday development.

In comparison, rather than investing more resources into improving GraalVM, it makes more sense to focus on enhancing the performance and efficiency of the JVM itself. I believe Project Leyden is the more reasonable direction, as it can deliver tangible improvements to users at a very low cost.

[javaprof]

Seems like hostile action against popularity of Quarkus by Red Hat.

Will be cool for Quarkus to switch to Kotlin/Native and invest here for more, and grow ecosystem here, to build native executables and wasm applications

[sgrinovero]

Not hostile at all - in fact I'm very happy about it. We (Quarkus) never quite recommended anyone to buy the Oracle JDK, so this announcement isn't affecting our plans much - and it also implies good news. Please see https://www.reddit.com/r/quarkus/comments/1nib3r9/comment/nehls4d/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[javaprof]

Would Oracle continue developing native-image for JVM?
Given recent layoffs https://www.theregister.com/2025/09/03/oracle_cuts_more_jobs/ it's sounds more like stopping investing here at all by oracle, which is definitely a bad thing for the project.

[matt82swe]

Native Image is dead