The Apama installation includes an Oracle Java(TM) SE Development Kit (JDK). To write and compile Java applications, you need a Java compiler such as javac, and the jar utility. Software AG recommends that you use Oracle JDK 8 included in the Apama installation to develop, build, and test your applications. The minimum JDK version you can use is JDK 7.

Apama 9.9 incorporates ICU (International Components for Unicode) Timezone Data update 2015e, which is the most recent update at the time of release. This will update timezone data used by the correlator and TimeFormat correlator plug-in.

The correlator will now search APAMA_WORK/license/ApamaServerLicense.xml to locate a license file if none is specified on the command line. If the license file is not found at that location, the correlator will also search Apama/etc/ApamaServerLicense.xml in the installation directory. If the found license file is expired, the correlator will fail to start up. In order to run the correlator in evaluation mode, any expired license file must be removed.

If the license cannot be found, remote connections are now allowed. You are no longer restricted to communicating only with processes on the same machine.

The correlator log will now include the type and size of the largest container (sequence, dictionary, listener, stream window) in each MThread when the logging of garbage collection events has been enabled using the verbosegc command. This is to allow easier diagnostics of applications that are using unusual amounts of memory.

The file jms-mapping-spring.xml, which stores the rules for mapping between JMS messages and Apama events, is now generated directly into the bundle_instance_files\Correlator-Integrated_JMS folder of an Apama project. With previous versions, this file was generated into the bundle_instance_files\Correlator-Integrated_JMS\Generated folder. The Generated folder is no longer created and used by Apama.

The connection event now has a new reopen action: reopenWithACK which requires a callback. This is useful to know when a reopen succeeds or fails. We recommend that you use this method over the deprecated reopen().

The shutdownConnectionOnError action will now be based on the reconnect policy and will therefore no longer remove outstanding queries from the queue if, for example, you have a reconnect policy of RECONNECT_AND_RETRY_LAST. In this case, outstanding queries will remain on the queue to be retried on a successful reconnection.