|
- For use of the PKCS#11 Implementation Provider Support, your z/OS operating system must be z/OS V1R9 or above.
- SDK V5 and SDK 6 takes advantage of enhanced z/OS linkage capabilities (XPLINK) for greatly improved performance. In most common cases, this will be done completely transparently. However, any application code that creates a JVM itself and interacts with the JVM via Java Native Interface(JNI) or any other "call" interface must create the Language Environment (LE) enclave specifying that LE should setup an XPLINK environment. That environment will include an XPLINK specific runtime library and stack format. This XPLINK LE enclave must be in place prior to creating the JVM. There are a variety of ways to accomplish this. They include setting a run-time option (XPLINK(ON)), or recompiling the launching application code to be XPLINK. These options and a description of the XPLINK technology are contained in the IBM Redbook, SG245991. Further details can be found in z/OS Language Environment Programming Guide.
Note that non-Java applications which are called through JNI subsequent to the instantiation of the JVM can be either XPLINK or non-XPLINK applications. Again, details are given in the above references.
- The persistent reusable and shared classes support in the 31-bit, IBM SDK for z/OS, Java 2 Technology Edition Product (5655-I56) is not present in this SDK 5 product.
- The new I/O (NIO) channels in this SDK and Runtime Environment have a number of limitations, listed in the following table. Click on the defect number to link to the Sun Web site that documents the limitation. To go directly to the bug, you must be a registered member of the Java Developer Connection. To see which bugs have been fixed, you should check the contents of any service refreshes of this SDK and Runtime Environment.
| List of new I/O limitations |
| Sun bug number |
Brief description of limitation |
| 4673298 |
Locking in Preferences sometimes fails on NFS mounted drives. NIO file locking over NFS might also be affected. |
At Version 1.4.2 (64-bit) and Version 5 (31-bit), the IBM Runtime Environment for z/OS contained new versions of the IBM Java Virtual Machine (JVM) and the Just-In-Time (JIT) compiler. If you are migrating from an older IBM Runtime Environment, note that:
- The JVM shared library libjvm.so is installed in directory jre/bin/j9vm. This directory is different, for example, from the Runtime Environment for z/OS for Version 1.4.2 (31-bit), where it is installed in jre/bin/classic. Native applications using the JNI invocation interface might need to add the new directory path to their environment variable or variables in order to locate the JVM dynamic link library.
- The JVM Monitoring Interface (JVMMI) is no longer available. You must rewrite applications that used that API. You are recommended to use the JVM Tool Interface (JVMTI) instead. The JVMTI is not functionally the equivalent of JVMMI. For information about JVMTI, see JVM Tool Interface (JVMTI) and the Diagnostics Guide.
- The new implementation of JNI conforms to the JNI specification, but differs from the old implementation. It returns copies of objects rather than pinning the objects. This difference can expose errors in JNI application code. For information about debugging JNI code, see -Xcheck:jni in Nonstandard options.
- The format and content of garbage collector verbose logs obtained using -verbose:gc have changed. The data is now formatted as XML. The data content reflects the changes to the implementation of garbage collection in the JVM, and most of the statistics that are output have changed. You must change any programs that process the verbose GC output so that they will work the new format and data. See the Diagnostics Guide for an example of the new verbose GC data.
- Earlier versions of the IBM JRE shipped with a file called rt.jar in the jre/lib directory. From Java V1.4 onwards, this file has been replaced by multiple JAR files that reside in the jre/lib directory.
- For additional industry compatibility and deprecated api information, see Sun's Java 6 Compatibility Documentation and Sun's Java 6 Deprecated API List.
- All z/OS Java SDK program products, whether the 31-bit SDK 1.4, 64-bit SDK 1.4, the 31- or 64-bit SDK 5, or the 31- or 64-bit SDK 6 products, can be installed and executed on the same z/OS machine. They are independent program products and can co-exist in any combination.
- The serial reusability feature of the IBM SDK for z/OS, version 1.4.2 (31-bit) and earlier, invoked using -Xresettable, is not supported. If you specify -Xresettable the JVM will issue an error message and will not start. The -Xinitasch and -Xinitth options, which allowed heap sizes to be specified for the resettable JVM, are ignored. You can share data between JVMs in an address space (the old -Xjvmset and -Xscmax options) using Class data sharing between JVMs, a new facility for 5.0. If you specify -Xjvmset or -Xscmax the JVM will issue an error message and will not start.
- Tracing class dependencies, invoked using -verbose:Xclassdep, is not supported. If you specify -verbose:Xclassdep the JVM will issue an error message and will not start.
Programs interacting with the 64-bit Java product, whether launching the JVM or being called from the JVM through the JNI interface, must be 64-bit programs. Programs dependent on JNI interfaces may require changes at the interface boundary to conform to 64-bit data types. Application JNI routines written in C will need to be recompiled for 64-bit, which may require some code changes.
| |
|
