Support information that is not available in the user documentation, for IBM® 31-bit and 64-bit SDK for z/OS®, Java™ Technology Edition, Version 6, Release 0, Modification 1, and for any other IBM products that include IBM SDK, Java Technology Edition, Version 6 with an IBM J9 Version 2.6 virtual machine.
The documentation to support IBM SDK, Java Technology Edition, Version 6 (J9 VM2.6) is available in the product documentation. Supplementary information is available in this support document.
JCE FIPS guide
The certified JCE FIPS guide can be found here: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1993.pdf
PKCS11 security provider
The following card is supported in a limited fashion on the AIX® platform, in both 32-bit and 64-bit modes:
- The IBM 4765 PCIe Cryptographic Coprocessor is supported for use only by Tivoli Key Lifecycle Manager (TKLM) release 2.0.1, and follow-on releases.
Note: For TKLM, only the following PKCS#11 crypto operations are supported:
- Translate an AES 128-bit or 256-bit software key to an AES hardware (PKCS#11) key
- Generate an AES 128-bit or 256-bit key
- Encrypt and decrypt data using an AES key and an AES/ECB/NoPadding cipher
- Store and retrieve an AES key to/from a PKCS11IMPLKS (PKCS#11) key store
See additional supplementary information that is available for the following release levels:
- Service refresh 8 fix pack 7
- Service refresh 8 fix pack 5
- Service refresh 8 fix pack 3
- Service refresh 6
- Service refresh 5 fix pack 2
- Service refresh 5 fix pack 1
- Service refresh 5
- Service refresh 2
For information about security fixes, see Security Alerts.
For information about IBM fixes. see IBM fixes for IBM SDK, Java Technology Edition, Version 6 (J9 2.6 VM).
For information about the daylight saving time changes included in service refreshes and fix pack levels, see Olson time zone updates. Later updates can by applied using the IBM Time Zone Update Utility for Java (JTZU).
Service refresh 8 fix pack 7 (July 2015)
Partial fix for change in behavior for -Xshareclasses:destroyAll
In fix pack 3, a behavior change was reported for this option on z/OS platforms. See Change in behavior for -Xshareclasses:destroyAll.
Following a fix for the 64-bit JVM, the problem remains only on the 31-bit JVM. When the destroyAll option is invoked from a 31-bit JVM, 64-bit caches are not destroyed. The following message is displayed:
JVMSHRC735I Use a 64-bit JVM to perform the requested operation on the 64-bit shared cache \"cachename\" as the 31-bit JVM cannot verify that the shared memory was created by the JVM
Service refresh 8 fix pack 5 (June 2015)
Logjam security vulnerability
A potential weakness is exposed with DH and DHE cipher suites that relates to the Logjam security vulnerability. A fix is provided to address this issue. For more information, see IBM SDK, Java Technology Edition: Fix packs to address the Logjam security vulnerability (CVE-2015-4000).
Service refresh 8 fix pack 3
Change in behavior for -Xshareclasses:destroyAll
Due to a current issue on z/OS, when the destroyAll option is invoked from a 31-bit Java virtual machine (JVM), 64-bit caches are not removed. Similarly, when the destroyAll option is invoked from a 64-bit JVM, 31-bit caches are not removed. The following message is displayed:
JVMSHRC735I: Use a nn-bit JVM to perform the requested operation on the nn-bit shared cache \"cachename\" as the nn-bit JVM cannot verify that the shared memory was created by the JVM.
Service refresh 6
Unexpected XSLT error on extension elements or extension functions when Java security is enabled
Any attempt to use extension elements or extension functions when Java security is enabled, results in a javax.xml.transform.TransformerException error during XSLT processing. This change in behavior is introduced to enhance security. For more information, see Unexpected XSLT error on extension elements or extension functions when Java security is enabled.
Service refresh 5 fix pack 2
This fix pack includes a change to the default value for the RMI property java.rmi.server.useCodebaseOnly from false to true, which might cause unexpected errors for applications that use RMI. For more information, see http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html.
On Windows, improvements are made to the way that Runtime.exec decodes command strings. However, applications specifying commands that contain spaces in the program name, or that use quotation marks incorrectly, might fail to start. For more information, including guidance on resolving problems, see http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#jaruntime.
Service refresh 5 fix pack 1
This fix pack contains a security fix for the Oracle security vulnerability, CVE-2013-0169. For any further security fixes in this release, see Security alerts.
A security enhancement is included to correctly validate certificates on jar files of applications. After upgrading, a CertificateException occurs for any applications in one of the following scenarios:
- The application jar is not properly signed.
- The application jar has incorrect certificates.
- A certificate in the certificate chain is revoked.
To avoid these exceptions, make sure that your application jars are signed with valid certificates before upgrading from an earlier release. This issue relates to APAR IV38456.
Service refresh 5
The following change is included in this release:
Non-blocking registration of interested operations with selectors on the AIX operating system
In this release, the implementation of the registration of interested operations with the java.nio.channels.Selector class has been modified to avoid blocked threads.
In previous releases, this implementation could cause blocking of threads on the AIX® operating system. If a Java application used the java.nio.channels.SelectionKey.interestOps() method to register an interested operation with a Selector object that was engaged in a polling operation, the registering thread could be blocked. A thread that is blocked in this way can cause the application to hang or timeout. The following Java stack traces from such a situation show that the first thread is performing a poll operation, and the second thread is blocked:
3XMTHREADINFO "Thread-2" TID:0x31E65800, j9thread_t:0x31C9764C, state:R, prio=5
3XMTHREADINFO1 (native thread ID:0x2AA00A5, native priority:0x5, native policy:UNKNOWN)
4XESTACKTRACE at sun/nio/ch/PollArrayWrapper.poll0(Native Method)
4XESTACKTRACE at sun/nio/ch/PollArrayWrapper.poll(PollArrayWrapper.java:116)
4XESTACKTRACE at sun/nio/ch/PollSelectorImpl.doSelect(PollSelectorImpl.java:57)
4XESTACKTRACE at sun/nio/ch/SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
4XESTACKTRACE at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:80)
4XESTACKTRACE at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:84)
4XESTACKTRACE at BlockIntOpsReg.run(BlockIntOpsReg.java:18)
4XESTACKTRACE at java/lang/Thread.run(Thread.java:735)
3XMTHREADINFO "main" TID:0x30A65500, j9thread_t:0x301162D4, state:B, prio=5
3XMTHREADINFO1 (native thread ID:0x14A005F, native priority:0x5, native policy:UNKNOWN)
4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:103)
4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.interestOps(SelectionKeyImpl.java:65)
4XESTACKTRACE at BlockIntOpsReg.main(BlockIntOpsReg.java:40)
This thread blocking was caused by the pollset implementation using a Java cache of limited size to store requests for registration of interested operations. When the cache reached its size limit, the implementation attempted to register all the requests in the Java cache into the native AIX pollset cache, which could result in blocked threads. From this release, the Java cache size is unlimited, and interested operations are registered just before the next poll operation, to avoid blocking of threads.
For more information about I/O polling on the AIX operating system, see the following developerWorks article: Efficient I/O event polling through the pollset interface on AIX.
Service refresh 2
The following change is included in this release:
This change relates to Oracle security vulnerability CVE-2012-0502.
The KeyboardFocusManager specification explicitly allows a single, global KeyboardFocusManager for all applets. Some public methods are unsafe for such implementations.
As a result of the fix, the following methods now throw a java.lang.SecurityException if they are invoked on a java.awt.KeyboardFocusManager that is not the current java.awt.KeyboardFocusManager for the calling thread's context:
- java.awt.KeyboardFocusManager.setGlobalFocusOwner(Component focusOwner)
- java.awt.KeyboardFocusManager.setGlobalPermanentFocusOwner(Component PermanentFocusOwner)
- java.awt.KeyboardFocusManager.setGlobalFocusedWindow(Window focusedWindow)
- java.awt.KeyboardFocusManager.setGlobalActiveWindow(Window activeWindow)
- java.awt.KeyboardFocusManager.setGlobalCurrentFocusCycleRoot(Container newFocusCycleRoot)
Comparative Oracle build levels
The following table indicates the Oracle FCS build level that has comparative functionality to recent releases of the IBM SDK:
|IBM SDK 6 (J9 VM2.6)||Oracle Java 6 FCS build|
|GA||Update 21 Build 06|
|Service refresh 1||Update 27 Build 02|
|Service refresh 2||Update 27 Build 02|
|Service refresh 3||Update 32 Build 05|
|Service refresh 4||Update 32 Build 05|
|Service refresh 5||Update 39 Build 02|
|Service refresh 6||Update 51 Build 09|
|Service refresh 7||Update 65 Build 11|
|Service refresh 8||Update 75 Build 13|
|Service refresh 8 fix pack 1||Update 81 Build 08|
|Service refresh 8 fix pack 2||Update 85 Build 13|
|Service refresh 8 fix pack 3||Update 91 Build 13|
|Service refresh 8 fix pack 4||Update 95 Build 11|
|Service refresh 8 fix pack 7||Update 101 Build 14|