OpenJDK 8 for VSI OpenVMS I64 Release Notes 09-Jun-2020 Introduction Thank you for your interest in this port of OpenJDK 8 for VSI OpenVMS I64. The current release of OpenJDK for VSI OpenVMS is based on the OpenJDK 8u222 distribution. OpenJDK (https://openjdk.java.net/) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). OpenJDK is licensed under the GNU General Public License (GNU GPL) Version 2 with a linking exception such that components linked to the Java Class library are not subject to the terms of the GPL license. OpenJDK is the official reference implementation of Java SE since Version 7. This release notes document contains installation instructions, details of any new features, known issues, and other information specific to this release of the software. This kit can be used to develop and run Java-based programs on VSI OpenVMS I64 Version 8.4-2L1 with latest updates (support for earlier versions of VSI OpenVMS I64 will be provided in a future release). Please ensure that you understand the copyright and license information before using this release (this information can be found in the top level directory of your OpenJDK installation). Note that OpenJDK 8 for VSI OpenVMS I64 is not an update for the Java™ Development Kit (JDK) 8 for the OpenVMS Integrity servers Operating System; it is a separate product. Fixed problems This release of OpenJDK for VSI OpenVMS is based on the 8u222 release. The OpenJDK release notes document http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009840.html provides details of problems fixed in this release. In addition to the fixed problems and updates included in the OpenJDK 8u222 release, a number of general issues encountered with previous versions of Java for OpenVMS have been resolved for this OpenJDK release, including the following: Upon certain exceptions (error conditions) the OpenVMS debugger could start unexpectedly. This problem has been fixed. Java crash dumps could sometimes be incomplete due to a second crash dump being initiated while the first crash dump was still in progress. This problem has been resolved. The code for creating child processes with inherited I/O has been significantly improved and is less error-prone. Issues associated with losing sub-process mailboxes have also been fixed. Enhancements to native code generation have eliminated the occurrence of a number of spurious errors and exceptions. Not all file versions were processed by IfExists() (java.nio.file.Files package) when the logical name JAVA$DELETE_ALL_VERSIONS was defined. This problem is resolved. The sun.nio.fs.UnixPath.toRealPath() method did not correctly resolve paths such as “path_to_dir/.” and “path_to_dir/subdir/..”. This problem has been fixed. In some cases the sun.nio.fs.UnixPath.toRealPath() method incorrectly resolved links. This problem has been fixed. The following C RTL features are enabled via LIB$INITIALIZE. Note that the logical names to enable some of these features are still included in java$setup.com in case users rely on these definitions for other purposes. – DECC$FILE_PERMISSION_UNIX – DECC$FILENAME_UNIX_NO_VERSION – DECC$FILE_SHARING – DECC$FD_LOCKING – DECC$EFS_CASE_PRESERVE – DECC$EFS_CHARSET – DECC$ARGV_PARSE_STYLE – DECC$READDIR_DROPDOTNOTYPE Atomic operations on improperly aligned values could result in %SYSTEM-F-ROPRAND errors. This problem has been resolved. The following JVM options have been changed: – The UseCompressedOops option is not supported in OpenJDK for VSI OpenVMS and is always set to false. – Only a subset of values can be used with the TypeProfileLevel JVM option. Specifically, for TypeProfileLevel=x00 x may only be 0, 1, or 2. Incorrect JVM exit status values were being set in some situations. Exit status values are now set in a correct and consistent manner. Problems with inconsistent file cache updates and renaming of cached files have been fixed. When remote debugging, programs would not start correctly due to listening sockets being closed when they should not have been. This problem has been resolved. When using sun.nio.fs.UnixNativeDispatcher.opendir() for an existing file (not a directory) an incorrect exception was being thrown. The correct exception is now reported. Compatibility OpenJDK 8 for VSI OpenVMS I64 is largely compatible with older Java versions for OpenVMS I64 and most existing Java programs will run without change on the OpenJDK platform. However, if you are moving from Oracle Java 6 for HPE OpenVMS to OpenJDK 8 for VSI OpenVMS there are some significant differences to be aware of. The following list identifies various differences between Oracle Java 6 for HPE OpenVMS and OpenJDK 8 for VSI OpenVMS that may impact the operation of some programs. Exclusive use of 64-bit pointers For Oracle Java 6 for HPE OpenVMS, the HotSpot Java Virtual Machine (JVM) utilized 64-bit pointers to facilitate the use of more than 2GB memory; however other binary components such as the launcher and shareable images called into by Java class libraries used only 32-bit pointers. OpenJDK 8 for VSI OpenVMS uses 64-bit pointers exclusively. As a consequence of this, any C or C++ application code using the Java Native Interface (JNI) will need to be recompiled to use 64-bit pointers (/POINTER_SIZE=64). Depending on the nature of the application code, this may necessitate some code changes. Symbol vector compatibility Symbol vectors in sharable images shipped with OpenJDK 8 for VSI OpenVMS will not necessarily match those of the equivalent images provided by Oracle Java 6 for HPE OpenVMS. Any C or C++ application code using the Java Native Interface (JNI) that links with these shareable images will need to be relinked. Removal of logical name JAVA$ENABLE_ENVIRONMENT_EXPANSION Commands to run Java programs can often be very long, and this can cause issues with DCL command line lengths. The logical name JAVA$ENABLE_ENVIRONMENT_EXPANSION was used in prior versions of Java for OpenVMS to help get around this issue such that any argument specified on the Java command line beginning with a “$” would be assumed to equate to a logical name (without the leading “$” character) that could specify a list of values and would be expanded out internally within Java, thereby avoiding issues with command line length. This facility was most commonly used to specify the Java class path (via the –cp or –classpath command line options), as class paths can often be very long; however the facility was little used for any other purpose. In OpenJDK 8 for VSI OpenVMS the Java virtual machine always checks the value supplied with the –cp or –classpath option to determine whether it equates to a logical name and if so then expansion occurs as before (as if the logical name JAVA$ENABLE_ENVIRONMENT_EXPANSION was defined), regardless of whether the argument has a leading “$” or not. It should also be noted that OpenJDK for VSI OpenVMS also supports the use of wildcards (“*”) in class path specifications. This feature can also be used to reduce the length of class path specifications. Logical name JAVA$FILENAME_CONTROLS defaults to “8” The logical name JAVA$FILENAME_CONTROLS can be used to control how OpenJDK interprets and maps file names (between UNIX and OpenVMS formats). This logical name now defaults to a value of 8, as this value generally affords greatest flexibility and most predictable results. Be sure to define JAVA$FILENAME_CONTROLS appropriately for your environment, particularly if an ODS-2 file system is used for .jar and/or .class files (however the use of ODS-2 file systems is not recommended). See examples in JAVA$FILENAME_CONTROLS.COM (found in SYS$COMMON:[OPENJDK$80.COM] assuming a default installation) for setting the variable JAVA$M_MULTI_DOT_KEEP_LAST to accommodate any particular file name mapping requirements. Changes to use of JAVA$FORK_PIPE_STYLE In Oracle Java 6 for HPE OpenVMS it was possible to specify values of 0, 1, and 2 for this logical name to control how pipes are established between parent and child processes. The value of 2 would cause sockets to be used instead of OpenVMS mailboxes or standard UNIX-style pipes. If JAVA$FORK_PIPE_STYLE is not defined then a default value of 1 is used (which causes mailboxes to be used for any inter-process communication). This is still the case for OpenJDK on VSI OpenVMS; however the value of 2 is no longer supported, and if a value of 2 or an invalid value is specified, this will not be accepted and the default value of 1 will silently be used. No debug versions of images The size of the HotSpot Java Virtual Machine is such that building a debug version is not possible and consequently OpenJDK for VSI OpenVMS does not provide debug versions of executable programs and shareable images. Case sensitivity of file names OpenJDK for VSI OpenVMS is more sensitive to the case of file names, and in general the names of .java and .class files should match identically the name of the class in question. For example, if you have a Java class named myClass, then the corresponding source file should be named myClass.java. This impacts both the JVM (the java command) and utilities such as the javac compiler. However, when compiling classes it is possible to specify Java source code file name arguments to javac in arbitrary case and the compiler will attempt to determine (and use) the true on-disk filename (which javac will expect to match the public class name). Mixed syntax file names Oracle Java 6 for HPE OpenVMS allowed mixed-syntax file names (file names containing a combination of UNIX-style and OpenVMS-style syntax). The use of mixed syntax is not supported by OpenJDK for VSI OpenVMS, and in general file names should ideally conform to UNIX-style syntax. For example, the following code will give an exception: File file = new File("[.log]/filetest.log"); java.awt.headless system property The system property java.awt.headless defaults to "true" for this release of OpenJDK for VSI OpenVMS.