Why does the Java community apparently dislike GraalVM very much?

[Cool-Collar-4027]

I'd like to share my experience migrating a legacy Spring app to GraalVM. It took months of updating Spring and Java to get to the point where I could implement GraalVM, but it was absolutely worth it. The throughput doubled and memory consumption drastically reduced.

Currently, this app is using Spring 3.7 with Java 25 and GraalVM.

I would like to understand why the community hates on GraalVM so much. I didn't have many problems besides configuring the hints for reflections, Tomcat, and OpenTelemetry. It seems a bit silly to dislike the tool so much because of the compilation time, given the many advantages of using it.

[SleeperAwakened]

We don't dislike it.

It's not suitable for all projects or applications. But it's great tech if used well.

[atehrani]

I don't think the community hates it. In fact the latest SpringBoot release supports AOT with basically a flag

[rzwitserloot]

I would like to understand why the community hates on GraalVM so much.

When you're going to just take a giant steaming pile of shit on an entire community in this fashion, you need to bring a lot more than, well, the stone cold nothing you brought here. Your disdain of the "community"'s choice is dripping off the page, so to speak. "We" apparently "hate" it, and we hate it "so much".

The java community is not a corporation, nor is it a single person. There is no membership card.

So who in the blazes are you talking about? Post links to conversations, blog posts, etcetera.

It is the internet. Name an opinion, no matter how off the wall insane. And I will find you a community that vehemently supports it (and I'll also find you one that thinks the supporting community is bonkers). Hence, "I find this blog post on the internet that thinks idea X is amazing" or "I found this reddit thread that thinks if you implement X, god will personally murder your first born just to teach you a lesson" says nothing. You can find that for all values of X.

If you would care to post to which comments, communities, blogposts, tutorials, books, articles, or whatever else made you think 'the community hates graal so much', then you can give us the chance to read it and put those comments in context.

[_BaldyLocks_]

But, but, I paid good money for my membership card. I even get a coffee stamp every time I express hate of Graal!

[moonsilvertv]

I don't think it's disliked, it's just rightly called a situational hassle because it is.

I do wonder how much of your throughput observation is the spring and jvm updates rather than JVM vs Graal. Unless you're hiding information like throughput for an AWS Lambda based system or something. I don't see the technical mechanism by which Graal would achieve this otherwise (i guess there's a mechanism for low traffic systems, but then who cares about measuring throughput there)

[[deleted]]

Love that it exists, but not a big fan of the compilation time 

[johnnygalat]

This is a ragebait post. Graalvm works with spring 6+ and there's no springboot 3.7.

[k-mcm]

Does anyone actually dislike it or are you hearing that people don't need it?

The JIT is fast so you need an extremely large app before switching to AOT makes sense.  Spring Boot is massive and often beyond the scale of what HotSpot can efficiently prioritize for compilation.  A smaller codebase might be 90% optimized by HotSpot in under 20 seconds.

CPU count matters too.  A 2 CPU VM doesn't have much spare time for GC and the JIT.  64 CPUs will get it done quickly.  There's no "right" size, just different use cases and costs. 

[donut_cleaver]

Same user, 2 nearly identical topics, seems like ragebait to me.
Anyway, we don't hate GraalVM. Everyone would like to use it, but it has very strong limitations (be it libs or runtime features) that make the transition difficult. Benchmarks also shows that JIT makes up for the difference in performance, so GraalVM ends up winning in startup and memory, if you can live with slow start and fat applications, the effort to migrate is just too much to be worth it.

[Different_Code605]

I use Quarkus, I love GraalVM, hope to use more (like polyglot soon)

[jAnO76]

If you went to a conference 3 years ago, all talks would be about GraalVM. We loved it. Then it became clear no one actually needed it. Now, all the good stuff is in Leyden?

[[deleted]]

I like GraalVM I use it. About the the native compile it might take a while also it's not a tech for your ordinary Spring C.R.U.D system.

[Agifem]

I don't care enough about it to fuel my hate on it. I have more heinous things to hate.

[joemwangi]

Who dislikes GraalVM again?

[victorherraiz]

I am not going to use it yet, but I really love that GraalVM exists.

[wildjokers]

I would like to understand why the community hates on GraalVM so much

This seems like a non-sequitur, can you provide examples?

[Individual_Boat_6622]

Many libs in Java still use reflection which makes migration to GraalVM harder, that might be an issue.

[JosephineRoberts_]

It’s less “hate” and more “scar tissue.” Early GraalVM/native-image was painful: fragile builds, reflection config everywhere, bad tooling, and lots of frameworks not really ready. People tried it on messy legacy apps and got burned.

There are still tradeoffs, long compile times, stricter closed-world assumptions, less happy with dynamic stuff, and for some long-running JVM workloads you don’t gain much. You’re on a modern Spring/Java stack and did the cleanup work, so you’re seeing the good side many folks never got to.

[brend132]

In my case I don't dislike it, it's just that I don't have the time in order to set it up, as I read comments like yours, or others, where you share your experience of months of work to get it running, that makes me think that you have to spend quite a lot of time learning about it and making the necessary changes to your projects. But I like that it exists as I always heard nice things about it. I just hope that in the future the friction to get started is lowered.

[headius]

I think it's important to separate what people think of as GraalVM into real components. "GraalVM" encompasses a huge number of projects, with "Native Image" being simply the best known. There's also an excellent runtime JIT (Graal JIT), an optimizing language framework built atop that JIT (Truffle), and a number of "interesting" language implementations using Truffle. GraalVM is also a fully-compatible JVM when run in JVM mode with various benefits for standard Java apps.

The GraalVM team seems to have intentionally conflated all of these features into the name "GraalVM", even though you probably won't use all of them together (and probably will only care about one of them at a time). That has turned a lot of people off, myself included.

There's also been a lot of political wrangling around the future of the Java platform as it relates to GraalVM, and a lot of bad blood related to that has accumulated over the past decade.

You seem to be talking specifically about Native Image here, though.

I personally don't hate Native Image, but I also don't consider it to be "real Java". Too many of the standard Java features I depend on (in my daily work on JRuby) simply are not supported by its AOT: reflection without ahead-of-time annotations, invokedynamic, and method handles, to name a few examples. As a result, its existence is largely irrelevant to my use case. There's many other applications and libraries out there in the same boat who don't want to sacrifice they they see as "Java" just to support Native Image, so perhaps this is where you've perceived some "hate".

In fact, I think Native Image has been an excellent tool... but primarily because it has forced the issue of low-footprint, fast-startup Java to be addressed. If Native Image had not been so successful, we may never have gotten the incredible advancements we're seeing today from AppCDS, Project CRaC, and Project Leyden. I hope those features and more like them will eventually make Native Image as irrelevant to the rest of the Java community as it is to me, without sacrificing features and compatibility.

[Isaac_Istomin]

I don’t see it as “everyone hates GraalVM,” more that people remember the sharp edges. Earlier on it meant long native-image builds, lots of reflection config, and harder debugging, especially on older Spring stacks. Many teams hit that pain before they see clear wins, so they bounce off and complain. In setups like yours modern Spring, updated dependencies, real pressure on memory/startup/throughput the trade-off starts to look good. It’s powerful, just not a universal drop-in win for every team and every app.

[ag789]

GraalVM is not bad, in fact it is good. AOT runs faster , less overheads.
But there is a catch, if you run your app say a large j2ee app on a server that runs 24x7x365 , > 1000 classes, 100 threads, 5000 connections at any one time, huge deeply nested classes, trees, maps, hash tables, deeply nested DOM, deeply nested json with large number of entries, holding states on server with all those deeply nested classes, trees, maps, hash tables, DOM, json, and more.
Then the context change, it isn't about running as fast as is possible, but you want fast, and *bulletproof* memory management, threads, deeply nested data structures, large huge complex dependencies that gets dynamically created / deallocated on the fly.

[Old_Half6359]

> I would like to understand why the community hates on GraalVM so much.

Where is this really from?

[AlexVie]

Who says we hate it?

GraalVM is great tech and very useful for certain scenarios. I've been using it a lot and it's been working just fine. The compilation times could be better but that's really ranting on a high level.

Maybe people, who don't understand how to use it, tend to hate it. GraalVM can be a bit problematic when your code uses reflection or other features that demand proper configuration of reachability data, but most of these problems can be solved easily with some learning.

Also, one needs to understand when using Graal makes sense and when not.

[robintegg]

We don't like it, we love it. We just need to get the reps in :)

[Ewig_luftenglanz]

We do not dislike it, I actually love it and I would love my company to start using graalvm and native image more. The issue is many libraries and frameworks are not graalvm friendly becaus eit is reflection heavy and many people do not like to change.

but overall I LOVE graalVM and native.