Support information for IBM® SDK, Java™ Technology Edition, Version 7 Release 1 that is not available in the user documentation.
The documentation to support this release is available in the online product documentation.
Supplementary information is available for the following updates:
- Service refresh 3 fix pack 10
- Service refresh 3 fix pack 1
- Service refresh 3
- Service refresh 2 fix pack 10
For information about the daylight saving time changes included in this release, see Olson time zone updates. Later updates can by applied using the IBM Time Zone Update Utility for Java (JTZU).
To compare the IBM SDK functionality with Oracle build levels at each service refresh level, see Comparative Oracle build levels.
You can download the SDK from developerWorks.
Service refresh 3 fix pack 10 (July 2015)
Partial fix for change in behavior for -Xshareclasses:destroyAll
In service refresh 2 fix pack 10 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 3 fix pack 1 (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 3 (May 2015)
DumpControlMXBean visible in JConsole
The DumpControlMXBean is unintentionally visible in JConsole. Do not use this MXBean to create heap, system, or Java dumps. Instead, use the Health Center tool as described in Triggering Dumps.
Service refresh 2 fix pack 10 (February 2015)
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
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.
This feature is no longer available as part of this release but can be obtained from the Multitenant JVM community site for evaluation.
The following limitations apply when you are using the -Xmt option:
JAVA_TOOLS_OPTIONS environment variable
Setting parameters with the JAVA_TOOLS_OPTIONS environment variable is not supported.
If you specify the
-Djavad.home option after the target class, it will be parsed incorrectly as an option, instead of an argument to the program.
If you specify multiple instances of the -Djavad.home option, the first instance takes precedence. This behavior is incorrect; the final instance should take precedence, as is the convention with other conflicting command-line options.
When you add options to the
javad.options file, each option must be on a separate line. Combining multiple options on the same line does not work.
If you specify options that are not valid on the command line, the options are silently ignored and the JVM continues to start.
When using API methods such as memoryBean.getHeapMemoryUsage() in a tenant, you might not get a value for each tenant. Depending on the API you use, and the method in which it is called, you might get either a value for the specific tenant, or a value for the entire javad process.
If an application uses the java.nio.file.WatchService class but fails to call the close() method before the application ends, thread resources might not be cleaned up completely. If the resources are not cleaned up completely, the tenant does not shut down.
Use of the
-Xlimit:diskIO resource control feature affects the speed of read and write operations to disk when very small amounts of data are being written. For example, if your application makes continuous write operations of one byte at a time by using the FileOutputStream.write method, there is a noticeable performance degradation. However, this performance degradation is not noticeable if you instead write 4 KB at a time.
Use of the
-Xlimit:netIO resource control feature might result in 10% to 20% network throughput degradation for both regular and datagram sockets, depending on the length of data that is read or written. For example, if your application makes continuous write operations of a few bytes at a time, you might see this impact on throughput.
If your application uses the
-Xlimit:threads option and the AsyncIO API is used, the threads started by the AsyncIO API are included in the limit. The result is that your application might receive a ResourceConsumptionException if too small a limit was specified.
When you download and install packages for this release, you can choose a language in which to review and accept the license. On Windows (Installshied) packages, and AIX® or Linux (InstallAnywhere) archive packages, there is no option to review the license in Lithuanian even though a Lithuanian license exists in the package. You must choose an alternative language during installation and then review the contents of the Lithuanian license, which can be found in the docs/lt directory.
Known problem with zEDC
As per the specification of the java.util.zip.Deflater.setlevel() API, the deflate() API must not compress the data if the level is set to zero. However, with zEDC hardware compression, the deflate() API does compress the data when java.util.zip.Deflater.setlevel(0) is set. You can work around this problem by switching to software compression on z/OS®, which can be achieved by using one of these methods:
- Set the z/OS environment variable _HZC_COMPRESSION_METHOD, by specifying the following command: export _HZC_COMPRESSION_METHOD=software
- Disable the zEDC hardware adapter by making it offline.
- Remove READ ACCESS to resource class FPZ.ACCELERATOR.COMPRESSION, which is a System Authorization Facility (SAF) FACILITY that protects access to the zEnterprise® Data Compression Express® coprocessor.
Co-existence of releases
IBM SDK, Java Technology Edition Version 7 Release 1 can co-exist with IBM SDK, Java Technology Edition Version 7 on the same Windows operating system. However, if the first installation is removed, the Windows registry is corrupted and the following error is seen when you run the java -version command:
Error: Failed reading value of registry key:
Software\IBM\Java2 Runtime Environment\CurrentVersion
Error: could not find java.dll
Error: Could not find Java SE Runtime Environment.
This problem occurs when the second installation is installed as the system or non-system JVM. In this situation, you can obtain version information by specifying the full installation path when you run the java -version command.
Comparative Oracle build levels
The following table indicates the Oracle FCS build level that has comparative functionality to the IBM SDK:
|Release date||IBM SDK 7 Release 1||Oracle Java 7 FCS build|
|December 2013||Initial release||7 Update 45 Build 18|
|April 2014||Service refresh 1||7 Update 55 Build 13|
|July 2014||Service refresh 1 fix pack 1||7 Update 65 Build 19|
|November 2014||Service refresh 2||7 Update 71 Build 13|
|February 2015||Service refresh 2 fix pack 10||7 Update 75 Build 13|
|May 2015||Service refresh 3||7 Update 79 Build 14|
|July 2015||Service refresh 3 fix pack 10||7 Update 85 Build 15|