Java "Unsupported major.minor version 61.0" - Fix Legacy JDK in CI

By Daniel Zoghalchali·Latchkey

Older JVMs (and some tools) report a class-version mismatch with the legacy wording Unsupported major.minor version N. It is the same condition as UnsupportedClassVersionError: a newer class file on an older runtime.

What this error means

A run or a tool (often an Ant/Maven plugin loading classes) fails with Unsupported major.minor version 61.0 (Java 17) or 52.0 (Java 8). The number identifies the bytecode level the JVM cannot read.

Exception in thread "main" java.lang.UnsupportedClassVersionError:
com/example/App : Unsupported major.minor version 61.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)

Common causes

Newer bytecode loaded by an older JVM

A plugin, agent, or app jar compiled for a newer release is loaded by a JVM that predates it. Major version 61.0 means Java 17; the JVM is older.

A tool runs under a different (older) JDK

The build tool itself may launch under JAVA_HOME while your classes target a newer release than that JDK.

How to fix it

Upgrade the runtime JDK to match

Run everything under a JDK at least as new as the highest bytecode level in play.

- uses: actions/setup-java@v4
  with:
    distribution: temurin
    java-version: '17'
- run: echo "JAVA_HOME=${JAVA_HOME}" && "${JAVA_HOME}/bin/java" -version

Identify the offending class version

1. Map the number: 52=8, 55=11, 59=15, 61=17, 65=21.
2. Run javap -verbose Offending.class | grep "major version" to confirm the level.
3. Ensure JAVA_HOME for the tool points at a JDK new enough to read it.

How to prevent it

• Standardize on one JDK across compile, tools, and run; assert it early with java -version so legacy major.minor mismatches surface immediately.

Frequently asked questions

Related guides

References

• Apache Maven guides
• Gradle user manual
• GitHub Actions documentation