Using of jdk via Tool Locations in Node Properties

Using Jenkins Ask a question
1

Hi guys,

I have totally understand, that jenkins had to migrated to jdk 11 with 2.263 at latest and I’m fine with that generally, but I really don’t understand, why it should not be possible to set via tool locations an older jdk like 8 in the agent node. JDK 8 is still supported and not every vendor software is ported to 11 or higher. I think this is really hard of most jenkins installations if you do so a break up between some versions. I think it should the user decision to run a build with that version, what they want.

In 2.346.3 it is working great to run the nodes with 11 and the build itself with 8 and this is what people really need. for example:
Name Architecture JVM Version Remoting Version
agent-jdk8 Linux (amd64) 11.0.15.1 4.13.3
Built-In Node Linux (amd64) 11.0.15.1 4.13.3

agent-jdk8 uses the jdk8 via Tool Locations

Please don’t send me the link to the migration side, I read and watched it so many times, but the functionality is gone. We can’t upgrade since and the danger of vulnerability increases with every week.

best regards
Thomas

2

You only need to run jenkins with java 11, your code can be compiled/run/etc with whatever version you want.

I’m really not sure what your concern/statement is? is something broken? are you just saying jenkins shouldn’t use 11?

3

Hi, with 2.346.3 it is working as I wrote, but if I upgrade to 2.361.3 it is not longer working, because the Tools Environments seems not taken in that way like before.
I got with the same settings this error message: Exception in thread “main” java.lang.UnsupportedClassVersionError: hudson/remoting/Launcher has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
For me it is broken. Maybe I miss some setting, but this i can’t expect.

4

That message usually means that JDK 8 is running and is trying to execute byte code that is compiled for Java 11. You said earlier that your agent is running Java 11. If your agent is running Java 11, then I assume that message is not from the agent startup, but happens some time later in the process. Where specifically does that message occur and what actions cause that message to appear?

You use the phrase “Tool Environments”. Does that mean you have installed the tool environments plugin or that you have some tool configuration that creates some sort of environment?

If you’ve installed the “Tool Environments” plugin, what version is installed and how is the plugin configured?

When I installed the Tool Environments plugin on my Jenkins 2.361.3 installation, I was unable to configure a Freestyle job to use the tool environments settings that were described in the plugin documentation. I don’t know if that is a plugin bug or a misunderstanding on my part. When I defined the freestyle job and enabled tool environment, it would accept my check box entries but would not write them to the configuration file. When I modified the config.xml of the freestyle job with my text editor and reloaded the job, the environment variable was visible and worked as expected.

You’re much more likely to receive useful help if you provide enough information so that others can duplicate the problem you’re seeing. I’ve made my guesses about the problem you’re seeing, but it is much more likely that others will be able to help if you provide the detailed information described in “How to report an issue”.

5

I just went through this kind of thing with my own system. For reasons, I wanted my agent to make JDK8 available. It turns out that your controller and your agent must be running on the same JDK. So, if you need to build with JDK8 while your agent is running on JDK11, you’ll need to install JDK8 on your image or agent.

I did that with a variation of this tip from dduportal: JDK8 Image bundles wrong agent jar version again. Regression from 276 · Issue #282 · jenkinsci/docker-inbound-agent · GitHub

7

omg, yes you are right, I used the wrong wording, I meant “Tool Locations”, I wrote it in my initial question part, and mixed it, so I have not the plugin, which you mentioned. Sorry for that.

This are my nodes:
Name Architecture JVM Version Remoting Version
agent-jdk8 Linux (amd64) 11.0.15.1 4.13.3
Built-In Node Linux (amd64) 11.0.15.1 4.13.3

The agent-jdk8 node has in his properties “Tool Locations”:
name: jdk8
home: /sharedev/SW/java/jdk1.8.0_141

My build is a maven build.
With 2.346.3 it executes:
/sharedev/SW/java/jdk1.8.0_141/bin/java -cp /home/acdbadev1/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven32-agent-1.13.jar:/sharedev/SW/apache-maven/boot/plexus-classworlds-2.5.2.jar:/sharedev/SW/apache-maven/conf/logging jenkins.maven3.agent.Maven32Main /sharedev/SW/apache-maven /sharedev/acdbadev1/utils/jenkins/war/WEB-INF/lib/remoting-4.13.2.jar /home/acdbadev1/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven32-interceptor-1.13.jar /home/acdbadev1/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.13.jar 43438

With 2.361.3 it executes:
/sharedev/SW/java/jdk1.8.0_141/bin/java -cp /home/acdbadev1/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven32-agent-1.13.jar:/sharedev/SW/apache-maven/boot/plexus-classworlds-2.5.2.jar:/sharedev/SW/apache-maven/conf/logging jenkins.maven3.agent.Maven32Main /sharedev/SW/apache-maven /sharedev/acdbadev1/utils/jenkins/war/WEB-INF/lib/remoting-3044.vb_940a_a_e4f72e.jar /home/acdbadev1/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven32-interceptor-1.13.jar /home/acdbadev1/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.13.jar 44813
Exception in thread “main” java.lang.UnsupportedClassVersionError: hudson/remoting/Launcher has been compiled by a more recent version of the Java

As I can see, it means the remoting doesn’t allow the jdk8 anymore, but the 2.361.3 has only remoting-3044.vb_940a_a_e4f72e.jar. Maybe it is the agent.jar, which it doesn’t allow. I don’t know, maybe you can help.

From the doku and Jenkins itself I get the agent.jar: curl -sO http://jenkins-server:20015/jenkins/jnlpJars/agent.jar
and start it with: /sharedev/SW/java/jdk-11.0.15.1/bin/java -jar agent.jar -jnlpUrl http://jenkins-server:20015/jenkins/computer/agent-jdk8/jenkins-agent.jnlp -secret abcd1234etc -workDir “/sharedev/acdbadev1/utils/jenkins-agent-jdk8/”

It is now possible to get my problem?

I add you the output of Script Console from how to report an issue, if you also need it after teh upgrade, I have to switch first, please let me know.

Jenkins: 2.346.3
OS: Linux - 3.10.0-1160.76.1.el7.x86_64
---
ant:481.v7b_09e538fcca
antisamy-markup-formatter:2.7
apache-httpcomponents-client-4-api:4.5.13-1.0
bootstrap4-api:4.6.0-3
bootstrap5-api:5.1.3-6
bouncycastle-api:2.26
branch-api:2.7.0
build-timeout:1.20
caffeine-api:2.9.3-65.v6a_47d0f4d1fe
checks-api:1.7.4
cloudbees-folder:6.714.v79e858ef76a_2
command-launcher:1.6
credentials:1087.1089.v2f1b_9a_b_040e4
display-url-api:2.3.6
echarts-api:5.3.3-1
email-ext:2.87
external-monitor-job:192.ve979ca_8b_3ccd
font-awesome-api:6.0.0-1
jackson2-api:2.13.3-285.vc03c0256d517
javadoc:217.v905b_86277a_2a_
javax-activation-api:1.2.0-3
javax-mail-api:1.6.2-5
jaxb:2.3.6-1
jdk-tool:1.5
jnr-posix-api:3.1.7-1
jquery3-api:3.6.0-4
jsch:0.1.55.2
junit:1119.1121.vc43d0fc45561
ldap:2.8
mailer:408.vd726a_1130320
mapdb-api:1.0.9.0
matrix-auth:3.1
matrix-project:758.v7a_ea_491852f3
maven-plugin:3.16
next-build-number:1.8
pam-auth:1.7
plain-credentials:1.8
plugin-util-api:2.16.0
popper-api:1.16.1-2
popper2-api:2.11.5-1
scm-api:608.vfa_f971c5a_a_e9
script-security:1189.vb_a_b_7c8fd5fde
snakeyaml-api:1.29.1
ssh-credentials:1.19
ssh-slaves:1.33.0
sshd:3.236.ved5e1b_cb_50b_2
structs:324.va_f5d6774f3a_d
subversion:2.16.0
token-macro:277.v7c8f82a_d66b_3
translation:1.16
trilead-api:1.0.13
versioncolumn:2.2
windows-slaves:1.8.1
workflow-api:1164.v760c223ddb_32
workflow-scm-step:2.13
workflow-step-api:625.vd896b_f445a_f8
workflow-support:839.v35e2736cfd5c
zentimestamp:4.2

if you need more, let me know. thx

8

That sounds really like my problem, I will go deeper next week, I’m not sure, how currently :slight_smile:

9

The maven job type is a very special beast. The maven plugin documentation says:

The Jenkins project recommends that users transition from the Maven job type to use Pipeline jobs or freestyle jobs. Stephen Connolly describes many of the reasons in his 2013 blog post, “Jenkins’ Maven job type considered evil”.

During the transition period while you are moving away from using the maven job type to use a Pipeline job or a freestyle job, you can refer to an article from CloudBees that offers some alternatives:

10

hm, this does not help, I don’t want to design everything new, if i want to upgrade jenkins…but thx you

11

Ah, it looks like the maven plugin is using JDK11-based jars. So you’re going to have to use JDK11 to compile your code for Java 8. Unless, like me, you have code that prevents it from being compiled by Java 9+.

12

Before

After

This is what I’m talking about. I know that 4.13 is the last remoting artifact that was compiled with Java 8. So 3044 was built with Java 11, which makes it incompatible with your use of the Java 8 JDK.

13

Maven jobs specifically couples your job to the version of java running jenkins. It was a big issue when we switched to java 7, java 8, and now java 11. It’ll continue to be a major problem.

At some point you’ll need to invest in the cost to fix this. Maven is pretty simple in pipeline, you can see Declarative Pipeline for Maven Projects as an example.

Hopefully the notes others have provided can help your immediate issue though.

14

thx all, but finally we can say, it is not possible to work with jdk8 after switching to 2.361.3 out of the box, The guys outside have to invest a lot of time to get it running with redesign or recompiling. This is not what I expect and a bit sad.

15

The redesign happened first with the Jenkins freestyle job type and then happened again with the Jenkins Pipeline job type.

Yes, a design error was made in the original Jenkins maven job type (several actually, if you read the risks section of the plugin documentation). The design error cannot be fixed in the Jenkins maven job type. The solution to that design error has been available for many years in freestyle jobs and in Pipeline jobs. You’ve chosen not to use the available solution by remaining with the maven job type.

I agree that it is a bit sad that you’ve chosen to not use the solution to the issue that has been available for many years. I hope that you’ll decide to use the available solution to the issue.

16

I really recognize your passive aggressive wording in the latest post, but tell me, if I have more than 8 years no problems with the maven job type, why I should invest time for changing it? Anyway, as mentioned, I’m investing to the Pipeline stuff, it is not really funny and a lot of time consuming and a bad implementation (for example: sh cmd is broken, if you have a global PATH variable set…), but hopefully it will be solved until the next redesign thing, let’s see. This topic can be closed.