Supplementary documentation for IBM® SDK, Java™ Technology Edition, Version 7 Release 1
Note: For links to downloads, fixes, time zone updates, and the table of comparative Oracle versions that used to be available in this document, see IBM SDK, Java Technology Edition refreshes.
The documentation to support this release is available in IBM Documentation. However, from service refresh 4 fix pack 25, only the security documentation is still maintained. Any updates or changes to other content are detailed in this technote.
Changes to the online content:
Supplementary information is available for the following updates:
- Service refresh 4 fix pack 85
- Service refresh 4 fix pack 80
- Service refresh 4 fix pack 45
- Service refresh 4 fix pack 40
- Service refresh 4 fix pack 20
- Service refresh 4 fix pack 10
- Service refresh 4 fix pack 1
- Service refresh 3 fix pack 10
- Service refresh 3
- Service refresh 2 fix pack 10
Changes to online content:
JCE Jurisdiction policy files
For older releases of the SDK, you had to obtain JCE jurisdiction policy files from a download site. Since service refresh 4 fix pack 20, the policy files have been included with the SDK, updated, and made more secure. Upgrade to the latest release to get the most recent and secure policy files. Version 7 Release 1 reaches end of service in September 2022. The old, downloadable policy files will be removed at that time. For more information about policy files, see SDK Security policy files in the documentation.
Configuring large page memory allocation on z/OS systems
There are changes to the content in the topic Configuring large page memory allocation . 1M pageable large pages are supported only on IBM zEnterprise EC12® or later systems. The online documentation states that the Flash Express® feature (#0402) is required. However, it is actually not required but recommended, only to avoid demoting 1 MB pageable large pages to 4 K pages when paging is required during periods of high real memory usage. When the 1 MB pageable large pages are demoted to 4 K pages, they remain as 4 K pages until a future system IPL.
On z/OS 2.3 and later, 1M pageable large pages are available by default. You no longer need to set the PAGESCM=ALL option in the IEASYSxx parmlib member.
Service refresh 4 fix pack 85 (May 2021)
Ubuntu 16.04 is no longer supported because it is now in extended security maintenance.
Service refresh 4 fix pack 80 (February 2021)
The supported level of the Microsoft Visual Studio compiler for Windows™ 64-bit on x86, listed in Supported compilers, is now 2017.
Service refresh 4 fix pack 45 (April 2019)
This release adds support for the new Japanese era name, Reiwa. For more information, see Japanese era changes for the IBM SDK, Java Technology Edition.
Service refresh 4 fix pack 40 (February 2019)
Changes to Korean codepoint mappings
In previous releases, if you used EUC-KR encoding to convert between EUC-KR codepoints and Unicode during string conversion, some Korean characters were not mapped to the expected Unicode values. This result is because the EUC-KR codepage was based on the IBM970 codepage. This behavior has been corrected in this release. The affected characters are as follows:
|EUC-KR mapping||Correct Unicode mapping||Character||Incorrect Unicode mapping||Character|
|0xA1A4||\u00B7||Middle dot||\u30FB||Katakana middle dot|
|0xA1AA||\u2015||Horizontal bar||\u2014||Em dash|
|0xA1AD||\u223C||Tilde operator||\u301C||Wave dash|
|0xA2A6||\uFF5E||Full-width tilde||\u02DC||Small tilde|
|0xA2C1||\u2299||Circled dot operator||\u25C9||Fisheye|
Note: java.nio.charset classes already used the correct mappings and are unaffected.
If you require the previous mappings, specify the -Dibm.useCp970=true system property on the command line when you run your application.
In addition, the following characters from the KS X 1001 standard have been added:
|EUC-KR mapping||Unicode mapping||Character|
|0xA2E8||\u327E||Korean postal code mark (circled hangul ieung u)|
Service refresh 4 fix pack 20 (January 2018)
Out of memory exceptions when running applications with compressed references enabled
The Oracle CPU for January contains an update for CVE-2018-2582 to fix vulnerabilities in the Hotspot virtual machine (VM) that might be exploited by Java web start applications and applets. Fixes are also applied for the OpenJ9 virtual machine. The fix increases the amount of low memory used for VMs that use compressed references. Customers who are running close to the maximum amount of allowed 32-bit memory might experience out of memory exceptions. A possible workaround is to use the -Xmcrs option to secure space in the lowest 4GB memory area for any native classes, monitors, and threads that are used by compressed references.
For more information about this option, see -Xmcrs .
Service refresh 4 fix pack 10 (October 2017)
Support for z/OS v2.3
This update includes support for z/OS v2.3.
Service refresh 4 fix pack 1 (February 2017)
Security vulnerability CVE-2016-2183
A further fix is added to mitigate against this vulnerability, which is described here . (APAR IV93288)
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 (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)
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.
When you download and install packages for this release, you can choose a language in which to review and accept the license. On 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.
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.
Was this topic helpful?
01 June 2022