Minecraft server crashes after adding mods? Read the error, then pick the right Java runtime
Minecraft server crashes after adding mods? Read the error, then pick the right Java runtime
Last updated 2026-08-13
Short answer
A line reading UnsupportedClassVersionError or class file version 61.0 means the mod or loader was compiled with a newer Java than the one your server is running on. The cause: Java is picked from the Minecraft version number, which is only correct for vanilla — mod loaders and modpacks have their own requirement that the game version cannot express. The fix: take the class file number from the error and subtract 44 to get the Java version it wants (61 minus 44 = Java 17), switch the server to that Java, then start it again.
Steps at a glance
Read the console error and confirm it is a Java problem
Find the Java version your modpack or loader needs
Switch to the Java runtime the loader wants
Restart the server and read the console again
Contents
Contents
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:
Number in the error
Java
52.0
Java 8
55.0
Java 11
60.0
Java 16
61.0
Java 17
65.0
Java 21
69.0
Java 25
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:
Minecraft version
Java the system picks
Year-style (26.x) and LATEST
latest — needs Java 25 at minimum
1.20.5 – 1.21.x
java21
1.17 – 1.20.4
java17
1.16.5 and below
java8
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:
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.
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.
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:
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:
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, and find the Java runtime field (it sits right after JVM performance flags), then save. 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.
Server stuck in a boot loop — Restart does not work (it only acts on a server that is genuinely running). The banner at the top swaps that button for Stop instead: stop first, then 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
Situation
What to choose
Vanilla, Paper, Purpur — no client-side mods
Auto
Fabric or Quilt on an older Minecraft
Auto — the system already raises it to java17
A modpack from CurseForge / Modrinth
Whatever the pack page states; the system cannot see the loader inside a pack
Old Forge, for example on 1.12.2
Auto (java8) — do not raise it without a concrete reason
Chasing extra performance
The GraalVM variant of the same number — not a fix for a version error
You genuinely need older than Auto picked
Allowed, but you must tick the warning's confirmation first
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.
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.
Frequently asked questions
Can I just pick the newest Java and be done?
It is not a universally safe shortcut. A Java newer than the mod asks for usually does run, but very old Minecraft versions can fail on the newest JVM too — which is exactly why Auto still picks java8 for 1.16.5 and below. The warning in the settings card only covers the direction that is provably fatal, meaning picking older than required. Silence in the other direction is not a promise that anything newer is safe.
Why does picking an older runtime warn while picking a newer one stays silent?
Because only one direction is provable from the numbers alone: a class file newer than the JVM knows is rejected the moment the class loads, every time. Picking a newer runtime is the case this feature exists for — Fabric on 1.16.5 needs a Java newer than the game version implies — so that direction is silent by design. Neither direction is ever blocked; the warning just asks you to tick a confirmation.
Do I have to pick Java again every time I change the Minecraft version?
No. An explicit pick stays with the server across version changes, because an explicit pick always beats Auto. The side effect is that a pick made for an old version can become too old after an upgrade; the warning is recalculated against the new version and shows up next time you open the settings card. If you are no longer sure the pin is needed, switching back to Auto is the safest answer.
Does a plain vanilla server need this setting at all?
No. The automatic table is built from what vanilla Minecraft itself requires, so an unmodded server already matches Auto. This setting exists for the cases where a mod loader or a modpack wants a different Java than the game version implies.
Does changing the Java runtime affect my world or saves?
No. Changing Java changes only the program that runs the server — it does not touch world files or any configuration. That is why no backup is forced before the change, and why the new runtime takes effect on the server's next start rather than the moment you hit save.