Guidefor server owners3 min read
Fixing java.lang.UnsupportedClassVersionError
The exact numbers in this error tell you which side is too old and which class file is too new, before you even open a config file. How to read it, and the fix for each of the two shapes it comes in.
Read the numbers before you do anything else
The full error names two numbers, and they tell you exactly what is mismatched without guessing:
Exception in thread "main" java.lang.UnsupportedClassVersionError: net/minecraft/server/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
69.0 is the class file's own version, set by whatever Java compiled it. 65.0 is the highest version the JVM trying to run it understands. The class file is newer than the runtime, always, in this exact error. It is never the other way around: a runtime happily loads older class files, so this specific message only ever appears when the file is ahead of the runtime, not behind it.
Class file versions are not the same numbers as Java's own version names. They are offset:
| Class file version | Java version |
|---|---|
| 52.0 | Java 8 |
| 55.0 | Java 11 |
| 61.0 | Java 17 |
| 65.0 | Java 21 |
| 69.0 | Java 25 |
The Java version checker converts this for any Minecraft version directly from Mojang's own metadata, so you do not have to do the arithmetic by hand.
The two shapes this error actually comes in
The game or server itself is too new for the runtime. You downloaded a Minecraft server or client build that requires a newer Java than what you have installed, or than what your start script is actually calling. Why Minecraft 26 needs Java 25 covers this exact case for the current requirement floor, including the specific trap of installing a newer Java without pointing your start script at it.
A plugin or mod is too new for the server running it. The server itself starts fine and runs on the Java version it needs, but a specific plugin or mod was compiled targeting a newer Java than the server provides, and fails to load with this same error the moment the server tries to load that one jar. This is the same underlying rule, one level down: a build tool set to target Java 25 while the server that will load the plugin still runs Java 21 produces exactly this error at plugin load time, not at server startup. What breaks a Paper plugin on a new drop covers the developer side of avoiding this.
Telling the two apart is the class name in the error. If it names the server's own main class, the server itself is the mismatch. If it names a plugin or mod class, that one jar is the mismatch and the rest of the server is unaffected.
The fix, either way
- Confirm what's actually running.
java -version, in the exact terminal, script, or panel context that launches the thing failing, not just anywhere on the machine. A second, older Java install elsewhere is the single most common cause of this error persisting after an update. - If the server itself is the mismatch, install the runtime the error names and point your start script or panel's Java selector at it explicitly.
- If one plugin or mod is the mismatch, either upgrade the server's runtime to meet what that plugin needs, or replace the plugin with a build compiled for your current runtime, if the plugin author has published one. Upgrading the whole server's runtime is usually the less disruptive choice, since it very rarely breaks something that already worked.
- If you are the one compiling the jar, set your build tool's target Java version to match what the servers running your plugin actually use, not the newest Java you happen to have installed. Maven and Gradle coordinates for Paper shows the toolchain setting that controls this.
