Minecraft Java, Compiled Native | From QuestCraft to Xbox

TL;DR

I compile Minecraft: Java Edition ahead of time into a native executable with GraalVM, no JVM at runtime, and it runs modded on an Xbox One and an Xbox Series S. Vanilla, Fabric and Forge all work, and the tool that builds it, MCNativeBuilder, is open source.

I'm Cole Roberts, known as Judge in the modding community. I've been working on this since 2023, mostly in my spare time. This post covers how it started, how it works, and where it's going.

How it started

It started with QuestCraft, the project that runs Minecraft Java on Meta Quest headsets. I was its lead developer, current project lead, and in 2023 I went looking for ways to make it run faster on mobile hardware. Compiling the game ahead of time with GraalVM native-image looked like the biggest possible win.

Two things changed my plans. First, a native image bakes Mojang's code into the binary, so I couldn't ship it to QuestCraft players. Second, I realized the idea was much bigger than one headset. If Minecraft could run without a JVM, it could run almost anywhere that has a C compiler and a graphics driver.

The first build: "you can't have done that"

On October 8, 2023, I had a working native Minecraft 1.20.2 client: a single 553 MB executable. I posted it in the technology channel of the CaffeineMC Discord, home of the Sodium optimization mod.

The first replies were skepticism from well-known developers in the Fabric performance scene. That was fair: everyone knew native-image and Minecraft didn't mix. I answered with proof, technical explanations and sources, and that conversation is part of why I kept going.

How it works: vanilla and Fabric

GraalVM native-image compiles Java ahead of time under a closed-world assumption. Every class, method and reflective call must be known at build time, because there's no JIT and, traditionally, no loading new classes at runtime.

Vanilla was the easy part. I ran the game with GraalVM's tracing agent, which records every reflection, resource and JNI access as the game runs. That metadata was enough to get a working native client.

Modded was the real problem. Fabric is built on runtime class loading. Its Knot class loader loads mod classes and applies Mixin transformations on the fly. SubstrateVM, the runtime under native-image, didn't support that at the time.

My solution was to move all of that to build time:

1. Run Knot during the image build, so every mod class is loaded and every Mixin transformation is applied.
2. Bake the fully transformed classes into GraalVM's image heap, the snapshot of objects that ships inside the binary.
3. Let GraalVM's points-to analysis scan that heap, so the closed-world analysis sees modded code exactly as it would run.

The result was my first native Fabric builds, with mods, and no class loading at runtime.

Getting it onto Xbox

Once the game was a native binary, an Xbox port became a porting problem, not a Java problem. Xbox runs UWP apps in Dev Mode, has no JVM and speaks Direct3D, not OpenGL. I compiled the game as a native DLL and wrote a barebones UWP launcher that just loads and calls it.

The hard part is graphics. Minecraft expects desktop OpenGL, so each console needs a translation layer underneath a modified GLFW:

On the Series S, Fabric 1.21.11 runs at 1080p around 82 FPS, using about 700 MB of a 4 GB heap, while connected to a Folia server. My earlier posts on r/XboxHomebrew show both consoles in action: Xbox One and Series S.

Forge and servers

Forge took about a year. I was working full-time, so this happened on nights and weekends. As of last week I have a working native Forge server, and it will host the official Legends Mod Megaverse server.

My current test build runs Arclight 1.20.1, a Forge server that also loads Bukkit plugins, with 16 mods and 31 plugins:

At 80 players the native server stays under the 50 MSPT budget for a full 20 TPS. The same setup on HotSpot needs about 200 MSPT per tick, which drags the server down to roughly 5 TPS.

Startup is faster too: the native Forge server is up in about 24 seconds, compared with roughly 1 minute 15 seconds on the JVM.

Folia and Purpur run natively too, with plugins. These ports aren't public yet, so I'll keep the details short. Carefully placed reflection metadata, the right command-line flags and runtime class loading for plugins get Bukkit-style plugins working in a native server. With GraalVM's recent G1 and Metaspace improvements, they're already well ahead of HotSpot in my testing.

Performance

The biggest jump I've seen is on Android: upwards of 500 FPS natively, even through a graphics wrapper, where the regular JVM build struggles to reach 100 on the same device. My theory is that HotSpot's JIT emits more instructions on ARM than on x86, so ahead-of-time compilation helps most there.

Try it yourself

You can build a native client today with MCNativeBuilder: point it at a GraalVM install and a Minecraft version, and it produces an executable. Be warned that the build needs a lot of RAM (about 20 GB on Linux, and more on Windows, which uses more memory by default).

Why no downloads? A native image contains Mojang's code, and the Minecraft EULA doesn't allow redistributing it. That's why the builder compiles from your own copy of the game. If Mojang were open to it, I'd happily distribute builds with proper license checks.

What's next, and how you can help

Next up is optimization and stability, so native builds become something people can rely on, not just a demo.

The most useful thing you can do is share this. Awareness is what I need most right now: post it, send it to a modder, server owner or JVM nerd you know, and star the repo or follow the MCNative Team on GitHub.

If you can support the work financially, Ko-fi keep me working on this. If you run a server network or hosting company and want to talk about native servers, reach me at colepatrickroberts@gmail.com, or find me as thejudge156 on Discord and X.