Minecraft server crashes after adding mods? Read the error, then pick the right Java runtime

You install a mod or a modpack, start the server, and it dies on its own a few seconds later — even though the Minecraft version matches exactly what the mod asked for. Almost every time, this is not a wrong-version mod. It is the server running on a different Java than the mod needs. The good news: the error prints the number you need, right there in the console. You just have to know where to look.

The server dies quietly — read the console before guessing

Read the console error and confirm it is a Java problem

Scroll the console (or open logs/latest.log) back to the first red line, the one starting with Exception. If it looks like this, the whole article applies:

Exception in thread "main" java.lang.UnsupportedClassVersionError: some/mod/loader/MainClass has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0

The class name at the front changes with whatever loader or mod tripped it. The two numbers are what matter:

• class file version 61.0 = the file being loaded was compiled with that Java
• up to 52.0 = the Java actually running right now only understands up to that one

In plain terms: the thing being loaded is newer than the thing loading it, so Java refuses before the world ever starts loading. This is not a broken mod, it is not low RAM, and adding RAM will not help.

Both numbers convert back to a Java version by subtracting 44:

So the example above reads: "this wants Java 17, but the machine is running Java 8." Your numbers may be a different pair — apply the same subtract-44 rule to whatever you see.

To confirm you are in the right article: seeing UnsupportedClassVersionError is conclusive. If instead the server "just closes with no long error", find logs/latest.log and read it there — a console window that closes itself usually takes the important line with it.

Why the system can pick the wrong Java

A Minecraft server does not ship with Java inside it. It has to be run by a Java installed separately. And when something has to guess which Java a given server should use, the only thing available to guess from is the Minecraft version number. On uniz.host that table looks like this:

That table is correct for vanilla, because it reflects what the game itself needed in each era. The problem is that a mod loader is not compiled for the game's era — it is compiled for the loader's own era.

The classic case is Fabric on Minecraft 1.16.5. The game version dates from the Java 8 era, so the table picks java8 — but the current Fabric installer is compiled for Java 17. The server crashes the instant it boots, with exactly the error above, while the game version was "correct" the entire time. That is where guessing from the version number alone breaks down, and it is the reason a manual choice has to exist.

On uniz.host this specific case is now handled automatically (since 12 Aug 2026): if the server runs Fabric or Quilt, Auto raises the floor to java17 on its own, even on 1.16.5. But when you run the server yourself at home, nothing raises anything for you — you have to pick the right Java by hand. So this case is still very much alive outside a host.

That floor deliberately covers Fabric and Quilt only, not "all modern loaders", because old Forge (on 1.12.2, for instance) genuinely requires Java 8. Raising Java for it would break servers that run perfectly well today. That asymmetry is precisely why no single blanket rule is safe for every loader.

And one group cannot be raised automatically at all: modpacks from CurseForge or Modrinth. A pack's real loader lives in the manifest file inside the pack, not in the "server software" field the system can see. Modpacks are therefore the main case that still needs a manual pick today.

The fix: run the Java the loader actually asks for

Find the Java version your modpack or loader needs

Three trustworthy sources, most reliable first:

1. The number in the error itself — the most accurate, because the JVM read it out of the real file. Subtract 44 from the class file version and you have the answer immediately.
2. The modpack's own page — almost every substantial pack states its Java requirement in the description or a requirements section. This is authoritative because the pack author sets it.
3. The loader's download page — Fabric, Forge and NeoForge each document which versions they support.

What you should not do is infer it from the Minecraft version number — that is the reasoning that led here in the first place. If none of the three sources gives you an answer, trust the number in the error.

Switch to the Java runtime the loader wants

Running it yourself on Windows: Java is a free download from adoptium.net (the package is called Eclipse Temurin) — pick the version number you need. You can keep several versions installed side by side; there is no need to uninstall the old one, since each lands in its own folder.

After installing, open a fresh Command Prompt and run java -version. Whatever prints there is what your server will actually get. What decides which java runs is PATH, not the JAVA_HOME variable. If the printed version is not the one you just installed, the machine has several Javas and PATH still points at an old one.

The surest route skips PATH entirely and calls Java by its full path in the start command:

"C:\Program Files\Eclipse Adoptium\jdk-17.0.13.11-hotspot\bin\java.exe" -Xmx4G -jar server.jar nogui

The version numbers in that folder name change with whatever you downloaded — run dir "C:\Program Files\Eclipse Adoptium" to see the real folder on your machine and substitute it. (-Xmx is the RAM ceiling; how much to give it is covered in the article on game server RAM.)

Running it yourself on Ubuntu/Debian: install the version you need, then switch which one the system calls:

sudo apt install openjdk-17-jre-headless
sudo update-alternatives --config java

Or skip the switching and use the full path, same idea as on Windows: /usr/lib/jvm/java-17-openjdk-amd64/bin/java. That folder name varies by version and machine architecture, so check what is really there with ls /usr/lib/jvm before using it.

On uniz.host: open the server page, go to the Settings tab, open the Version and performance group, and find the Java runtime field in its Java section (it sits just above JVM performance flags). Once you pick, a save bar appears at the bottom of the group: press Save, or, while the server is running, Save and restart to do both at once. Things worth knowing before you pick:

• The first option is Auto, and its label tells you what Auto currently resolves to — for example "Auto — java17 (recommended)". That label accounts for both the game version and the server software, not the game version alone.
• The remaining options are the runtimes themselves: java8, java11, java16, java17, java21, java25, java17-graalvm, java21-graalvm, java25-graalvm and latest.
• Picking older than what Auto chose raises a warning with a confirmation checkbox; without ticking it, the save is refused. Picking newer is completely silent, on purpose — that is the main case this feature exists for.
• The GraalVM variants are a performance option, not a fix for this error: java17-graalvm accepts exactly the same class files as java17. If java17 does not fix it, neither will its GraalVM twin.
• java8, java17, java21 and latest are pre-loaded on our machines. The rest (java11, java16, java25 and all three GraalVM variants) are not, so the first start after switching to one of them can take a few extra minutes while the image downloads.
• The field stays editable in every state, including while the server is stuck in a boot loop — a wrong pick is always reversible, and you cannot lock yourself out.
• Changing Java touches no world files, which is why no backup is forced, and the new runtime applies on the server's next start rather than the moment you save.

Restart the server and read the console again

The new setting does nothing until the server starts a fresh run:

• Server running normally — press Restart in the server's header (skip this if you already pressed Save and restart).
• Server stuck in a boot loop — there is no Restart button to press (it only acts on a server that is genuinely running). The server's header offers Stop instead: stop first, then press Start again.
• Running it yourself — type stop in the console if it still accepts input, or close the window, then run your start command again — making sure that command really points at the Java you just switched to.

Then read the new console output. There are three possible results:

• It gets past the old crash point and reaches the Done line — finished, the server is up.
• A different error appears — that is progress. The Java problem is solved and what remains is something else (conflicting mods, a bad config file, and so on). Read the new error on its own terms.
• The exact same error with the same numbers — Java did not actually change. On a host, check whether the server really started a new run; running it yourself, check java -version in the window you launch from, or switch to calling Java by full path.

Quick pick table

One rule covers every row: the class file number in the error is always the truth. When a table and an error disagree, believe the error.

Read next

• Never run a server before? Start with how to run your own Minecraft server, from zero to friends joining.
• Server boots but stutters? Check game server RAM before blaming Java — different symptoms, different cause.
• Want to run a modpack without handling Java yourself? See the Minecraft page.