Page Comparison

...

1. The upgrade to Java 17 may require you to handle the conflicts that may occur with custom jars or custom classes. You may come across the following scenarios wherein you need to take the necessary actions to address the conflicts. 

   1. Java packages used in the custom plugins, custom jars, or custom classes may have changed. To address this issue, you need to change the custom plugins, custom jars, and the custom classes accordingly.

   2. Classes used in custom plugins, custom jars, or custom classes may have been deprecated or their implementation may have changed. To address this issue, you need to change the custom plugins, custom jars, and the custom classes accordingly.

   3. Although Java 17 is backward compatible – code compiled with Java 8 continues to run on Java 17 most of the time – there are certain restrictions implemented in Java 17, for example, Java 17 restricts the use of certain packages and reflections. However, you can override these restrictions by adding the required entries in the launcher.properties file.

   4. External jar(s) in the ext folder may not be compatible with the upgraded versions of the framework. In this case, jars need to be upgraded accordingly.

2. With an upgrade to JRE v17, the

   1. The SAML implementation in Adeptia Connect has

   now

   1. got configuration changes. To learn more about SAML in Adeptia Connect, refer to this document.

   With this upgrade, the

   1. The JMS provider that connects to Apache Active MQ JMS server

   now uses

   1. uses the two jars activemq-core-5.7.0.jar and geronimo-j2ee-management_1.1_spec-1.0.1.jar.  Ensure that:

      • You use these two jars when you create a JMS provider that connects to Apache Active MQ JMS server.

      • You have updated any existing JMS provider that connects to Apache Active MQ JMS server to use these two jars.
        For more details, refer to this page.