- See more service summaries and restrictions
- Service summaries
- IBM 31-bit SDK for z/OS, Java Technology Edition Version 8
- IBM 64-bit SDK for z/OS, Java Technology Edition Version 8
- IBM 31-bit SDK for z/OS, V7 R1
- IBM 64-bit SDK for z/OS, V7 R1
- IBM 31-bit SDK for z/OS, V7
- IBM 64-bit SDK for z/OS, V7
- IBM 31-bit SDK for z/OS, V6.0.0 and V6.0.1
- IBM 64-bit SDK for z/OS, V6.0.0 and V6.0.1
- IBM 31-bit SDK for z/OS, V5
- IBM 64-bit SDK for z/OS, V5
Version 6.0.1 Considerations
Unless otherwise stated, the Restrictions and Migrations below for Version 6.0.0 also are applicable to Version 6.0.1.
Additional considerations for Version 6.0.1 include:
- The Diagnostic and User's Guide information deltas from Version 6.0.0 are consolidated in one manual for Version 6.0.1 called IBM SDK Java Technology Edition, Version 6 Supplement (PDF, 1MB). The supplement includes, among other topics, information about garbage collection. That manual should be used in conjunction with the SDK Guide for Version 6 (PDF, 994KB) and the IBM SDK Diagnostics Guide.
- There are new JZOS capabilities, described in the JZOS Batch Launcher and Toolkit Installation and User's Guide (PDF, 273KB), SA23-2245-03. From a migration consideration view, the following should be noted:
- The PackedDecimalAsIntField, PackedDecimalAsLongField, PackedDecimalAsBigIntegerField, and PackedDecimalAsBigDecimalField classes in the com.ibm.jzos.fields package have been changed so "get" methods that encounter an invalid sign will throw an IllegalArgumentException.
- Some JZOS methods have been enhanced so that invalid arguments will cause IllegalArgumentExceptions.
- ZFile.obtainDSN() is updated to return null if the specified dsn does not have a DSCB in the VTOC. (In earlier releases, the same method returns a pseudo DSCB.)
Additional considerations for Version 6.0.1 SR1 and Version 6.0.0 SR10 or later include:
- See the National Institute of Standards and Technology (NIST) recommendations for default encryption key lengths changes section in Restrictions/Considerations when using the IBMPKCS11Impl provider on z/OS.
- The changes are made to the locale translation files to make them consistent with Oracle JDK 6.
The following locales are changed:
Slovakia : Day abbreviations for Friday, Eras
Malaysia : Day abbreviations
France : Eras, NumberPatterns for percent, DateTimePatternChars
Slovenia : Eras
Bulgaria : DayNames for Thursday
Germany : DateTimePatterns
Czech Republic : AmPmMarkers
Turkey : NumberPatterns for currency and percent
Serbia : MonthNames, MonthAbbreviations, DayNames, DayAbbreviations
To understand the differences in detail, see technote. Include the -Dcom.ibm.UseCLDR16 system property on the command-line to revert to the locale translation files used in earlier releases.
- After the application of this Service Refresh (SR), Java applications or applets that have a legitimate need to set a particular SSLSocketFactory will require that the Java security java.policy file be updated to include "setFactory" permission (java.lang.RuntimePermission("setFactory"), if it is not already there.
Back to top
- For use of the PKCS#11 Implementation Provider Support, your z/OS operating system must be z/OS V1R9 or above. Note: SDK6 Version 6 Release 0 Modification 1 pre-reqs z/OS V1.10 and above, so this restriction is not applicable for Version 6.0.1.
- 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, SG24-5991. Further details can be found in z/OS Language Environment Programming Guide (PDF, 6.8MB).
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 limitation is 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. This limitation is lifted as of SDK6 SR8 and later in Version 6.0.0 and does not apply to Version 6.0.1.
List of new I/O limitations
|Sun bug number
||Brief description of limitation
||Locking in Preferences sometimes fails on NFS mounted drives. NIO file locking over NFS might also be affected.
Back to top
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 the Java SE 6 Compatibility Documentation and Java SE 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 (PDF, 378KB) 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.
Back to top
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.
Back to top