Background
We build a customised Gen Runtime (Java) .jar with some mirror changes to User Exits.
We create the ‘genrt.jar’ by running the following command & parameters:
mkjavart genrt.jar clean JavaProxy OpLibrary EJB WCE TCPIP EJBRMI
In the past, we have never needed to update the ‘mkjavart.xml’ file to provide us with the desired result, but we have had to modify it to remove references to the file abrt.json.jar.
Questions/issues raised by our Java Development team:
There are a few issues regarding the genrt.jar library produced by the current Gen mkjavart.bat/mkjavart.xml files.
1. Java version compatibility
2. Unexpected third-party classes like Jackson serializer packaged inside the runtime jar.
Release : 8.63
The abrt.json.jar file was first added as part of the consuming Rest feature in PTF RTJ86208/LU03173.
Then it was updated in this security enhancement for jackson-databind PTF RTJ86211/LU05309.
It is also in the latest Gen 8.6.3 Consolidation PTF WKS86300/LU06327.
Gen™ 8.6 > Release Notes > New Features
1. Java version compatibility
Gen Engineering has advised that the abrt.json.jar is compatible with Java 8. They have encountered no problems with using it in Java 8 environments and it is also being used with Java 8 by other customers.
As the classes in that file are from a third party Engineering has no control over how they were packaged. They cannot go back to an earlier version because there is a security vulnerability in earlier versions.
As a further check, Gen Support also exploded the file abrt.json.jar into a directory and went through all class files in all sub-directories to check the major version. For the 3 main directories under com\fasterxml\jackson i.e. annotation, core and databind, they found that all classes under annotation and core had major version 50 while all classes under databind had major version 52. So all those classes would be Java 8 compatible. Only the module-info.class in the root folder of the file has later major version 53 which is incompatible with Java 8 and it seems that the only reason an issue was encountered was that the Maven configuration checked the version of that file.
2. Unexpected third-party classes like Jackson serializer packaged inside the runtime jar.
The Jackson classes are only used for parsing the JSON response on a REST call. If not using the new Call REST feature, it doesn't matter whether those classes are there or not. If the Call REST feature is used and the Jackson classes/jar files are in the classpath then the abrt.json.jar is not required. Even if Call REST is being used, Gen is using such a basic part of the Jackson library that it doesn't matter what version of the classes are used unless there are concerns about security vulnerabilities.