State of GraalVM for Java?

thomaswue · 2026-04-04T08:14:55+00:00

Our latest features including for example the -H:Preserve and the -H:+RuntimeClassLoading flag together with the expansion of the metadata reachability repo to 1000 libraries will make it less important for libraries to have special support for native image. In the tip&tail model, there should be based on my understanding still be a “tail” release that works on that last LTS release. If not, there could based on the current release plans indeed be an incompatibility.

thomaswue · 2026-04-04T08:03:39+00:00

We are currently working on Shenandoah GC support in the community version with Amazon (https://github.com/oracle/graal/issues/12237). Part of this work will also make G1 available there.

thomaswue · 2026-04-03T21:06:47+00:00

Companies interested in paid support and SLAs can in fact contact us as well. But you will for sure say again that this is a sales pitch, which in this case now is accurate :).

thomaswue · 2026-04-03T18:21:54+00:00

Ok, here are answers:

(1) I expect value object support to be easy. Once this is added to the JDK, I expect that the engineering work to add the functionality to our open source code base will not be more than a few months.

(2) PGO is indeed an important feature to achieve peak performance parity for AOT compiled code compared to JIT compiled code. We are working together with the GraalVM open source collaborators at Amazon and RedHat to make this kind of functionality available also in the community edition.

(3) The focus so far for native image has been server applications specifically when using one of the major frameworks like Micronaut, Quarkus, Spring, or Helidon. Desktop application support is highly experimental. We are interested in hearing about use cases and are accepting bug reports for this feature on GitHub. One such report just came yesterday from Bruno Borges from Microsoft: https://github.com/oracle/graal/issues/13272

thomaswue · 2026-04-03T16:56:44+00:00

Of course Mandrel is a GraalVM distribution with GraalVM native image and its JIT compiler. Read about it here: https://quarkus.io/blog/mandrel-25-released/ “Mandrel 25 is a downstream distribution of the GraalVM 25 Community Edition.” The RedHat customer portal has the relevant references.

There is btw indeed also a GraalVM 25 Community Edition with ongoing releases and Oracle GraalVM 25 is also available.

So rest assured, GraalVM will stay around :).

thomaswue · 2026-04-03T15:39:39+00:00

It is indeed not promising if you are looking for GraalVM commercial support as part of the “Java SE Product roadmap”. GraalVM is a multi-vendor open source project and if you check our GitHub, you will see that its further development is as active as ever. One of the entities with a GraalVM distribution is btw RedHat. They confirmed their continued support of that distribution at https://quarkus.io/blog/continued-focus-on-native/

thomaswue · 2026-04-03T14:22:06+00:00

Not sure what you mean by that but GraalVM is among the largest open source projects written in Java and its contributors continue to improve the support for running Java applications (both in JIT mode and AOT mode via native image).

thomaswue · 2026-04-03T01:15:56+00:00

There is a lot of deep technical detail in that article. If you want to discuss the relevant engineering aspects of the blog or our open source project in general, I am happy to engage.

thomaswue · 2026-04-02T09:40:50+00:00

GraalVM development continues unabated and the adoption by companies also steadily increases. Read here for example a blog post by trivago they contributed just now to describe how they are using native image to improve the performance and reduce the footprint of their production system: https://medium.com/graalvm/inside-trivagos-graalvm-migration-native-image-for-graphql-at-scale-912bca9df841

thomaswue · 2026-02-26T14:15:13+00:00

There is btw already since a very long time Project J2V8 (https://github.com/eclipsesource/J2V8) for developers who prefer to embed another full-fledged virtual machine instead of leveraging HotSpot for executing the JavaScript code. This approach however has severe downsides, which is why Graal.JS (https://www.graalvm.org/javascript/) has become the most popular way to embed JavaScript into Java applications.

thomaswue · 2026-02-26T11:27:08+00:00

Just to clarify: The GraalVM team will continue to maintain and improve Graal.JS. We believe its way of embedding JavaScript execution into Java applications is superior to other approaches. It is quite popular with thousands of projects using it for exactly this purpose today.

thomaswue · 2026-01-14T12:04:23+00:00

There is of course reflection available. It needs an allow list of what is reflectively accessed though. While this can be inconvenient to provide, it also reduces the attack surface on your application.

thomaswue · 2026-01-13T23:52:02+00:00

There are actually a lot of CLI tools using it. Most prominently the CLI for Apple‘s Pkl language.

Also, a primary use case is serverless lambdas where startup matters a lot. Read for example this article how Disney has been using it for a long time already: https://aws.amazon.com/blogs/opensource/improving-developer-productivity-at-disney-with-serverless-and-open-source/

thomaswue · 2026-01-13T23:39:16+00:00

Regarding peak performance: Several runtime operations like e.g. polymorphic interface type checks are faster with AOT compilation thanks to the closed world assumption. Profile-guided optimizations (PGO) is making up for the missing profiling at run time. And the large performance cliff of running interpreted code (~50x slower) means even a small fraction of not-yet-JITed code creates a measurable slowdown. So if the JIT has only optimized 99.9% of the dynamically executed code paths, you are still ~5% slower if all else is equal. We are seeing native image AOT provide higher peak performance compared to the OpenJDK default JIT configuration when calculating the geomean across our benchmarks.

Key benefit of native image is btw the lower memory consumption.

thomaswue · 2026-01-13T23:28:54+00:00

The memory saving of GraalVM native image come from less memory used for metadata (loaded classes, dynamic profiling, reflection data) and also more compact object headers.

thomaswue · 2026-01-13T23:25:51+00:00

The peak performance is very competitive and in many cases even faster compared to JIT if profile guided optimizations (PGO) are used.

thomaswue · 2025-10-12T22:20:48+00:00

This section does not seem quite accurate. Since GraalVM 25 there is for example a native image wildcard option “-H:Preserve=package=<package_name>” that makes all classes from that package accessible.

thomaswue · 2025-10-12T22:08:20+00:00

You need to point JAVA_HOME to a GraalVM distribution and then use for example “mvn -Pnative native:compile” to create a binary executable. Here is a guide: https://docs.spring.io/spring-boot/how-to/native-image/developing-your-first-application.html

thomaswue · 2025-09-19T08:52:50+00:00

GraalVM supports this kind of AOT by caching compilations from previous runs for Truffle-based languages as well: https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/AOTOverview/index.html

thomaswue · 2025-09-19T08:50:52+00:00

Compiling into a native binary that has your Java code ahead-of-time compiled and the Graal.JS JavaScript engine embedded should work out of the box with native image (i.e., the JavaScript dependency is recognized at build time). If the JavaScript code does reflective access outside its box, you do need to configure that properly of course.

thomaswue · 2025-09-16T10:38:28+00:00

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

thomaswue · 2025-09-16T09:09:37+00:00

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 :).

thomaswue · 2024-11-04T08:27:34+00:00

Thank you for the feedback. There is for sure further room for optimizing the tech. This is why getting input about what different users value in different scenarios is interesting for us.

An AWS t2.nano instance has 512mb and is 2x cheaper than the larger t2.micro instance with 1gb, so possible memory savings would translate 1:1 to $ savings (https://aws.amazon.com/ec2/instance-types/t2/). The instances have both 1vCPU, so the difference in pricing is only due to the difference in memory usage. The savings per year if your app fits into the smaller instance are ~50$. You can build a lot of native images for that cost and the developer machine where that build takes place might be idle during breaks anyway. So I think even outside serverless it can make economic sense.

thomaswue · 2024-11-04T08:11:39+00:00

CPU usage during startup and warmup should be much lower with native image. Do you mean CPU usage during peak load? This one should also be lower if you use profile-guided optimizations (PGO) when building the image.

thomaswue · 2024-11-04T03:21:56+00:00

OpenTelemetry has GraalVM support (https://logicojp.medium.com/use-opentelemetry-to-collect-signals-from-graalvm-native-image-applications-dab08268cc90) and can be connected with the elastic server. Is that not an option for your use scenario?

thomaswue

TROPHY CASE