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. 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 Java 17 since Washington DC. 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 RuntimeTokyo 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 Xanadu A ServiceNow build of OpenJDK 17.0.10 is Supported and Included (17.0.10-sncmid1) Yokohama A ServiceNow build of OpenJDK 17.0.12 is Supported and Included (17.0.12-sncmid1)Starting with the Yokohama release, the MID Server is compiled using Java 17 and is incompatible with any Java version below 17 for runtime execution. See KB1704368 MID Server JRE Minimum Version Requirement Update to JRE 17 Starting from Yokohama Release for information about mandatory procedures before upgrading the instance. ResolutionChanging to your JRE If you chose to use your own Oracle/OpenJDK JRE with the MID Server, perhaps to use a more recent patch, 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. Changing it back to the bundled Open JDK JRE If you no longer want to use your own OpenJDK JRE with the MID Server, then follow these instructions: Edit the agent/conf/wrapper-override.conf file to comment out the wrapper.java.command line. Without that override, the same read only property in the wrapper.conf file will tell the MID Server to use the bundled OpenJDK JRE. (Use Wordpad and not Notepad on windows, as this is a Unix format file)Restart the MID Server service. #wrapper.java.command=C:\ServiceNow_MID_Servers\OpenJDK\8u251\jre\bin\javaAdditional 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/