GraalVM 25.1 is here! 🎉

First innovation release 🚀

Today, we’re pleased to announce the release of GraalVM 25.1!

GraalVM 25.1 is the first innovation release to build on GraalVM 25, with 25.2, 25.3, and subsequent releases to follow. This new release train will deliver features and improvements sooner, through smaller, incremental releases that make it easier to try new capabilities and provide feedback.

Meanwhile, the long-term support GraalVM 25.0 release train will continue to receive regular Critical Patch Updates (CPUs), providing the stability that production applications require.

You can already download GraalVM and check the release notes for more details.

This release is packed with new exciting features: even smaller native images, Native Image skill, AI-powered reachability metadata, polyglot sandboxing, and so much more — keep reading to learn about them!

You can also watch the release stream with our favorite features and demos:

Even Smaller Native Images 📦

Native Image is widely used to produce small, self-contained native executables. It does this through sophisticated reachability analysis that includes only the parts of your application you actually need, powerful optimizations from the Graal compiler, and more.

In this release, we further reduce the size of native images. We see an improvement of around 3% across a broad set of benchmarks, with small applications, such as CLI and automation tools, seeing the most significant gains. You can expect even more updates towards reducing image size in the next releases!

This improvement is achieved by reducing metadata stored in the image, making image heap storage more compact, and new more efficient String.format optimization.

As an example, we measured the impact of size optimization on the google-java-format project, which uses GraalVM Native Image to produce compact executables for distribution. The current release contains a linux-x86–64 build of 33.03 MB, while built with GraalVM 25.1 it goes down to 30.74 MB — 6.94% smaller!

Native Image Performance 🚀

Great news: this release introduces a highly-requested by our community feature: G1 GC is now available in Native Image on Darwin/aarch64! This means that you can have the same build setup for native images between your local Darwin AArch64 machine and a Linux-based deployment environment, or have better performance for your applications running on Darwin.

We also introduced a new Serial GC policy, Adaptive2, which uses mark-compact collection in the old generation by default. On average, this policy reduces memory usage and often improves throughput and latency. In our benchmarks, we observe improvements around peak RSS, throughput, and latency, although the exact impact varies by workload. For example, a Micronaut ShopCart application using Adaptive2 shows ~8% lower RSS and 3.8% higher throughput.

1500 libraries in the GraalVM Reachability Metadata Repository! 🤖

Native Image uses a closed-world assumption for AOT compilation. Static analysis can infer a lot, but some behavior is only visible at run time. Reachability metadata fills that gap for dynamic features such as reflection, resources, serialization, JNI, and proxies.

To simplify and automate working with reachability metadata for our users, several years ago we introduced GraalVM Reachability Metadata Repository. The goal was simple: let users share and reuse metadata instead of solving the same compatibility problems in every application. Over the years, we built out the repository together with Spring and Micronaut teams, and other members of the GraalVM community.

This year, with the rise of production-grade AI agents, we saw an opportunity to scale this work. We use a fleet of AI agents and a carefully designed workflow to generate the necessary metadata for thousands of libraries. The workflow starts with Native Image reports, uses tests to exercise dynamic behavior through standard library APIs, generates metadata from observed execution, and verifies the result with Native Image, CI, and human review.

As a result, Native Build Tools now can automatically pull reachability metadata for almost 1500 libraries!

To benefit from the repository, just make sure that your Maven or Gradle project uses Native Build Tools.

Requesting reachability metadata for a new library is as simple as providing its Maven coordinates — follow the instructions on GitHub.

Native Image Skill for AI Agents 🤖

We added a Native Image skill to oracle/skills! This repository is a centralized collection of specialized skills for working with common Oracle technologies, such as Oracle Database, Oracle APEX, GraalVM, Fusion, OCI, and others.

Our skill provides AI assistants with the best practices and practical steps for common Native Image workflows and tasks. By using this skill, an AI assistant can help you:

• Build native executables with the Native Image CLI;
• Configure Native Build Tools for Maven and Gradle projects;
• Set common build options for performance, binary size, monitoring, and security;
• Work with reachability metadata;
• Troubleshoot build failures, runtime differences, class initialization issues, missing metadata, and other issues.

We look forward to your feedback as you try the skill in your projects. You can explore on GitHub, or install from command line:

npx skills add oracle/skills/graal

Dynamic Class Loading in Native Image 🌎

This release includes an early version of Dynamic Class Loading in Native Image. It can be useful for libraries and tools that generate JVM bytecode at run time, and open the door to more plugin use cases, such as loading javac annotation processors dynamically. Good example of such project is for example ByteBuddy — a library commonly used to generate and modify classes at runtime.

To try it, pass -H:+RuntimeClassLoading to your Native Image build.

While Crema is still a work in progress, it includes another step in
that direction: it adds Ristretto — a JIT compiler for runtime-loaded classes. To try it, additionally pass -H:+GraalJITCompileAtRuntime to your Crema build.

Developer Experience Improvements 🛠️

• JFR recordings and heap dumps on Windows: Native Image now supports these diagnostics on Windows, making debugging more consistent across platforms.
• --print-options for native-image: print available build options directly from the tool in table, Markdown, or JSON format. It can be useful for option discovery, docs, and tooling.
• JFR emergency dumps on POSIX: when an out-of-memory error happens while a JFR recording is active, Native Image can preserve the in-memory recording data in an emergency JFR file.
• Runtime collection of conditional reachability metadata: -XX:TraceMetadataConditionPackages helps collect more precise metadata from a native image at run time.
• Simpler tracing-agent filtering: the Native Image agent now applies built-in filters by default. Custom filters can still be passed directly when needed.
• Reachability metadata schema shipped with GraalVM: the schema is now available locally at <graalvm-home>/lib/svm/schemas/reachability-metadata-schema.json, with more detailed validation constraints.
• Portable Native Image bundles: bundle path maps are now portable across platforms, and the bundle format is versioned as 1.0.
• Bundle size warnings: Native Image bundles can now warn when individual files or the total bundle size exceed configured limits.
• -Werror for Native Image: treat warnings as errors, which is useful for CI and stricter build pipelines.

GraalPy 🐍

• GraalPy now includes new -X jit=0|1|2 presets. These presets make it easier to tune GraalPy for different workloads, from startup-heavy applications to throughput-oriented ones. The GraalPy launcher now defaults to the jit=1 preset.
• The GraalPy Native standalone on Linux now uses a lower-footprint Native Image garbage collection configuration. This reduces resident set size (RSS) for many workloads, but may increase startup time and warmup time — we encourage you to try it on your own workloads.
• Java interoperability got several useful improvements. Foreign buffer objects are now treated as Python buffer-compatible binary objects, so APIs such as memoryview, bytes, bytearray, binascii.hexlify, and io.BytesIO work naturally with them. This makes it easier to pass binary data between Python and Java ByteBuffer or ByteSequence objects, with minimal and sometimes zero copies.
• For embedding use cases, GraalPy adds more precise control over execution. New Truffle source options let embedders set the Python optimization level with python.Optimize and run code with a fresh globals dictionary using python.NewGlobals. There is also a new Java backend for pyexpat, useful when running without native access or in multiple-context scenarios. This backend is the default when embedding; the standalone distribution still defaults to native expat.
• GraalPy 25.1 also improves compatibility. The _ctypes module now uses the native CPython version instead of the previous intrinsified implementation, which improves compatibility and reduces the memory footprint of using ctypes. GraalPy also dispatches sys.audit events to hooks registered with sys.addaudithook, including events raised through the PySys_Audit C API.
• Standalone JVM artifacts are no longer released as separate distributions. For standalone deployments, use the GraalPy native artifacts. If you require Java interoperability, use our jbang launcher (jbang graalpy@oracle/graalpython -c "print('hello from GraalPy')") or a custom embedding.

GraalJS and GraalWasm

GraalVM 25.1 also brings important updates for GraalJS, including new ECMAScript support, Node.js updates, new WebAssembly proposals, and more.

• ECMAScript 2026 mode and features are now enabled by default.
• Node.js has been updated to version 24.14.1.
• Temporal support is complete and available in ECMAScript 2027 mode: enable with --js.ecmascript-version=2027
• The new experimental js.crypto option provides getRandomValues() and randomUUID() from the Web Crypto API.
• The stable js.performance option provides performance.now(), timeOrigin, and toJSON() from the Web High Resolution Time API.
• The WebAssembly GC proposal is now implemented and enabled by default! It can be disabled with wasm.GC=false.
• GraalWasm now uses a bytecode-handler-based design for the WebAssembly interpreter, improving interpreted performance on Native Image.
• Standardized WebAssembly features Extended Constant Expressions, Multiple Memories, Relaxed SIMD, and Typed Function References are now enabled by default.

For a detailed list of GraalJS and GraalWasm updates in this release, check the release notes.

Polyglot Runtime

Also new in GraalVM 25.1, the Truffle sandbox is now available in GraalVM Community Edition, giving embedders a practical way to run guest JavaScript or WebAssembly behind a configurable security boundary. Sandboxing is becoming increasingly important as applications look for safe ways to run AI-written code: for example, an application could let users install AI-generated JavaScript plugins while limiting what those plugins can read, how long they can run, and which application APIs they may call. With the Truffle sandbox, applications can restrict host access, file and socket access, native calls, process creation, output, memory, CPU time, statement count, stack depth, and more. We will share more about the Truffle sandbox in upcoming posts, including a deeper technical look and a new project that builds on it to turn prompts into application plugins.

• Starting with Polyglot 25.1, the optimizing Truffle runtime is supported only with GraalVM 25.1 or later, including Oracle GraalVM and GraalVM Community Edition. On standard JDKs down to JDK 21, you can either use polyglot isolates, or the fallback runtime without runtime compilation.
• The JavaScript polyglot isolate now includes support for WebAssembly.
• Language launchers now use --polyglot by default, so you no longer need to pass it explicitly to use other languages in standalones.

For a detailed list of polyglot runtime and Truffle framework updates in this release, check the release notes.

Community and Ecosystem

• After migrating to Native Image, trivago eliminated warm-up and reduced replicas from 43 to 12 for their GraphQL gateway, handling 9,000+ req/s per subgraph. Learn more about their migration process and recommendations.
• Learn how Picnic built a rule engine on GraalVM, where rules are defined in JavaScript or Python and executed by a Java backend, handling 37M evaluations and 2M actions daily.
• A local AWS emulator that starts in 24 ms and uses just 13 MB of idle memory? Learn how Hector Ventura built Floci — free, open-source, and powered by GraalVM!
• GraalVM accepts AI-assisted contributions, while the human contributor remains responsible for reviewing and verifying the submitted change;
• Micronaut 5 was released, moving to a Java 25 and GraalVM 25.0.3 baseline.
• Quarkus 3.35 offers an out-of-the-box PGO integration: enable it with quarkus.native.pgo.enabled=true, and use your existing integration tests for the profiling workflow.

Conclusion

We’d like to take this opportunity to thank our amazing contributors and community for all the feedback, suggestions, and contributions that went into this release.

If you have feedback for this release or suggestions for features that you would like to see in future releases, please share them with us on Slack, GitHub, or LinkedIn.

Now go ahead and try the new GraalVM! 🚀

— the GraalVM team