java.lang.UnsupportedClassVersionError: class file version 65.0

The exact error string

The modern wording (Java 8 and later) names two version numbers — the one the class was built for, and the highest one your runtime understands:

Exception in thread "main" java.lang.UnsupportedClassVersionError:
  com/example/App 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 52.0

Java 7 and earlier printed the same error with different words — if you searched that phrasing, this is your page too:

Exception in thread "main" java.lang.UnsupportedClassVersionError:
  com/example/App : Unsupported major.minor version 52.0

Both mean the same thing: a .class file was produced by a newer compiler than the JVM trying to load it, and the JVM refuses because it can't read a class-file format from the future. Every JDK release bumps the class-file format version by one and will not load anything higher than its own.

Anatomy of the message — read the two numbers

This error tells you exactly what's wrong; you just have to decode it. There are only two moving parts, and the fix falls out of them:

The rule is major version = JDK feature release + 44, so you never have to guess. The trailing .0 is the minor version and is almost always 0; the one exception is a class compiled with preview features enabled, which sets the minor version to 65535 (0xFFFF) — if you see 65.65535, the class targets Java 21 and was built with --enable-preview, which additionally requires an exactly-matching runtime with --enable-preview too.

Class-file version ↔ JDK lookup table

Match the number in your message to the JDK on both sides:

If your message shows an even higher number, keep applying version − 44. This is a mismatch of the same shape as ClassNotFoundException / NoClassDefFoundError in that both stop a class from loading — but that one is about a class that can't be found, whereas this one found the class fine and rejected its format.

Confirm which side is which

Before changing anything, verify the runtime version and the class's compiled version so you know which one to move. Check the runtime first:

java -version
# openjdk version "1.8.0_402"   <- runtime is Java 8 (the "up to 52.0" side)

javac -version
# javac 21.0.2                  <- compiler is Java 21 (the "65.0" side)

Then read the version stamped into the actual class file — this is the ground truth, independent of which javac is on your PATH right now:

javap -verbose com/example/App.class | grep -E "major|minor"
# minor version: 0
# major version: 65            <- 65 - 44 = Java 21

# on any Unix box, without a JDK:
file com/example/App.class
# App.class: compiled Java class data, version 65.0 (Java 21)

Now you know both numbers came from your own machine, not just from the error text, and you can pick the fix with confidence.

Fix 1: run on a newer Java runtime (raise the runtime)

The direct fix is to run the class on a JDK at least as new as its class-file version. A version 65.0 class needs Java 21 or newer. Install one and point JAVA_HOME and PATH at it:

# example on Linux/macOS after installing a JDK 21 build
export JAVA_HOME=/usr/lib/jvm/temurin-21-jdk
export PATH="$JAVA_HOME/bin:$PATH"

java -version   # confirm it now reports 21.x before re-running
java -cp . com.example.App

If you manage several JDKs, a version manager (sdkman, jenv, or your OS package manager's alternatives system) makes switching the active runtime a one-liner. This is the right fix when the newer bytecode is intentional — you want Java 21 features and simply need the deploy target to catch up.

Fix 2: recompile for the older runtime (lower the target)

When you can't change the runtime — a server stuck on Java 8, a customer environment, a locked base image — compile the bytecode down to that runtime instead. Use --release, which both emits older bytecode and restricts you to APIs that existed in that release (unlike the older -source/-target pair, which could let you call APIs the target JDK doesn't have):

# javac --release requires JDK 9+; targets the given release's bytecode + API
javac --release 8 -d out com/example/App.java

javap -verbose out/com/example/App.class | grep major
# major version: 52            <- now a Java 8 class, runs on a Java 8 JVM

You obviously can't use language or library features newer than the target — --release 8 will reject a record or a var in a lambda. That rejection at compile time is the point: it stops you from shipping a class that would only blow up at runtime on the old JVM.

Fix 3: set the release level in Maven or Gradle

Most real projects don't call javac directly. Set the target once in the build tool so every module is consistent. In Maven, prefer the single release property over separate source/target:

<!-- pom.xml -->
<properties>
  <maven.compiler.release>17</maven.compiler.release>
</properties>

In Gradle, a toolchain is the robust choice because it pins the exact JDK used to compile regardless of which java launched Gradle:

// build.gradle
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}
// (or, to only lower bytecode without pinning the JDK:)
// tasks.withType(JavaCompile).configureEach { options.release = 17 }

Set the number to the oldest runtime you must support. Building with a newer JDK is fine — --release 17 under a JDK 21 build produces Java 17 bytecode that runs everywhere from Java 17 up.

Why it usually happens: build JDK ≠ runtime JDK

Almost every occurrence is one machine (or image, or IDE) compiling with a newer JDK than a different machine runs. The build succeeds because the compiler is new; the failure only shows up when the class meets the older runtime. The usual culprits:

• CI vs. deploy: the pipeline builds on JDK 21 but the production container's base image is eclipse-temurin:8-jre or openjdk:11. Pin both to the same release.
• IDE vs. terminal: IntelliJ or Eclipse compiles with its own configured JDK while your shell's java is older. Align the project SDK/language level with the runtime.
• A dependency, not your code: the failing class name in the message is a library's class — a jar built for Java 17 pulled into a Java 8 app. Either upgrade your runtime or downgrade to a version of the dependency that targets your JDK.
• Two JDKs installed: mvn -version and java -version report different Java versions. Fix JAVA_HOME so the build and the launcher agree.

Debugging checklist

• ✓ Decode both numbers with version − 44 — know which side is the class and which is the runtime
• ✓ Confirm the runtime with java -version and the class with javap -verbose ... | grep major
• ✓ Newer bytecode intentional? Upgrade the runtime (Fix 1) and re-check with java -version
• ✓ Runtime is fixed (old server / base image)? Recompile with --release N (Fix 2/3)
• ✓ Failing class is from a dependency? Match the library version to your JDK, or raise the JDK
• ✓ mvn -version ≠ java -version? Align JAVA_HOME across build and runtime
• ✓ See .65535 as the minor version? It's a --enable-preview class — run with a matching JDK and --enable-preview