How to migrate from the Classic JVM to the IBM J9 JVM

Brief introduction

Starting with IBM I 7.1, IBM Classic Java Virtual Machine is no longer supported by IBM I. The IBM Technology for Java Virtual Machine (also known as the IBM J9 JVM) became the only supported JVM. This article is intended to illustrate the differences between the two JVMs, while helping users and developers migrate their applications from the Classic JVM to the J9 JVM. On IBM i, all versions of the Java Development Kit (JDK) are published in the form of the Java License Program option (for example, 5761JV1 products on IBM i 7.1).

Although this document discusses the differences between the Classic JVM and the J9 JVM in a detailed and comprehensive way, this does not mean that the migration from the Classic JVM to the J9 JVM is difficult or requires significant changes to the application. For most users, the change from the Classic JVM to the J9 JVM is a very simple process. In most cases, just change the java_home and their application will work. The purpose of this document is to give users who are having problems, this document can help them quickly understand what the problem is, and solve the problem as soon as possible.

The difference between the user interface

Select the desired JDK version

In the past, when using the Classic JVM, the system property "Java.version" was used to set a specific version of the JDK for the Java application. For example, after using the command "java-djava.version=1.5 HelloWorld", the Classic JVM runs HelloWorld with JDK 1.5.

For the J9 JVM, the system property "Java.version" is not supported. The only way to set the JDK version is to set the environment variable java_home. For example, if you set the Java_home to "/qopensys/qibm/proddata/javavm/jdk50/32bit", we can have the J9 JVM run on JDK 1.5 32bit. The J9 provides 32bit and 64bit two versions for each JDK.

CL command

Commands related to the associated Java program

Direct execution is a technique for creating Java programs from Java class files, jar files, or zip files. When using the Classic JVM, all jar files or class files are required to be shipped with a *JVAPGM object. This object contains 2 main parts: One is the pre-approved bytecode and the other is the code generated by direct execution.

Starting with IBM I 6.1, the ability to run Java programs in direct execution (DE) mode is no longer supported, and direct execution's code cannot be run again, but the Classic JVM still requires *JVAPGM, so we can still To benefit from this kind of pre validated byte code.

At IBM I 7.1, some Classic JVM commands are still available. These commands are: ANZJVAPGM, CRTJVAPGM, DSPJVAPGM, CHGJVAPGM, and DLTJVAPGM. On I 7.1, Jars and class files can have *JVAPGM objects, but these objects are completely ignored by the JVM. On I 7.2, any jar or class file that has a *jvapgm object will be deleted if it has a *JVAPGM object.

Commands for JVM job management and analysis

On IBM I, there are commands to help manage JVM jobs and debug problems. Some commands apply to the Classic JVM, some for the J9 JVM, and two for all. The following is a list of these commands:

ANZJVM: Applies only to Classic JVMs.

Dspjvmjob: Applies to both Classic and J9 JVMs.

DMPJVM: Applies only to Classic JVMs.

Genjvmdmp: Starting from I 6.1, only applies to J9 JVM.

Prtjvmjob: Starting from I 6.1, only applies to J9 JVM.

Wrkjvmjob: Starting from I 6.1, only applies to J9 JVM.

JAVA and Runjva

The Gchmax option of the JAVA command and the Runjava command is *nomax only for the Classic JVM. J9 JVMs does not support *nomax values, but instead uses the values set by-XMX as the maximum heap size. If you do not set the-xmx,j9 JVM use 2G as the default value.

"Java Hello" and "Java Qibmhello"

The Classic JVM provides a "Hello" class file in the root directory of its classpath, while the J9 JVM provides Qibmhello.

System Properties

In previous versions of IBM I, the Classic JVM supported specific system properties that were no longer supported in J9JDK. Users who use these system properties need to find the corresponding system attributes (or methods) in the J9 JVM to achieve their needs. Table 1 is a list of these properties that are no longer supported by J9: