解决Unsupported class file major version 61错误

Unsupported class file major version 61 是 Java 项目开发、构建或运行过程中比较常见的一类版本兼容错误。它通常意味着：当前环境使用的 Java 版本过低，无法识别由更高版本 Java 编译生成的 .class 文件。

其中，major version 61 对应 Java 17。也就是说，如果项目中的某个类文件是使用 JDK 17 编译的，而当前运行环境只支持 Java 16 或更低版本，就可能出现类似错误。

一、Unsupported class file major version 61是什么意思

Java 源代码经过 javac 编译后，会生成字节码文件，也就是 .class 文件。每个 .class 文件内部都有一个版本号，用于表示生成该字节码所使用的 Java 版本。

常见的 Java class major version 对应关系如下：

因此：

Unsupported class file major version 61

可以直接理解为：

当前 Java 环境无法处理 Java 17 编译出来的 class 文件。

需要注意的是，错误不一定意味着项目本身必须升级到 Java 17。也可能是某个依赖、插件或者构建工具使用了 Java 17 编译，而你的项目运行环境仍然停留在 Java 8、Java 11 或 Java 16。

二、为什么会出现这个错误

最常见的原因是 Java 版本不一致。

例如项目依赖中存在：

some-library.jar

这个 JAR 是使用 JDK 17 编译的：

Java 17 → .class major version 61

但是你的项目运行环境是：

Java 11 → 最多支持 major version 55

当 Java 11 尝试加载这个类时，就会出现：

Unsupported class file major version 61

典型场景包括以下几种。

1. JDK版本过低

例如开发人员使用 JDK 17 编译项目：

Bash
javac -version

得到：

javac 17

服务器却使用：

Bash
java -version

得到：

openjdk version "11..."

这时候就可能产生版本冲突。

2. Maven使用的Java和系统Java不一致

很多开发环境同时安装了多个 JDK。

例如：

系统 java：Java 11
IDE：Java 17
Maven：Java 11

开发人员在 IDE 中运行项目没有问题，但执行：

Bash
mvn clean package

却出现 major version 61。

原因通常不是代码发生了变化，而是实际执行 Maven 的 JDK 与 IDE 使用的 JDK 不一致。

3. Gradle运行环境版本不匹配

Gradle同样依赖 Java 环境。

例如项目使用：

JDK 17

但 Gradle Daemon 仍然运行在：

JDK 11

某个插件或者依赖加载时，就可能触发 class 文件版本错误。

4. 第三方依赖使用了更高版本Java

项目本身可能仍然是 Java 8：

XML

    1.8

但是新加入的第三方库已经要求 Java 17。

此时即使自己的代码没有升级，也可能出现：

Unsupported class file major version 61

5. 编译环境和运行环境不一致

这是服务器部署中尤其常见的问题。

例如：

本地开发：JDK 17
CI构建：JDK 17
生产服务器：JDK 11

构建阶段正常：

BUILD SUCCESS

部署后启动却失败。

因此排查这个问题时，不能只看项目配置，还需要检查实际运行程序的 Java 环境。

三、首先检查当前Java版本

遇到错误后，不要急着修改 Maven 或 Gradle 配置，首先确认当前环境到底使用哪个 Java。

执行：

Bash
java -version

再执行：

Bash
javac -version

例如：

java version "11.0.20"
javac 17.0.8

这种情况就非常值得注意。

java 和 javac 分别来自不同版本的 JDK，可能导致编译和运行环境不一致。

Linux/macOS还可以执行：

Bash
which java

以及：

Bash
which javac

Windows可以使用：

cmd
where java

和：

cmd
where javac

进一步确认实际调用的是哪个程序。

四、解决方法一：升级JDK到Java 17

如果项目依赖本身已经要求 Java 17，那么最直接的方案就是将运行环境升级到 JDK 17 或更高版本。

升级后检查：

Bash
java -version

确保输出类似：

openjdk version "17..."

同时检查：

Bash
javac -version

确认编译器版本也符合预期。

如果使用 Maven，还可以执行：

Bash
mvn -version

重点查看：

Java version: 17

例如：

Apache Maven 3.9.x
Java version: 17.x

如果 java -version 显示 Java 17，但 mvn -version 显示 Java 11，说明 Maven使用的JDK仍然没有切换成功。

五、解决方法二：修改JAVA_HOME

如果电脑中安装了多个 JDK，需要确保 JAVA_HOME 指向正确版本。

Linux中可以查看：

Bash
echo $JAVA_HOME

例如当前指向：

/usr/lib/jvm/java-11-openjdk

而项目实际要求 Java 17，就需要修改为对应的 JDK 17 路径。

例如：

Bash
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
export PATH=$JAVA_HOME/bin:$PATH

然后重新检查：

Bash
java -version
mvn -version

Windows则需要在系统环境变量中检查：

JAVA_HOME

以及：

Path

是否仍然优先指向旧版本 JDK。

修改环境变量后，建议重新打开终端，再执行：

cmd
java -version
mvn -version

避免旧环境变量仍然处于当前终端会话中。

六、解决方法三：降低项目编译版本

如果项目必须运行在 Java 8、Java 11 等旧版本环境，而某个模块是按照 Java 17 编译的，那么升级运行环境并不一定是唯一选择。

可以考虑将源码重新使用较低版本 Java 编译。

以 Maven 项目为例，可以配置：

XML

    11
    11

或者使用：

XML

    11

release 通常比单独设置 source 和 target 更适合控制目标 Java 平台。

例如项目需要兼容 Java 8：

XML

    8

但这里有一个关键问题：

如果第三方依赖本身就是使用 Java 17 编译的，仅仅修改自己的 target 并不能解决问题。

因为依赖中的 .class 文件仍然是：

major version 61

此时应该寻找支持旧 Java 版本的依赖版本。

七、解决方法四：降低第三方依赖版本

假设项目运行环境只能使用 Java 11，但最近升级了某个依赖：

XML

    example
    example-library
    新版本

新版本可能已经使用 Java 17 构建。

这时可以查看该组件的版本兼容要求，选择仍支持 Java 11 的版本。

修改版本后执行：

Bash
mvn clean package

或者：

Bash
./mvnw clean package

如果是 Gradle：

Bash
./gradlew clean build

需要特别注意依赖树中是否还存在其他 Java 17 组件。

Maven可以使用：

Bash
mvn dependency:tree

查看项目完整依赖关系。

如果项目依赖复杂，这一步通常非常重要，因为报错的类不一定直接来自你刚刚修改的那个依赖。

八、解决方法五：检查IDE中的JDK配置

如果命令行运行正常，但IDE中报：

Unsupported class file major version 61

需要重点检查IDE使用的JDK。

例如 IntelliJ IDEA 中，通常需要检查：

Project SDK

以及：

Project language level

同时还需要检查：

Build Tools → Maven → JDK

因为项目SDK和Maven运行JDK可能并不是同一个版本。

如果使用Gradle，还需要检查：

Gradle JVM

例如：

Project SDK：Java 17
Gradle JVM：Java 11

这种配置就可能导致Gradle构建时出现版本问题。

调整为统一的JDK版本后，再重新执行构建。

九、解决方法六：检查Gradle使用的JDK

Gradle项目可以执行：

Bash
./gradlew -version

查看：

JVM:

对应的 Java 版本。

例如：

Gradle 8.x
JVM: 11.x

如果项目依赖要求 Java 17，而Gradle实际运行在Java 11，就需要调整Gradle JVM。

也可以检查：

Bash
echo $JAVA_HOME

并确认：

Bash
./gradlew -version

显示的JVM版本是否与预期一致。

如果修改了 JDK 后仍然出现旧版本信息，可以停止Gradle Daemon：

Bash
./gradlew --stop

然后重新构建：

Bash
./gradlew clean build

十、Spring Boot项目中的常见情况

Spring Boot项目特别容易遇到Java版本不一致的问题。

例如项目配置：

XML

    17

但服务器执行：

Bash
java -version

结果却是：

java version "11"

那么项目启动时就可能产生版本兼容问题。

如果项目明确要求 Java 17，应确保：

IDE → Java 17
Maven → Java 17
项目编译目标 → Java 17
服务器 → Java 17
Docker镜像 → Java 17

这些环境尽量保持一致。

例如Dockerfile：

dockerfile
FROM eclipse-temurin:17-jre

COPY target/app.jar /app/app.jar

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

这样可以避免本地JDK和容器JDK差异过大。

十一、如何快速定位到底是哪一个依赖导致错误

如果错误信息没有直接指出具体依赖，可以从堆栈信息入手。

例如：

java.lang.IllegalArgumentException:
Unsupported class file major version 61

继续向下查看：

at xxx.xxx.SomeClass

通常能够找到正在加载的类。

如果怀疑某个JAR，可以检查它里面的 .class 文件版本。

Linux环境下可以使用：

Bash
javap -verbose SomeClass.class

查看：

major version: 61

这就可以确认该class确实是Java 17字节码。

对于JAR文件，可以先解压：

Bash
jar xf example.jar

再找到对应的 .class 文件进行检查。

这种方法特别适合大型Java项目，可以帮助定位真正产生版本冲突的组件。

十二、不要只修改source和target

很多人遇到这个问题后，会直接修改：

XML

和：

XML

但这并不一定有效。

例如：

你的代码 → Java 11
第三方依赖 → Java 17
运行环境 → Java 11

即使将自己的代码编译成Java 11：

XML
11

第三方JAR仍然可能包含：

major version 61

Java 11加载它时照样会失败。

所以排查思路应该是：

当前运行JDK是多少？
        ↓
报错的class来自哪里？
        ↓
这个class使用哪个Java版本编译？
        ↓
当前JDK能否加载？
        ↓
升级JDK还是降低依赖版本？

这样比盲目修改配置更加有效。

十三、Maven项目推荐的排查命令

遇到 Unsupported class file major version 61 时，可以依次执行：

Bash
java -version

Bash
javac -version

Bash
mvn -version

然后查看依赖：

Bash
mvn dependency:tree

清理旧的编译产物：

Bash
mvn clean

重新构建：

Bash
mvn clean package

如果使用Maven Wrapper：

Bash
./mvnw -version

Bash
./mvnw clean package

这样能够避免系统Maven版本与项目指定Maven版本之间产生额外差异。

十四、常见错误处理思路

情况一：项目明确要求Java 17

直接将开发环境、构建环境和运行环境统一到Java 17。

重点检查：

java -version
javac -version
mvn -version

以及IDE、CI/CD和服务器的JDK配置。

情况二：服务器只能使用Java 11

不要直接把服务器升级到Java 17，而应该确认依赖是否有Java 11兼容版本。

必要时降低相关依赖版本，并重新构建项目。

情况三：IDE能运行，命令行不能运行

重点检查：

IDE JDK
Maven JDK
JAVA_HOME
PATH

很可能是IDE使用Java 17，而命令行Maven仍使用Java 11。

情况四：本地正常，服务器报错

重点检查：

本地JDK
CI构建JDK
服务器JDK
Docker基础镜像

尤其是通过CI/CD生成JAR后部署到旧服务器的情况。

情况五：升级JDK后仍然报错

检查是否存在多个Java环境。

执行：

Bash
which java

或：

cmd
where java

然后检查：

Bash
mvn -version

如果Maven仍然显示旧JDK，就说明Maven环境没有真正切换。

十五、总结

Unsupported class file major version 61 的核心原因并不复杂：Java运行环境无法识别Java 17编译产生的class文件。

看到 major version 61 时，可以先记住：

major version 61 = Java 17

解决问题通常有两条路线：

方案一：升级运行环境
Java 11/16 → Java 17

或者：

方案二：降低编译目标或依赖版本
Java 17 class → 使用兼容旧JDK的版本

实际处理时，最重要的不是简单修改一个配置，而是确认编译JDK、运行JDK、Maven/Gradle JDK、IDE JDK以及第三方依赖的Java版本是否匹配。

只要找到产生 major version 61 的具体类，再结合项目必须支持的Java版本选择升级JDK或降级依赖，通常就能快速解决这个错误。