Since Jenkins needs Java 21 on agents as well as on the controller, AIX 7.1, Solaris, HP-UX, and RHEL 6 build hosts can’t connect to an up-to-date controller: those systems stop at Java 8. The usual workarounds are a second, frozen Jenkins for those platforms, or building them by hand or other workarounds, and neither survives a security audit for long.
It’s the official agent.jar with its bytecode downgraded to Java 8 (or 11/17) using JvmDowngrader, plus a small Java agent that downgrades classes the controller sends at runtime and keeps serialization compatible (pinned serialVersionUIDs, the List.of/Stream.toList() serial form, an OpenJ9 fix). The host stays a normal inbound agent: labels, sh, file steps, junit, stash, aborts, Git checkout and withCredentials work.
install.sh fetches the build matching the controller’s remoting version, checks its sha256, keeps your original jar as a backup, and you restart the agent with the same command.
Status, honestly:
Tested in CI against the current LTS and weekly on Linux with HotSpot 8 (CentOS 6.10), OpenJ9 8, and HotSpot 11.
Real AIX, Solaris, and HP-UX are experimental: not fully run on real hardware yet.
If you use the Versions Node Monitors plugin, set its JVM Version monitor to not disconnect.
Not an official Jenkins project.
I’d really like to hear from anyone with AIX/Solaris/HP-UX agents who can try it, and about plugins that break on it. Feedback on the approach is welcome too.
The OpenJ9 virtual machine was abandoned by the Jenkins Platform SIG in August 2021. We did not have enough interest in it from SIG participants and there were real problems with it.
The JDK the agent uses with the controller does not need to be the JDK to build a product on an agent. You can have an agent.jar running on Java 21 execute a job that builds an application on Java 1.8 (or even older!) via its shell script.
From a build tools perspective I believe there are two options:
run the build on an older JDK (I don’t generally advise this but it is the easiest option)
More difficult but longer term maturity: Adopt a modern Java development tool chain and target jdk8 byte code compatibility. Your application can build and test on Java 21 and still ship artifacts capable of running on Java 8.
Either option produces a Java 8 result. Both options still mean your agent.jar is java 21 since agent java version is irrelevant to the application being built.
Linux and Unix can have multiple java versions installed at the same time
The problem here is that when you’re running an old OS there is just no newer Java. So you’re not able to connect such a machine to a recent Jenkins normally.
Though there are other ways to overcome this, what I once did was to checkout everything on a linux machine, then copy the workspace with scp over to the machine, execute the build via ssh and then copy the results back to the linux machine. A bit tricky is handling parallel builds and when a build gets cancelled. Luckily I no longer need to support those old platforms.
Agreed if the host can run a newer Java. But on AIX 7.1, HP-UX or Solaris 10 nothing new enough for current Jenkins exists, so agent.jar itself has to run on 8.