Newer releases of Java 1.8 JRE/JDK now cause CIMTool startup to fail with an ICU4J error during initialization.

[admin-cimug]

Given that CIMTool currently utilizes the older Eclipse 3.x plugin foundation it means the CIMTool must run on a 64-bit Java 1.8 JRE/JDK. New supported releases are currently available for this older version of Java at either:

https://www.java.com/en/download/ (The latest Oracle release)
or
https://www.azul.com/downloads/?package=jdk#download-openjdk (Azul OpenJDK)

At the time of the writing of this issue both of these release options are currently at version 333.

It has been discovered that at some point in the release history of these JRE/JDKs that the ICU4J project utilized for internationalization support features was upgraded in the JRE/JDK. Therefore, the ICU4J jar file originally included in the release of CIMTool (i.e. icu4j-3.4.4.jar in the Kena project \lib folder) now produces one of the two flavors of error messages in the console (as shown below) on either startup and/or loading of a CIMTool project.

Presently, we have been unable to determine which specific release that this occurred in but detailed testing with older releases of the Java 1.8 JRE have narrowed it down to somewhere between release 201 and the latest release (i.e. 333). As a result new users of CIMTool that install CIMTool and a newer Java 1.8 JRE/JDK are unable to fully utilize CIMTool. Research into the issues has provided various sources of information that may be helpful in resolving the problem:

• An example update of ICU4J to version 67.1 in JRE 15: https://bugs.openjdk.org/browse/JDK-8243504?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
• Release build instructions that are specific to JDK 1.8 and how to build an icu4j-x.x.x.jar file compatable with ICU 69.1 release: https://icu.unicode.org/processes/release/tasks/release-build (Note this URL may prove to be particularly important)
• The latest icu4j.68.1.jar file that may be able to replace the current jar file in the Kena project. Note that this must be thoroughly tested to ensure it works. There may be a need to compile and generate a JRE7/JRE8 compatible jar file using a JRE7 compiler if the jar file available in Maven Sonatype was compiled using a newer JRE/JDK and is not compatible with the older version. This must be vetted out: https://oss.sonatype.org/#nexus-search;gav~com.ibm.icu~icu4j~~~~kw,versionexpand & https://oss.sonatype.org/#nexus-search;quick~com.ibm.icu

[admin-cimug]

I have verified that the latest release of the jar at the time of this writing icu4j-71.1.jar file in Maven Central's Sonatype repository (refer to: https://oss.sonatype.org/#nexus-search;gav~com.ibm.icu~icu4j~~~~kw,versionexpand) was created by 1.8.0_282-b08 and has it's manifest specified with the Bundle-RequiredExecutionEnvironment: JavaSE-1.7 setting (see the manifest below for details). Therefore it may be possible that an upgrade of the jar should minimally be compatible with CIMTool without a custom build.

Note also that further investigation determined the following transitions points. This may be useful in determining which version of the jar file may be required to be upgraded to. The release boundaries are:

release 56.2: Bundle-RequiredExecutionEnvironment: J2SE-1.5 (this is the last release that required 1.5 or higher)
release 62.2: Bundle-RequiredExecutionEnvironment: JavaSE-1.6 (this is the last release that required 1.6 or higher)
release 63.1 to latest: Bundle-RequiredExecutionEnvironment: JavaSE-1.7

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.10.7
Created-By: 1.8.0_322-b06 (Temurin)
Specification-Title: International Components for Unicode for Java
Specification-Version: 71
Specification-Vendor: Unicode, Inc.
Implementation-Title: International Components for Unicode for Java
Implementation-Version: 71.1
Implementation-Vendor: Unicode, Inc.
Implementation-Vendor-Id: org.unicode
Bundle-ManifestVersion: 2
Bundle-Name: ICU4J
Bundle-Description: International Components for Unicode for Java
Bundle-SymbolicName: com.ibm.icu
Bundle-Version: 71.1
Bundle-Vendor: Unicode, Inc.
Bundle-Copyright: © 2016 and later: Unicode, Inc. and others. License
  & terms of use: http://www.unicode.org/copyright.html
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Main-Class: com.ibm.icu.util.VersionInfo
Export-Package: com.ibm.icu.lang,com.ibm.icu.math,com.ibm.icu.number,c
 om.ibm.icu.text,com.ibm.icu.util
Automatic-Module-Name: com.ibm.icu

[admin-cimug]

This has been resolved by replacing the icu4j-3.4.4.jar file in the \lib folder of the Kena project with release 71.1 of the ICU4J project jar (icu4j-71.1.jar). Testing was completed against the newest Java 8 releases from both Oracle and Zulu OpenJDK with success.

However, what should be noted is that this allows CIMTool (as of 1.10.0.RC2) to be run against new JRE/JDKs, but release prior to this release will no longer launch successfully. The below screenshot illustrates the error that occurs when older releases are launched against new release of Java 8. As described in this stack overflow entry the cause of this error is a result of the following:

This is likely caused by an older version of ICU4J in your classpath. The VersionInfo class was limited to 2-character version numbers, setting a limit to 255. Since Java 8 is now at 1.8.0_291, the 291 exceeds the 2-character limit, causing the ICU4J VersionInfo exception. ICU-21219 is fixed in ICU4J:68.1

So unfortunately, given the nature of the issue, by providing a fix for the original error we have the unavoidable side affect that older versions can not run against new Java 8 releases. There is no critical need to have older releases of CIMTool on a system as the latest CIMTool release should have all functionality of prior releases and projects created in older versions are fully compatible with new releases of CIMTool. However, if someone does desire to have both older and new CIMTool releases co-exist on a system the following two approaches can be used to allow the older releases to function:

Both an old and a new version of Java 8 JRE/JDKs will need to be installed on the user's system (in two distinct locations) and then the -vm parameter explicitly passed in during a call to the CIMTool.exe executable. This can be accomplished via either:

• a Windows shortcut for the CIMTool.exe executable

• by the use of a Windows .bat file to pass in the -vm parameter during invocatoin.

  NOTE: the CIMTool installation and setup pages should be updated to reflect this as well.

[admin-cimug]

Issue is being closed as a result of the solution previously described in earlier comments.