Opt-in way to start the patched server on the app class path, so JDK 25's AOT cache can hold it

[u9g]

What

Paperclip starts the server from a URLClassLoader over the patched jars (Paperclip.main). JDK 25's AOT cache (JEP 483, JEP 514) only caches classes loaded by the JVM's built-in loaders. So a cache recorded through Paperclip holds none of Minecraft's or Paper's classes. The training run skipped all 12,520 of them:

[warning][aot] Skipping net/minecraft/world/level/block/TntBlock: Unsupported location
... (12,520 lines)

Started from the same patched jars on the app class path, the same cache cuts startup by about a third.

Numbers

Paper 26.2-124, Temurin 25.0.4+7, -Xms1G -Xmx1G, a fresh world each start (level-seed=1), on an 8-core Linux box. Time from java to Done (:

Start	Time to Done
java -jar paper.jar (Paperclip), as today	13.3s
app class path, no cache	12.1s
app class path, -XX:AOTCache=paper.aot	7.9–8.7s

The cache was recorded with -XX:AOTCacheOutput=paper.aot on one start that ran to Done and was then stopped. It's about 195MB.

How we got Paper onto the app class path

We ran -Dpaperclip.patchonly=true into a bundlerRepoDir. Next to it we put a manifest-only jar, Main-Class: org.bukkit.craftbukkit.Main, whose Class-Path lists versions/… and then libraries/…, in the order META-INF/versions.list and META-INF/libraries.list give. The paths are relative to the jar, so the folder can move. Then:

java -XX:AOTCache=paper.aot -jar <repo>/launch.jar --nogui

Our server images now start this way, with a plugin loaded, and pass our start-up checks. The class-path order is the same as Paperclip's, versions first, as setupClasspath requires.

Two things we learned that a user would need to know:

• The JVM checks every class-path jar's size and modification time against the cache. If anything differs, for example after a repatch, it prints [error][aot] … timestamp has changed and starts without the cache. So a stale cache fails safe, just slower.
• A cache recorded with the JDK and the jars at other paths still works when they're moved, as long as their relative layout and times are the same. We record ours at image build time.

Proposal

An opt-in, leaving the default launch alone. For example, while patching Paperclip could also write launch.jar (as above) into the bundlerRepoDir, perhaps only when asked with a system property. Anyone wanting the AOT cache would then run that jar instead of paper.jar.

This keeps what #35 was after: the server loaded as if started with plain java -jar, on the JVM's own loader. It would also sidestep the service-loader problem in #66, since the app loader is the parent there.

If a Paperclip-side change isn't wanted, a short note in the readme on doing this by hand with paperclip.patchonly would still help people on Java 25.

I'm happy to open a PR for whichever shape you prefer.

[MiniDigger]

if you want look into AOT, I would suggest skipping paperclip and using https://github.com/PaperMC/tack

[u9g]

Thanks, we tried tack. For our setup it comes out slower than the manifest-jar approach from the issue, so we're staying on that for now. The details, in case they're useful:

Paper 26.2, -Xms1G -Xmx1G, a fresh world each start (level-seed=1), on an 8-core Linux box, three runs each. tack 0.1.1-beta with Temurin 26.0.2.1; the cache recorded with tack --only-record -Xmx1G -Xms1G -jar paper.jar --nogui (34s).

Start	Wall time to Done (	Paper's Done (…)
launch.jar + -XX:AOTCache, JDK 25	8.3–8.6s	7.8–8.0s
tack --no-record, JDK 26	9.7–10.5s	7.4–8.3s
tack --no-aot, JDK 26	13.5s	12.7s

The cache does as much under tack as without it. The difference is before the JVM starts: tack hashes the 214MB paper.aot and every classpath jar on each start, and the jars twice (once against versions.list/libraries.list in setup_classpath, again in AotMeta::build). tack --check-aot alone takes about 2.1s. We record the cache when the server image is built, and the image never changes after that, so for us that check is pure cost.

Other things we ran into:

• Recording ran out of memory in a 2Gi container. create_aot_cache starts a second JVM while the server is still up. It recorded fine at 4Gi.
• The image we build on (itzg/minecraft-server) has no Java 26 variant yet, so we'd have to ship a second JDK next to its 25.
• The meta requires the JVM args to match exactly, so the recording has to reproduce whatever the start script passes.
• tack wants the Mojang jar in .paper/cache/ and copies it there from cache/ if it isn't. Since Paperclip uses cache/, we'd ship it twice.

One bug: err_ctx wraps Error::Exit, so the early exits in check_aot_opt come out as exit code 1. --check-aot on a valid cache prints Failed to check AOT cache / Caused by: Exiting with code 0 and exits 1. --require-aot on a bad cache exits 1 rather than 33, and --only-record on a good cache exits 1 rather than 0.

If a way to skip re-hashing, or to trust size and mtime as the JVM does, would be welcome in tack, I'm happy to open a PR there.