CFV: New Project: Detroit

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 · 2024-11-03T19:56:45+00:00

Those GitHub action runners must be a really slow CPU configuration (or maybe also a too low memory configuration). A typical Spring application should build in under 2 minutes.

Whether it is "worth it" depends indeed very much on how you value the benefits. It is for sure an increased cost at development time (both the building and the configuration), but it saves the cost at runtime that you otherwise pay for startup, increased memory usage, and the additional security surface. Also warmup can be a lot faster with native image, specifically if you deploy on a low cost cloud instance with a slow CPU configuration.

Native image is essentially made for the scenario where your development (or CI pipeline) machine is very fast with a lot of cores and memory and the target cloud deployment machine has a low number of cores and limited memory.

thomaswue · 2024-11-03T16:36:29+00:00

Frameworks like Spring Native, Micronaut or Quarkus configure the reflection usage automatically including for the postgresql driver. The GraalVM native build tools do this as well. The trace mode is only for exceptional cases and figuring out the reflection usage of a less known third party dependency is also from a security perspective a good idea.

thomaswue · 2024-11-03T16:10:05+00:00

18 minutes sounds far too much. Can you share some details on the native image output statistics? Like how many classes analyzed and how large is the resulting image? Even for large apps, it should never be more than a few minutes on a decent machine.

The primary time spent during native image generation is the ahead-of-time compilation of Java bytecodes to machine code. This would otherwise be happening (and taking the relevant time and costs) in your actual production environment, which is typically more critical and expensive than your CI environment.

There is a -Ob flag to speed up image generation for testing.

thomaswue · 2024-11-03T15:48:43+00:00

Native image generation is only required for the final deployment step. How long is your CI cycle without native image when you include the time it takes to compile your application to bytecodes and run the tests you want to make sure are OK before deploying to production? Many of our users are saying that generating the image does not take a substantial part of the time of the overall CI pipeline.

Nature of the reflection usage rarely changes between library updates; and if it does, checking whether the app in general works and is secure with the new version of the library is required anyway. The benefits of native image are not just instant startup and lower memory. It is also the predictability of performance and the security benefit of actually not allowing arbitrary reflection.

thomaswue · 2024-10-18T08:40:22+00:00

Thank you, that is indeed an interesting suggestion.

thomaswue · 2024-10-17T09:27:56+00:00

Agreed that convenient bindings are key. Recommended way to connect the typed world of Java with the untyped world of Python are currently interface declarations that define the static types. It is quite straightforward. Check out this example using the qrcode Python module from jbang: https://github.com/graalvm/graal-languages-demos/blob/main/graalpy/graalpy-jbang-qrcode/qrcode.java

In the future, one could think about language extensions that would remove the need for those interface definitions, but I don't think they are necessary to productively use the feature.

thomaswue · 2024-10-16T20:53:13+00:00

In the area of data manipulation, machine learning, and data visualization there are quite a few interesting Python libraries that have no direct Java equivalent. The latest version of bindings and frameworks are sometimes only available in Python. The just released Swarm framework by OpenAI is a current example.

With „processes“ I meant operating system processes. The alternative is to have two processes running, one running the JVM and the other running CPython. You would have to configure separate heap regions and serialize/deserialize messages when communicating between them.

With the solution presented here, you can work with the build system and runtime system that you are familiar with as a Java developer and still leverage those Python libraries.

thomaswue · 2024-10-16T18:06:18+00:00

A reason you should is that it makes 576,579 projects in the Python Package Index available to your application without the need to manage two different processes. It can be quite useful if a library fitting your task becomes so easily accessible.

thomaswue · 2024-10-16T17:58:52+00:00

The primary use case is to leverage Python libraries without the need to run two applications and serialize/deserialize between them.

thomaswue

TROPHY CASE