For most of its history, Java has sat on the sidelines of the machine learning conversation. Python dominated that space, and for understandable reasons: it had the libraries, the ecosystem, and direct pathways to GPU hardware. Java, by contrast, had none of that. If you wanted to train a model or run GPU-accelerated inference in Java, your choices were to call Python over HTTP, vendor-specific JNI bindings, or accept that some workloads just weren’t a Java problem.
Project Babylon, an active OpenJDK project led by Oracle Library Architect Paul Sandoz, is quietly dismantling that assumption. And in 2026, it’s doing so in a very concrete way.
The chart below frame both where we are today — in terms of real performance numbers from TornadoVM benchmarks — and where Project Babylon is heading on its development roadmap. Now let’s walk through the full story.
1. What Is Project Babylon, Really?
At its core, Babylon’s primary goal is to extend the reach of Java to foreign programming models such as SQL, differentiable programming, machine learning models, and GPUs. OpenJDK The mechanism it uses to achieve this is called code reflection — and it’s worth understanding what makes that different from the Java reflection you already know.
Standard Java reflection lets you inspect a class at runtime: what fields it has, what methods it exposes, what annotations are present. That’s useful, but it tells you nothing about what the code inside a method actually does. You can see that a method called computeGradient exists, but you can’t look inside it and see the mathematical operations it performs.
Code reflection changes that entirely. In the context of Babylon, a code model is a representation of a program — for example, a Java method — that is produced by the javac compiler and stored in the class file. Babylon’s enhanced reflection API empowers developers to access and manipulate these code models at runtime, enabling metaprogramming directly within Java.
In even plainer terms: Babylon lets Java see its own source-level intent — not just compiled bytecode — and use that symbolic description to do something completely new with it. Translate it to GPU kernel code. Differentiate it mathematically. Convert it to SQL. The same underlying mechanism serves all of those goals.
2. The Missing Piece: Why Bytecode Wasn’t Enough
To understand why this matters, it helps to know why existing approaches fell short. Java bytecode is a well-understood, stable format — but it’s an optimised representation. By the time the compiler is done, a lot of the original programmer intent has been erased. Variable names are gone, high-level constructs have been flattened, and the mathematical meaning of a computation is no longer visible.
Consequently, access to Java code in symbolic form has been currently limited to the use of non-standard APIs or to conventions at different points in the program’s life cycle, and the symbolic forms available — abstract syntax trees or bytecodes — are often ill-suited to analysis and transformation.
This is precisely the gap that code reflection fills. A method annotated with @CodeReflection produces a model that sits above bytecode — closer to what the programmer wrote, with the structural and type information that makes it amenable to transformation. A GPU backend can then walk that model, recognise the computational structure, and emit the appropriate GPU code. All from a Java library. No separate tools. No separate source files.
3. HAT: The GPU Layer Built on Top of Babylon
The most tangible demonstration of Babylon’s capabilities is the Heterogeneous Accelerator Toolkit (HAT), developed alongside the core project.
HAT is a parallel programming framework that allows Java developers to offload Java code and dispatch the generated code on modern hardware accelerators such as GPUs. HAT can be used to speed up massive parallel workloads such as deep learning, AI, big data analytics, and physics simulations by automatically offloading and running these workloads on specialized hardware. OpenJDK
The compilation pipeline is elegantly simple compared to what came before. A developer annotates a method with @CodeReflection. The javac compiler generates the code model and stores it in the class file. At runtime, HAT reads that model, lowers it through a series of transformation stages, and produces GPU-native code — OpenCL C, CUDA PTX, or SPIR-V — which the GPU driver then compiles to a final binary. No JNI. No C. No separate GPU source files to maintain. Java Code Geeks
As of early 2026, HAT supports OpenCL and CUDA backends with SPIR-V under active development.
4. The Use Cases: Far Wider Than Just GPUs
One of the most underappreciated aspects of Babylon is that GPU programming is actually just the proof of concept. The same code reflection mechanism unlocks several other use cases that enterprise Java teams will find immediately relevant.
| Use Case | What Babylon Enables | Status |
|---|---|---|
| GPU kernel offload | Write parallel Java → compiled to OpenCL/CUDA | Active (HAT) |
| Automatic differentiation | Java methods mathematically differentiated for ML training | PoC demonstrated |
| LINQ-style queries | Lambda expressions translated to SQL/query languages | PoC demonstrated |
| ONNX/LLM inference | ONNX model graphs executed via Java code models | PoC demonstrated (Nov 2025) |
| Differentiable programming | Gradients computed from plain Java functions | Research prototype |
The ONNX angle is particularly interesting for enterprise teams. A November 2025 inside.java article demonstrates using Babylon to run ONNX-based generative AI models in Java, with code models providing the bridge between Java’s type system and ONNX’s computational graph format. For organisations that want to run LLM inference inside their existing Java infrastructure — rather than spinning up a Python microservice — this is a genuinely new path.
Meanwhile, Project Babylon enables developers to build and run AI models such as LLMs, image classifiers, or object detection algorithms directly in Java. With code reflection, machine learning logic can be defined in plain Java code, eliminating the need for Python or external model files.
5. Where Things Stand in 2026
It’s important to be honest about the timeline here, because Babylon is genuinely exciting — and also genuinely not yet production-ready as a standard JDK feature.
For Project Babylon, 2026 plans include incubating code reflection, which allows third-party frameworks to reflect over Java code in a lambda expression and process it. The Babylon team is also working on proofs of concept for using code reflection to run machine learning models on the GPU.
The API lives in the jdk.incubator.code module. Compilation and execution of dependent code requires that this module be made visible by explicitly adding it to the list of modules, for example with the command line option --add-modules jdk.incubator.code. In other words, it’s available to experiment with today, but it requires opting in deliberately.
Babylon is not shipping in JDK 26 or 27. The project leadership has explicitly stated delivery will happen via a series of JEPs across multiple feature releases. This is a very deliberate approach — the team wants to get code reflection right before formalising it through the JEP process. Given that code reflection is a foundational primitive on which many future capabilities will be built, that caution is well justified.
6. TornadoVM: The Production Bridge Right Now
Because Babylon is still incubating, the practical question for teams that need GPU acceleration in Java today is: what do you use in the meantime?
The answer is TornadoVM, which reached version 2.0 in December 2025. TornadoVM automatically accelerates Java programs on multi-core CPUs, GPUs, and FPGAs. This release is of particular interest to teams developing LLM solutions on the JVM.
The performance numbers are striking. When running on GPUs, TornadoVM can achieve up to 39× and 270× speedup compared to sequential Java for Intel HD Graphics and NVIDIA GPUs respectively. InfoQ The chart below shows real benchmark figures from a matrix multiplication workload at the JVM Advent 2025.
TornadoVM offers two complementary ways to express parallelism: the Loop Parallel API, which uses Java annotations such as @Parallel and @Reduce to parallelize loops, and the Kernel API, which provides explicit GPU-style programming with concepts such as thread IDs, local memory, and barriers — similar to CUDA and OpenCL.
The relationship between TornadoVM and Babylon is complementary rather than competitive. TornadoVM, shipping today with up to 270× speedups over sequential Java and full LLM inference support, shows that Java GPU programming is already real — Babylon wants to make it standard platform infrastructure rather than a sophisticated plugin. Java Code Geeks TornadoVM solves the production problem now. Babylon solves it at the platform level, for every Java developer, without requiring a specialised framework.
7. What This Means for Enterprise Java Teams
The practical implication of all this research is something quite significant: the long-held assumption that Java is not a serious language for ML or GPU-accelerated workloads is starting to look outdated.
For teams building microservices in Java who currently call a Python ML service over HTTP, Babylon and TornadoVM together represent a realistic path to collapsing that boundary. Model inference could live in the same JVM process as the business logic that uses it. Gradients for on-device learning could be computed from plain Java methods. ONNX models could be loaded and run without a runtime language switch.
That said, it’s equally important to have realistic expectations. Babylon’s incubation is a genuine signal of forward momentum, but what exists today is a development branch that tracks mainline, active research prototypes, and a growing body of published demonstrations. Teams should watch the project closely — particularly the talks at JVMLS and JavaOne, which have consistently been the best windows into where the project is heading — but should not design production systems around Babylon APIs that are still evolving.
The right posture in 2026 is to experiment with Babylon today (using --add-modules jdk.incubator.code), run production GPU workloads on TornadoVM, and keep an eye on when the first formal JEPs from the Babylon project land.
8. What We’ve Learned
Project Babylon is one of the most architecturally ambitious things happening in the OpenJDK ecosystem today. Its core innovation — code reflection — gives Java the ability to reason about its own source-level intent for the first time in a standardised, platform-native way. Built on top of that foundation, the Heterogeneous Accelerator Toolkit (HAT) provides a pure-Java path to GPU kernel execution without C, JNI, or separate GPU source files, while ONNX-based ML inference prototypes demonstrate that running AI models natively in Java is no longer a thought experiment.
In 2026, the project is in active incubation, with GPU ML proof-of-concepts under development and a formal JEP process expected across multiple future releases. TornadoVM 2.0 bridges the gap for teams that need production-grade GPU acceleration today. Together, they paint a picture of a JVM platform that is seriously, methodically closing the gap with Python on machine learning — not by copying Python’s model, but by extending Java’s own strengths.
