Which Java versions are supported and compatible with MID Servers (OpenJDK/Oracle JRE)Description Until Kingston, MID Servers were bundled with Oracle's build of the Java Runtime Environment (JRE). Since Madrid ServiceNow own OpenJDK based JRE build is included. This JRE has been what all MID Server-related release testing has been done with since. From Paris, the bundled Java 8 or 11 OpenJDK JRE was intended to be updated to a more recent patch with every major release. The bundled JRE does not have to be used (see resolution instructions at the end). You may have a requirement to use the latest Java patch instead, for security reasons, or because you need to customise the JRE and not have it overwritten at each upgrade. As of the Orlando/Paris release, MID Server officially documents that it supports all Oracle and OpenJDK JREs, not just our own build and patch level, although only Java 11 should be used since Quebec, and won't work at all from Utah. From Vancouver, Java 17 is bundled. If there is a problem running ServiceNow features and code on a MID Server with one of those non-bundled JREs then it will be treated as a product defect and we will try to provide a workaround or fix. Be prepared for Tech Support to ask you to temporarily switch back to the bundled servicenow OpenJDK build to confirm if the JRE version is relevant to the reported issue. The following known problem specific to the JRE version was fixed in Tokyo: PRB1548158 / KB1001926 - 32 Bit MID Server installed on 64 Bit host machine fails AutoUpgrade in Rome (Ref.: Knowledge base for other Known Errors) MID Server Installer Java Runtime <=Kingston Oracle 1.8.0_152 JRE (8u152) is Supported and Distributed with the MID Server installer. Previously releases included 8u60, 8u40, 6u45 & 6u14 and were the 'supported version' at the time, and would have been upgraded along with the MID Server. Kingston Patch 14 was the final Patch to include an Oracle JRE. Kingston Patch 14b HotFix1 included the OpenJDK 1.8.0_181 JRE, as used in Madrid. London No JRE is included in the full Installer ZIP file for London Patch 7 and below. Customers needed to source their own JRE. However, if the MID Server was installed <=Kingston, then an upgraded London MID Server will continue to use the Oracle JRE originally installed by ServiceNow. London Patch 8 and later includes the OpenJDK 1.8.0_181 JRE, as used in Madrid. Customers who are using their own Oracle JRE, external to the agent folder, can switch back to using OpenJDK using these steps :KB0719389 Switching the MID Server from an existing Java Runtime Environment (JRE) to the OpenJDK provided by ServiceNow Madrid /New York /Orlando A ServiceNow build of OpenJDK 1.8.0_181 JRE is Supported and Included. MID Servers installed before Madrid that are still using the Oracle JRE will have it replaced by the OpenJDK JRE. The last versions to include 1.8.0_181 were Madrid Patch 10, New York Patch 7 and Orlando Patch 2. Paris /Orlando Patch 3 /New York Patch 8 OpenJDK 1.8.0_231 will be included in Paris, and that has already been back-ported to the current Orlando and New York Patches. (1.8.0_231-sncmid1) New York Patch 8 and Orlando Patch 3 and later include 1.8.0_231. No Madrid patch included this version. Quebec A ServiceNow build of OpenJDK 11.0.8 JRE is Supported and Included (11.0.8-sncmid1). This Java version adds support for TLS v1.3. Although 32 bit installers are no longer available, existing 32bit installs will still be upgraded in this release, including the bundled Java to v11. These MID Servers must be retired and replaced before upgrading to Rome. Linux 32-bit MID Servers, and Linux 64-bit MID Servers with glibc version less than 2.17, cannot use Java 11, and will remain on Java 8. An email was sent to affected customers in November 2020. For more details, see KB0863694. Note: Quebec includes a fix to preserve the cacerts file, but applies only after you have upgraded, so a Quebec upgrade could lose your cacerts file. That is particularly important if you have added certificate chains for the connection to the instance via an interception firewall. That fix is backported to Orlando Patch 10 and Paris Patch 4, so to avoid problems due to the cacerts contents being lost, upgrade the instance to those or more recent patches before the Quebec upgrade to avoid the Java 11 upgrade replacing your cacerts file. For more details see:PRB1320637 / KB0750004 A MID Server upgrade that includes a new JRE version will overwrite the cacerts filePRB1451866 / KB0869024 The fix for PRB1320637 requires that the cacerts Truststore file password remains as the default "changeit", which many customers won't allow, causing certificate deletion during JRE upgrades (e.g. Quebec) and subsequent MID Server and Integration outage Warning: 3rd party apps and custom implementations that depend on additional JAR files/classes in agent/extlib will also need testing and verifying on Java 11 before upgrading to Quebec. Rome A ServiceNow build of OpenJDK 11.0.9.1 JRE is Supported and Included (11.0.9.1-sncmid1). 32-bit host machine MID Servers are no longer supported on Windows or Linux, so only 64-bit JREs will be included. An email was sent to affected customers in November 2020. For more details, see KB0863694. 32-bit MID Servers will not upgrade, and remain on the previous instance version in an 'Upgrade Failed' state, which may not work any more due to code/data/security mismatches, and will need new hosts provisioning for replacement MID Servers to be installed on ASAP. 32bit installs (that contain 32bit JRE) are still supported on 64bit hosts, however there is a known problem in relation to this:KB1001926 - 32 Bit MID Server installed on 64 Bit host machine fails AutoUpgrade in Rome San Diego A ServiceNow build of OpenJDK 11.0.12 JRE is Supported and Included (11.0.12-sncmid1). Windows x86-64mid-jre.sandiego-12-22-2021__patch0-hotfix2-02-04-2022_02-07-2022_1650.windows.x86-64.zipWindows x86-32mid-jre.sandiego-12-22-2021__patch0-hotfix2-02-04-2022_02-07-2022_1650.windows.x86-32.zipLinux x86-64mid-jre.sandiego-12-22-2021__patch0-hotfix2-02-04-2022_02-07-2022_1650.linux.x86-64.zipLinux x86-32mid-jre.sandiego-12-22-2021__patch0-hotfix2-02-04-2022_02-07-2022_1650.linux.x86-32.zip Tokyo A ServiceNow build of OpenJDK 11.0.15 is Supported and Included (11.0.15-sncmid1) mid-jre.tokyo-07-08-2022__patch9-hotfix2a-06-26-2023_07-05-2023_1648.windows.x86-64.zipmid-jre.tokyo-07-08-2022__patch9-hotfix2a-06-26-2023_07-05-2023_1648.linux.x86-64.zip Utah A ServiceNow build of OpenJDK 11.0.16.1 is Supported and Included (11.0.16.1-sncmid1) KB1124078 MID Server JRE version minimum requirement change to JRE 11 from Utah release onwards TLS 1.1 and below will no longer be supported. An email was sent out on 2022-02-14, with subject "MID Server support notification: Be informed".For workaround see: KB1006178 - Issue with discovering certain certificates via "11.0.12" JRE mid mid-jre.utah-12-21-2022__patch2-03-30-2023_04-10-2023_1543.windows.x86-64.zipmid-jre.utah-12-21-2022__patch2-03-30-2023_04-10-2023_1543.linux.x86-64.zip Vancouver Patch 0 (EA) A ServiceNow build of OpenJDK 17.0.5 was planned for Vancouver, but reverted to Java 11 for the General Availability (GA) release. Vancouver Patch 1 (GA) A ServiceNow build of OpenJDK 11.0.16.1 is Supported and Included (11.0.16.1-sncmid1) Note: The GA release of Vancouver reverted back to Java 11 due to CVE-2022-45146 in BCFIPS 1.0.2.jar with Java 17. Vancouver Patch 4 (GA) A ServiceNow build of OpenJDK 11.0.20.1 is Supported and Included (11.0.20.1-sncmid1) Washington DC A ServiceNow build of OpenJDK 17.0.8.1 is Supported and Included (17.0.8.1-sncmid1) Administrators will need to make sure any 3rd party JAR files for Credential resolvers, JDBC drivers, etc. are compatible with Java 17 and 'strong encapsulation', before upgrading.More information: KB1273036 MID Server - JRE 17 Upgrade ResolutionIf you do need to use your own OpenJDK JRE with the MID Server, then follow these instructions: Using the vendor's own instructions, Install the JRE in the normal way but be sure to install it outside of the MID Server's "agent" install folder. MID Server upgrades can replace anything included within the agent folder, and do regularly delete and replace everything in the bundled JRE's agent/jre/ folder.Edit the agent/conf/wrapper-override.conf file to tell the MID Server to use the newly installed external JRE. (Use Wordpad and not Notepad on windows, as this is a Unix format file)Restart the MID Server service. ################################################################################# External JRE################################################################################# Uncomment and edit if an external JRE is preferred. By default,# the internal JRE distribution is used.## OPTIONAL: The path (relative to agent dir or absolute) to the java binwrapper.java.command=C:\ServiceNow_MID_Servers\OpenJDK\8u251\jre\bin\java Warnings: You are now responsible for keeping the JRE maintained. ServiceNow upgrades will not touch this JRE.If you customise the JRE, perhaps by swapping .jar files within the jre for different versions, then this JRE will no longer be supported by servicenow.Search the knowledge base for known problems with compatibility with the versions you intend to use. The list above only lists some main ones known to the author.Additional Information A MID Server downgraded from Quebec to an earlier version will not downgrade the JRE again. This will cause problems due to PRB1419594, which was fixed from Orlando Patch 9 and Paris Patch 4. Downgrades to prior versions will need to turn off performance monitoring of the MID Server, to avoid exceptions from the SIGAR libraries. Downgrades are common when re-cloning after a upgrade test, and you can expect problems with mid servers in this situation newer mid servers find themselves talking to an older version instance. It is normal to ecpect to have to re-install those sub-production instance mid servers if you do hit a compatibility problem like that in more recent versions as well. https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.htmlhttps://www.oracle.com/technetwork/java/javase/terms/license/javase-license.htmlhttps://openjdk.java.net/faq/