Fix "UnsupportedClassVersionError" / Wrong Java on a Minecraft Server
Unsupported class version Minecraft server Java error means your JDK is older than the jar needs. Decode the class file number and install the matching Java.
"UnsupportedClassVersionError" means the jar you're launching was compiled with a newer Java than the one running it, and the number in the error tells you exactly which JDK to install: find the "class file version" it names, subtract 44, and that's your Java version. Class file version 69.0 means the jar wants Java 25; 65.0 means Java 21; 61.0 means Java 17 — so you stop guessing and grab the one number the jar is asking for. It's one specific flavor of a server that dies on startup, and unlike the grab-bag of reasons covered in why a Minecraft server keeps crashing, this one has a single cause and a single fix.
Read the whole error, not just the first line
Most people copy the top line, panic, and stop reading. The full string is where the answer lives:
java.lang.UnsupportedClassVersionError: io/papermc/paperclip/Main has been compiled by a more recent version of the Java Runtime (class file version 69.0), this version of the Java Runtime only recognizes class file versions up to 65.0
Two numbers matter here, and they're doing different jobs. The first, 69.0, is what the jar was built with. The second, 65.0, is what you currently have installed and running. The error is simply saying "this file expects 69, I only speak up to 65." So 69.0 is your target and 65.0 is your problem.
Some older JVM setups print the same idea in a different shape: Unsupported major.minor version 52.0. Same meaning, older wording — the 52.0 there is the class file version the jar wants. Either way, this crash happens at launch, before the world ever loads. You'll see it in the console the moment the process starts, not five minutes into gameplay, which is a useful tell that you're looking at a Java mismatch and not something in the world data.
Turn the number into a Java version (subtract 44)
The class file version is 44 higher than the Java major version, always, so you just subtract. Here's the table you actually need:
- Java 8 → class file 52
- Java 11 → class file 55
- Java 17 → class file 61
- Java 21 → class file 65
- Java 22 → class file 66
- Java 23 → class file 67
- Java 24 → class file 68
- Java 25 → class file 69
So 69.0 → 69 − 44 = Java 25. 65.0 → Java 21. 61.0 → Java 17. Memorize the arithmetic and you never have to look this up again.
One thing worth saying plainly: this error always points you newer, never older. UnsupportedClassVersionError only fires when the jar was compiled with a higher Java than your runtime — a jar built for Java 21 will happily run on Java 25, so the reverse mismatch simply can't throw this. That means the fix is always "install a newer JDK," and downgrading Java to match the smaller number will only dig you deeper. For any Paper jar on the 26.x line, whichever drop is the current stable target for a plugin server, the decoded answer is Java 25 (class file 69), since 26.1, 26.2 and 26.3 all require it.
Check what Java you actually have
Run this in the same terminal you launch the server from:
java -version
Read the first line. openjdk version "21.0.3" means you're on Java 21, which is exactly what throws the error against a 69.0 jar. openjdk version "25.0.1" means you're on 25 and that particular jar should load.
Now the classic trap: you installed Java 25 last week, you're sure of it, and you still get the error. That's almost always PATH order. The old Java 21 is still listed first, so the shell keeps resolving java to it and never touches the 25 you added. On Windows, check the JAVA_HOME environment variable and confirm it points at the JDK you want. On Linux or macOS, run which java — it prints the actual binary that wins, and if that path says jdk-21 you've found your culprit. Having several JDKs installed side by side is completely normal and fine; the only thing that matters is which one the launch command resolves to.
Install the exact JDK the jar wants
If you genuinely don't have the right version, grab a free build. Any of these work and all are no-cost: Eclipse Temurin (from Adoptium), Azul Zulu, or Amazon Corretto. Pick the major version the error decoded to — for a modern Paper server that's Java 25.
Stick to the LTS releases. Server jars target 17, 21 and 25, so those are the safe picks. Don't grab a newer non-LTS release just because the number is bigger — a jar built for 25 runs on 25, and reaching for the newest release isn't the goal here. Matching is. A too-new JDK can introduce its own headaches without buying you anything.
Once it's installed, run java -version again and confirm the shell now reports the number you wanted before you relaunch the server. If it still says 21, you've hit the PATH problem from the last section, and the next section is for you.
Point your launch command at the right java (multiple JDKs)
When several Javas coexist and you're tired of fighting PATH, stop trusting java and call the full path to the binary directly in your start script. On Linux that looks like:
/usr/lib/jvm/temurin-25-jdk/bin/java -Xms4G -Xmx4G -jar paper.jar --nogui
That's the same launch line from setting up a Paper server, just with the ambiguous java swapped for an explicit binary path so there's zero doubt about which runtime starts. On Windows, do the same with the full path:
"C:\Program Files\Eclipse Adoptium\jdk-25\bin\java.exe" -Xms4G -Xmx4G -jar paper.jar --nogui
If you'd rather fix it system-wide on Debian or Ubuntu, sudo update-alternatives --config java lets you set the default java to your 25 install, and then plain java in scripts resolves correctly everywhere.
Running on a host control panel instead of your own box? Don't touch a script at all. There's almost always a Java version dropdown in the server settings — usually offering images like Java 17, 21 and 25. Flip it to 25 and restart the server. That's the whole fix on managed hosting.
When it's a plugin jar, not the server
Same error text, different offender. If the stack trace names a plugin class — something like .../SomePlugin.class — instead of io/papermc/paperclip/Main, then it's a plugin that was compiled against a newer Java than your server's runtime, and it blows up as it loads.
You've got two ways out. The better one is to raise the server's Java to match, because then the whole server benefits and every other plugin stays happy. The patch option is to download a build of that specific plugin compiled for the Java version you're already on. This shows up a lot right now: plugins recompiled for the 26.x line commonly jump to Java 25, so an old server JVM that ran fine for months suddenly chokes on a freshly updated plugin the first time it loads. If you're weighing whether to move the whole server up, the tradeoffs are laid out in 26.1 vs 26.2 for owners and 26.2 vs 26.3.
FAQ
Can I just downgrade Java instead of installing a new one?
No, and it'll make things worse. UnsupportedClassVersionError only fires when the jar is newer than the runtime, so moving to an older Java widens the gap. The one downgrade that actually helps is picking an older server jar that was built for the Java you already have — but for the 26.x line that older jar doesn't exist, so installing the newer JDK is the real answer.
My host installed Java 25 but I still get the error — why?
Because the panel is probably still booting an older Docker or Java image, regardless of what got installed. Change the Java version in the server's startup or settings dropdown to 25 and restart. Installing a JDK on the box doesn't change which runtime the container actually launches with — the dropdown does.
What Java version does a 26.1 Paper server need?
Java 25, which is class file version 69 — decode it and it's right there in any error you'd hit. 26.2 and 26.3 want the same Java 25, so a single Java 25 install covers the whole 26.x line, whichever build Paper currently marks as stable. You don't need anything newer.
The error names a plugin — how do I tell which one from the stack trace?
Read the class path in the error line and work backward from the package. com/example/coolplugin/CoolPlugin points at the vendor and the plugin name, so the jar in your /plugins folder with that same name is the offender. Cross-check it against the last [SomePlugin] Loading or Enabling line printed just above the crash — that's the plugin the server was mid-loading when it died. Once you've named it, open that plugin's download page and look for a build tagged for older Java; some projects still post a Java 21 legacy jar next to the current one, and swapping that in holds you over until you raise the server's own Java to 25.
