We are controlling the (launched) VMWare VM’s (Windows 10 and 11) using JAVA. However… no matter what instructions I follow in the registry (on the VM) or other settings, every 3 months I have to update JAVA on all the VM’s.
Does anybody know a way of REALLY killing the updater?
If not - are there simple alternatives to controlling Jenkins (RFW) on the VM other than JAVA?
I’m surprised you’re able to run this recent version of Jenkins with Java 8 in the first place. All of the modern container images are using Java 11 or 17.
If you do choose to continue with Java 8, there is an option in the control panel to disable checking for Java 8 updates. Or, you could move away from Oracle’s Java 8 distribution to one of the many others available which do not provide that particular updater as part of their installations.
That’s a very old Jenkins version running with a very old Java version. Jenkins versions since mid-2022 require Java 11 or Java 17.
Jenkins 2.213 is a weekly release from 3.5 years ago. It is susceptible to multiple security vulnerabilities. The current Jenkins weekly release is 2.420. It requires Java 11 or Java 17.
Java 8u144 was released 8 years ago. It is susceptible to multiple security vulnerabilities. The current Java 8 release is 8u382.
If you’re running Java 8u144 from 8 years ago, that seems like you’re not actually updating Java on the VM’s, or if you are updating Java on the VM’s, that update is not being used by Jenkins. You may want to investigate further to understand if the updated Java versions are actually being used by Jenkins.
The Java documentation describes how to disable Java update notifications. Since you indicate that you’ve tried registry settings and nothing works, I’m afraid I don’t have any other suggestions to offer.
V8, doing registry hacks and setting the “don’t bother me” “don’t even CHECK for updates” checkboxes doesn’t kill the check and popup about “JAVA is out of date” (which stops my automation totally)
I know I am using older versions. Last update was probably beginning of 2022. I will be updating. And removing a LOT of unused plugins.
Please note that the JENKINS side of this is not the issue. The JAVA used for Jenkins to talk to on the Windows TEST VM (win10 or 11) is the issue. THAT is what keeps plugging up the system. It becomes a very unpleasant task to have to constantly update the VM’s (in a manner not under MY schedule).
Honestly, I’ve never had an issue with the Java 8 Updater interfering with operations on a system, Jenkins or otherwise. I’ve always been able to just use the Java Updater control panel to disable the check.
PS: Java is not an acronym, it is a name. Don’t capitalize the entire word.
The simplest solution is the same as that suggested by others; avoid lining Oracle’s pockets and switch to an OpenJDK variant. Temurin / Hotspot is tested with Jenkins. There are offerings from IBM, RedHat, Microsoft, Amazon, Azul, and a host of others.
Uninstall the existing package from the Control Panel, then install the OpenJDK variant simply by unzipping and updating the PATH manually. We have been doing this to support private legacy instances of Jenkins ( 2.263.4) which requires the deprecated TFS plugin. It’s been running fine with both Temurin (hotspot) and Semeuru (OpenJ9/IBM) 3.382. Temurin and the MS offering tend to be out of the gate fastest, usually a week after Oracle’s release (11 and 17 get priority over 8), with IBM Semeru somewhat later.
That’s a very good point that I had not considered. Thanks @Ian_W
The Jenkins platform SIG stopped testing Jenkins on the Eclipse OpenJ9 / IBM Semeru Java virtual machine two years ago (or more). However, IBM Semeru is the only reasonable choice if you need to run Java 8 on an IBM s390x mainframe because the Hotspot virtual machine is not available for IBM s390x. It worked well for me when I needed Java 8 on s390x.
If someone wants to investigate and resolve Jenkins issues with OpenJ9 / Semeru, they are welcome to join the platform SIG where we discuss those types of topics.