Gen 8.6 Java Runtime abrt.json.jar Jackson class questions

Products

• Gen
• Gen - Host Encyclopedia
• Gen - Run Time Distributed
• Gen - Workstation Toolset

Issue/Introduction

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

• The Gen runtime library was expected to build and package using Java 8 specification.
• As we know, for Java 8 all classes inside the jar must have the signature 52 or lower. There is at least one class (module-info.class) that has the signature 53.
• The module descriptor file module-info.class, which is stored in the jar root folder, makes no sense for Java 8. The modules have been included in Java only starting with Java 9.
• The presence of the module-info.class file is confusing the Maven builder and dependency management fails.
• Please confirm if the genrt.jar classes are built and packaged using Java 8. Also, why is a module descriptor added when it is Java 9 and higher compliant.
  
  

     2. Unexpected third-party classes like Jackson serializer packaged inside the runtime jar.

• Some Jackson classes are packaged inside the jar.
• At runtime, these Jackson implementation classes will get in conflict with the Jackson classes already packaged in some of our projects. If the Jackson versions will not be the same, we will run into compatibility issues; these incompatibilities will translate into random runtime problems hard to identify with various results based on the class loader the application is going to use.
• As a good common practice, the Jackson classes must be included as a jar in its own and will be specified in our application packager. In our case that is Maven. Any reason why Jackson classes are packaged within the genrt.jar.
• Is there harm in excluding Jackson classes within genrt.jar and add them as a dependency at the project level. If it is fine, what Jackson library versions are supported.

Environment

Release : 8.63

Cause

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

Resolution

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.