Jenkins升级后，“类文件版本错误" [英] `class file has wrong version` after Jenkins upgrade

问题描述

几天前，我将Jenkins升级到版本1.643.以前，我们使用的是詹金斯1.593.从Jenkins 1.612开始，Jenkins需要Java 7，请参见 changelog ，

A couple of days ago, I upgraded Jenkins to version 1.643. Before, we were using Jenkins 1.593. Starting with Jenkins 1.612, Jenkins requires Java 7, see changelog, announcement and issue. Our Jenkins server has Java 8.

我有一个由子模块组成的Maven项目. 在Jenkins的作业配置中，我已将构建配置为使用JDK 1.6.

I have a Maven project consisting of submodules. In the job configuration in Jenkins, I have configured the build to use JDK 1.6.

查看构建环境时，确实为1.6:

When looking at the build environment, it's indeed 1.6:

JAVA_HOME=/var/lib/jenkins/tools/hudson.model.JDK/1.6

其中一个子模块无法在Jenkins上构建，出现以下错误:

One of the submodules fails to build on Jenkins, with this error:

[ERROR] /var/lib/jenkins/<REDACTED>.java:[15,-1] cannot access java.lang.Object
bad class file: java/lang/Object.class(java/lang:Object.class)
class file has wrong version 52.0, should be 50.0

据我所能带给Google的信息，类文件版本52.0为JDK 1.8，而编译器期望版本为50.0，即JDK 1.6.我假设类文件52.0引用了包含java.lang.Object的rt.jar(Java运行时)(另请参见下面的pom.xml摘录).

According to what I can Google, class file version 52.0 is JDK 1.8 while the compiler is expecting version 50.0, which is JDK 1.6. I assuming that class file 52.0 refers to rt.jar (Java Runtime) which contains java.lang.Object (see also pom.xml snippet below).

我发现了这个问题(以及与之重复的其他文件)，但它们全都在某人通过其IDE(IntelliJ)或命令提示符进行构建的上下文中，并且在阅读它们之后，我看不到如何应用建议的解决方案.它们涉及设置$JAVA_HOME，这已经由詹金斯(Jenkins)完成.

I have found this SO question (and others that are duplicate of it), but they are all in the context of someone building from their IDE (IntelliJ) or from command prompt, and after reading them, I don't see how I could apply the suggested solutions. They involve setting $JAVA_HOME, which is already done by Jenkins.

我的问题有所不同，因为问题是在詹金斯(和Maven)的背景下发生的，并且仅在詹金斯升级之后才发生.当我在自己的桌面上(使用JDK 1.8)执行mvn clean install时，不会发生此错误.如果在有问题的类文件上执行file命令，但是在成功编译的桌面上执行compiled Java class data, version 50.0 (Java 1.6).对我而言，这证实了我的pom.xml(可能)仍然正确，并且(可能)是Jenkins配置问题.

My question is different because the issue is in the context of Jenkins (and Maven), and only occurred after the Jenkins upgrade. When I execute mvn clean install on my own desktop (with JDK 1.8), the error does not occur. If I execute the file command on the offending class file, but on the desktop where compilation succeeded, I get compiled Java class data, version 50.0 (Java 1.6). For me, this confirms that my pom.xml is (probably) still correct and it's (probably) a Jenkins configuration issue.

该特定子模块在pom.xml中具有此名称，该名称可能相关也可能不相关:

That specific submodule has this in the pom.xml, which may or may not be relevant:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.6</source>
                <target>1.6</target>
                <compilerArguments>
                    <verbose />
                    <bootclasspath>${java.home}/lib/rt.jar</bootclasspath>
                </compilerArguments>
            </configuration>
        </plugin>
    </plugins>
</build>

因此，如您所见，它从当前的$JAVA_HOME中提取了rt.jar，因此可以与1.6的目标交叉编译.

So, as you can see, it takes rt.jar from the current $JAVA_HOME so it can cross compile with a target of 1.6.

对于Java 8的起源，我有点迷茫.在Jenkins升级之前，我们已经在服务器上使用Java 8，并且与Java 6的目标交叉编译.

I'm a bit lost about the origin of this Java 8. Before the Jenkins upgrade, we were already using Java 8 on the server and cross compiling with a target of Java 6. What am I missing here?

编辑

我什至需要吗?如果我注释掉

Do I even need this? If I comment out

                <compilerArguments>
                    <verbose />
                    <bootclasspath>${java.home}/lib/rt.jar</bootclasspath>
                </compilerArguments>

在pom.xml中，我仍然可以在桌面上交叉编译，并且类文件仍然是50.0版.

in pom.xml, I can still cross compile on my desktop and the class files are still version 50.0.

编辑

当我删除该部分时，构建不会再失败了. 这意味着我自己解决了.

When I take that part out, the build does not fail any more. Which means I solved it myself.

我想将问题更改为:为什么首先失败了?而且为什么它在Jenkins 1.593上没有失败过?

I want to change the question to: why did it fail in the first place? And why didn't it fail before on Jenkins 1.593?

推荐答案

我认为您的假设存在一些错误.

I think you have a few errors in your assumptions.

1. compilerArguments已已弃用.它已经被取代，被compilerArgs 取代.

1. compilerArguments is deprecated. It's been superseded by compilerArgs.

就像您可以从编译器插件文档，compilerArguments/compilerArgs仅用于配置部分本身不支持的参数.由于支持bootclasspath，因此在compilerArgs/compilerArguments部分中使用它通常是不正确的.

Like you can see from compiler plugin documentation, compilerArguments/compilerArgs is meant to be used only for arguments not supported by configuration section itself. As bootclasspath is supported, using it in compilerArgs/compilerArguments section is generally incorrect.

compilerArgs/compilerArguments仅在

compilerArgs/compilerArguments is only used if fork is set to true, which was not correct for your configuration.

第三点可能是它对您不起作用的最重要原因.在您的用例中使用configuration部分应该没有问题，实际上根据您的问题/答案，似乎是这种情况.

The third point was probably the most important reason why it didn't work for you. Using configuration section for your use case there should be no issues, and indeed based on your question/answer, this seems to be the case.

还请注意，java.home不是 JAVA_HOME.我已经在此处中对此进行了扩展.我想这与您为什么看到Jenkins版本之间有变化有关.

Also note that java.home is not JAVA_HOME. I've expanded on that on my other answer here. I'd guess that is related to why you see changes between Jenkins versions.

这篇关于Jenkins升级后，“类文件版本错误"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！