Minecraft: change the Java versionWhich Java version belongs to which Minecraft version

Published on October 20, 2026

Which Java version do I need?

Mojang has raised the requirement several times. The mapping for vanilla and Paper servers:

The table shows the minimum in each case. A newer Java version is usually no problem with vanilla and Paper - with mod loaders, not always; more on that below.

Do not be confused by the number: since 2026, Mojang numbers versions following the pattern year.drop.hotfix. So 1.21.11 was not followed by 1.22 but by 26.1 (March 2026), then 26.2 and so on. All versions of this new numbering so far require Java 25; the Minecraft launcher brings the right runtime for players itself, and for the server you set it as described below.

Recognize the error message

If Java is too old, the start aborts immediately. The log says:

java.lang.UnsupportedClassVersionError: net/minecraft/server/Main
has been compiled by a more recent version of the Java Runtime
(class file version 65.0), this version of the Java Runtime only
recognizes class file versions up to 61.0

The numbers are readable: class file version 61 corresponds to Java 17, 65 to Java 21 and 69 to Java 25. The first number is therefore the required version, the second the one available. Anyone who upgrades a server from 1.21.x to 26.1 or newer and keeps Java 21 sees exactly this message with 69.0 as the required version. Where to find the log is explained in Server does not start.

Switch the Java version

The Java version is part of your server's Docker image. You will find the selection in the web interface under Startup, to the right of the start command. Procedure:

1. Stop the server - a change during operation does not take effect.
2. Go to Startup in the web interface.
3. In the Docker Image field, choose the matching Java version, such as "Java 21" or "Java 25".
4. Restart the server.
5. Check in the console that the start runs through to "Done".

On the same page, under Server Variables, you will also find the jar file and the Minecraft version - that is where you change the game version, not the Java version. One has nothing to do with the other, but they are often confused.

The start command itself does not need to be touched: memory is taken proportionally from the plan via -XX:MaxRAMPercentage, so there is no fixed -Xmx to maintain.

Before bigger jumps, backing up the world is worthwhile - how that works is explained in Create backups.

If the start still fails afterwards

Not every error after a Java change is a version problem again. Three messages come up regularly and mean completely different things:

• Unrecognized VM option or Could not create the Java Virtual Machine - the start command contains a parameter that the selected Java version no longer knows. Older flag collections from forums like to select a garbage collector that no longer exists in current Java versions. The parameter has to go, not the Java version back.
• NoClassDefFoundError or NoSuchMethodError when loading a plugin - here, an extension accesses something that does not exist in this combination. That is almost never down to Java, but to a plugin or server version that does not match the Minecraft version.
• The server starts but stops before "Done" - then it is running on the new Java version and hangs somewhere else. The usual causes are collected in Server does not start.

The big advantage over other changes: a Java change can be undone without consequences. Simply set the previous image again in the Docker Image field - world, plugins and configuration are not affected. That is the quickest test if a modpack refuses to work after the change, and the essential difference from changing the Minecraft version, where the world is converted and there is no way back.

Specifics with Forge, Fabric and modpacks

With mod loaders, "newer is better" is not automatically right:

• Forge for older versions is sensitive to Java versions that are too new. A Forge server for 1.12.2 expects Java 8; under Java 17 or 21, it usually does not start at all.
• Modpacks almost always state the expected Java version on their CurseForge or Modrinth page. That information takes precedence over the table above.
• Fabric usually follows the requirement of the respective Minecraft version.

Rule of thumb: with vanilla and Paper, go by the Minecraft version; with a modpack, by its own information. More on the loaders in Forge and Fabric.

Java version, memory and performance

A jump from Java 8 to a current version brings a more modern garbage collector along the way. It cleans up in smaller steps, making the short freezes that stand out as regular stuttering on old versions less frequent. It is not a cure-all: anything caused by too little memory, too high a view distance or an overloaded farm remains even under the newest Java version.

The change does not affect memory allocation. Because the start command takes memory proportionally from the booked plan via -XX:MaxRAMPercentage, there is no fixed -Xmx that would need adjusting after a Java change. How much your project actually needs is explained in How much RAM does a server need? - and if the tick rate drops despite a matching Java version, Improve lag and TPS walks you through finding the cause.

• Vanilla and Paper: use the Java version the server software recommends for the Minecraft version in use.
• Modpacks: the pack's information beats any general recommendation - see Install a modpack.
• When in doubt, leave it unchanged. If the server runs stably, a Java change without a reason is not an optimization step, just another moving part.

Frequently asked questions