MID Server - JRE 17 UpgradeIntroduction By default, MID server is bundled with a JRE which can run the MID server. The Utah version of JRE that comes with MID is 11.0.16.1. With Vancouver release, MID JRE will be upgrade to 17.0.5 version. Purpose Java 17 is the current Long-term support (LTS) release. It was released in Sep 2021 and has significant benefits in memory management, performance, and stability. Major changes in MID to support JRE17 Following are the major changes that were done for MID server to run on JRE17: Removed strongly encapsulated Java internal APIs From JAVA 17, Java internal APIs are not accessible outside. For more details read this link. The best fix is to refactor the code where these internal APIs are used. We have removed the Java internal APIs usage from the MID code wherever possible. But some dependent teams and third-party libraries still use these internal APIs and for it to work with JRE17 we have added JVM option (add-opens) suggested by JAVA for these internal APIs to be accessible like it used to with JRE11. For example, sun.security.x509.X500Name is an internal API which has been removed from the MID code. Apache Ignite is a third-party library which use many internal APIs and use reflection to access private and protected members of exported JAVA APIs. As MID uses this library, we had to add JVM options suggested by Apache to run Ignite on JRE17 (https://ignite.apache.org/docs/latest/quick-start/java#running-ignite-with-java-11-or-later). These JVM options have been added into wrapper.conf file. Changed recommended JRE version for MID The recommended JRE version for MID till Utah release is 11.0.16.1, which will be changed to 17.0.5 from Vancouver release. The minimum JRE version that MID supports in Vancouver is still 11.0.9. Upgrading to Vancouver When MID upgrades to Vancouver, it downloads JRE 17.0.5 package and upgrades the agent/jre directory with JRE17. Who are impacted? MID servers using JRE from agent/jre directory, will be upgraded to JRE17. These impacted MID servers must be tested for JRE 17 compatibility (Check if all the third-party libraries being used support JRE17 and update them if not supported. Check for any usage of removed APIs from JRE17 and replace them with alternate APIs). MID servers using JRE from a different location will not be impacted and will continue to use the existing JRE from that location. Troubleshooting After upgrading MID server to JRE17, you might face some issues because of strong encapsulation in Java17. If you see java.lang.IllegalAccessError or java.lang.reflect.InaccessibleObjectException in the logs, then it’s because of strong encapsulation. The fix is to open the module to all unnamed modules by adding a JVM option in agent/conf/wrapper.conf file. Below is one such option that’s added to fix these issues. wrapper.java.additional.120=--add-opens=java.base/sun.security.provider=ALL-UNNAMED Follow this link to know more. If you want to use custom JRE, then please follow this KB.