OpenJDK V8.0-412B-1

Support for POSIX-compatible file I/O has been significantly reworked.

x86-64 only: Redirection of stderr to/from files has been fixed.

OpenVMS-specific code has been optimized so that directories could not be opened as regular files.

Support for java.awt.Robot has been added.

A bug that occured upon creating a pipe with a child process has been fixed.

Non-blocking socket reading has been improved.

A problem with the error Exception: java.lang.OutOfMemoryError has been resolved.

This release contains numerous bugfixes from the OpenJDK community, including security fixes: CVE-2023-22045, CVE-2023-22049, CVE-2023-22067, CVE-2023-22081, CVE-2024-20918, CVE-2024-20919, CVE-2024-20921, CVE-2024-20926, CVE-2024-20945, CVE-2024-20952, CVE-2024-21011, CVE-2024-21085, CVE-2024-21068, and CVE-2024-21094.

Please see the official release notes for more detail - https://wiki.openjdk.org/display/jdk8u/Main.

SSL-independency has been introduced; the new version uses the system get_entropy method for random number/seed generation.

OpenJDK on X86: X11 terminal support was added. The bugs found in the Field Test version have been fixed.

JNI examples have been added to the product.

A bug, due to which the path/name of the options file needed was not provided after specifying the -V argument, has been fixed.

The V8.0-372 release of OpenJDK for VSI OpenVMS IA-64 is supported on VSI OpenVMS IA-64 V8.4- 2L1 or higher. It cannot be installed on VSI OpenVMS IA-64 V8.4-2 or lower.

An attempt to write to a closed pipe used to result in %C-F-SIGPIPE, broken pipe exception. Now, the correct java.io.IOException: broken pipe is created in this case.

A bug in the string conversion module that caused a memory leak has been fixed.

This release contains numerous bugfixes, including the security fixes: CVE-2023-21930, CVE2023-21937, CVE-2023-21938, CVE-2023-21939, CVE-2023-21954, CVE-2023-21967, CVE-2023-21968.

Please see the official release page for details - https://mail.openjdk.org/pipermail/jdk8udev/2023-April/017039.html.

The V8.0-222B release of OpenJDK for VSI OpenVMS is supported on VSI OpenVMS IA-64 V8.4-1H1 or higher (the previous release could only be used with VSI OpenVMS V8.4-2L1).

Unlike previous versions of Java for OpenVMS, OpenJDK for VSI OpenVMS does not normally require any DECC logical names to be defined in order to enable certain C RTL features required for correct JVM operation, with such features instead being enabled on JVM start-up via LIB$INITAILIZE. However, there may be some situations that require customization of the set of C RTL features that are enabled or disabled. This release of OpenJDK for OpenVMS provides a new logical name (JAVA$DONT_PRESET_LOGICALS) that can be used to prevent LIB$INITAILIZE from setting any C RTL features, allowing the user to explicitly specify which C RTL features are enabled by defining the relevant DECC logical names. The new logical name JAVA$DONT_PRESET_LOGICALS can be defined to any value (OpenJDK simply checks for existence of the logical name). Note that this new logical name should be used with considerable caution, and applications that rely on this setting should be thoroughly tested to ensure that there are no side-effects.

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:

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.

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. For Java applications that use AWT graphical user interface components, it is necessary to explicitly set java.awt.headless to false either via the java command line ("- Djava.awt.headless=false") or programmatically.

As a specific example, if you use the Archive Backup System (ABS) graphical user interface, the start-up script SYS$COMMON:[MDMS.SYSTEM]MDMS$START_GUI.COM should be modified to include -Djava.awt.headless=false on the Java command line, as follows:

$ java "-Xmx64M" "-Djava.awt.headless=false" "absview.ABSView" 

The CRTL feature DECC$READDIR_DROPDOTNOTYPE is enabled

This CRTL feature controls how the OpenVMS C RTL treats file names with no extension (no file type). Without this feature enabled, problems can occur when performing operations such as adding a directory containing files with no extension to a jar file such that the files with no extension appear in the jar with a “.” appended to the names. This can then cause problems if your Java code specifically tries to access those files in the jar. Appending the “.” is the typical C RTL behaviour when scanning a directory to return a list of file names; this behaviour is overridden by enabling the DECC$READDIR_DROPDOTNOTYPE feature.

Exit status

Upon normal successful completion, java, javac, and other executable utilities will consistently exit with a status of "%X10000001".

Location of error logs

In the event of an unrecoverable error condition, the JVM will attempt to create a log file containing potentially useful information about the crash. Oracle Java 6 for HPE OpenVMS would attempt to create these files in the equivalent of the UNIX/Linux tmp directory, which unless otherwise defined, is mapped by the OpenVMS C RTL to SYS$SCRATCH. To avoid any ambiguity, this release explicitly uses SYS$SCRATCH instead of tmp.

HPE Secure Web Browser compatibility

OpenJDK for VSI OpenVMS is not compatible with the HPE Secure Web Browser for OpenVMS. A compatible browser plugin may be provided at a later date.

Not compatible with Availability Manager Analyser

The Availability Manager Analyser kit includes a compatible JRE (Java Runtime Environment). Availability Manager Analyser will not work correctly with OpenJDK for VSI OpenVMS and the use of the bundled JRE should not be overridden or bypassed in any way. An updated Availability Manager Analyser that can be used with OpenJDK for VSI OpenVMS will be made available in due course.

JAVA$DAEMONIZE_MAIN_THREAD logical name deprecated

In Oracle Java 6 for HPE OpenVMS this logical name could be used to “daemonize” the main JVM thread, making it less susceptible to various types of interruption (particularly ASTs) that run on the main thread. This is the default for OpenJDK 8 for VSI OpenVMS. The logical name JAVA$DAEMONIZE_MAIN_THREAD therefore serves no purpose and defining it will have no effect on JVM operation.

VSI OpenVMS x86-64 Version 9.2-2 Update 2

VSI TCP/IP, HPE TCP/IP Services for OpenVMS, or the Process Software MultiNet TCP/IP stack for network communication

The software must be installed on an ODS-5-enabled file system (the software cannot be installed on an ODS-2 file system)

DECWindows Motif V1.5 or higher (note that this is required even if you are not using the Java AWT, as functionality provided by the Motif libraries is used for some non-AWT functions)

The OpenVMS internationalization data kit (VMSI18N) must be installed in order to use the Java debugger, jdb.

Kernel support for Thread Manager upcalls must be enabled (do not disable Thread Manager upcalls using either the image flags or the MULTITHREAD system parameter)

Development tools (SYS$COMMON:[OPENJDK$80.BIN])

This area contains programs that will help you develop, execute, debug, and document programs written in the Java programming language.

Runtime environment (JRE) (SYS$COMMON:[OPENJDK$80.JRE])

An implementation of the Runtime Environment (JRE). The runtime environment includes a virtual machine for Java, class libraries, and other files that support the execution of programs written in the Java programming language.

Additional libraries (SYS$COMMON:[OPENJDK$80.LIB])

Additional class libraries and support files required by the development tools.

C header files (SYS$COMMON:[OPENJDK$80.INCLUDE])

Header files that support native-code programming using the Java Native Interface (JNI) and the JVM Tools Interface.

JNI example code (SYS$COMMON:[OPENJDK$80.examples.jni])

Simple example code that illustrates using the JNI to call C code from Java and to call Java (invoke a JVM instance) from C.

When trying to work with fonts from the FreeType library or pictures in jpg format, errors may occur.

The redirect stderr to the file does not work yet.

Use of the JAVA$READDIR_CASE_DISABLE logical name:

Java program performance may be improved by defining the JAVA$READDIR_CASE_DISABLE logical name. This logical name allows the user to turn off the case-sensitive filename extraction feature, if it is not needed. In such cases, for ODS-2 filename formats the Java language compiler (javac) fails with the “cannot find symbol” error when referencing Java programs with mixedcase class names.

To set the receive or send buffer size using the socket.setReceiveBufferSize(int)or socket.setSendBufferSize(int) methods, processes must have one (or more) of SYSPRV, BYPASS, or OPER privileges. This restriction is imposed by TCP/IP services.

Without one of these process privileges, these Java methods behave as follows:

Alternatively, you can modify the default buffer size value in the system.

If the process does not have either of the SYSPRV, BYPASS, or OPER OpenVMS process privileges, invocation of the DatagramSocket setBroadcast(boolean) method fails.

The OpenJDK debugger (jdb) fails with “UTF ERROR” at startup if the VMSI18N kit for VSI OpenVMS is not installed.

The jdb utility uses the C RTL iconv family of functions to perform UTF-8 character conversions; however the database files required by the RTL for these conversions are not installed by default on all VSI OpenVMS operating system versions that support OpenJDK. To overcome this issue, you must ensure that the VMSI18N kit is installed on your system (note that VMSI18N is installed by default for OpenVMS 8.4-2 and higher).

OpenJDK will not operate properly after the DCL command SET PROCESS/CASE=SENSITIVE is executed.

OpenJDK will not operate correctly if either of the logical names DECC$FILENAME_UNIX_ONLY or DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION are defined. Running Java programs with these logical names defined is not supported. Other DECC$* logical names (or combinations of such logical names) may also result in incorrect operation of the Java virtual machine.

Upon encountering a fatal error, the JVM may try to create a log file containing potentially useful information regarding the crash. Unless specified otherwise (using the –XX:ErrorFile command line option) such log files will be created in the directory pointed to by the logical name SYS$SCRATCH (which is generally your login directory). However, it should be noted that the JVM will report that the file has been created in /tmp (the standard scratch area on UNIX and Linux systems). If tmp is not defined as a logical name, the OpenVMS C RTL will map /tmp to your SYS$SCRATCH directory. If tmp is defined, the log file may be found in the corresponding directory (assuming the directory exists). For example, the following definition would cause log files to be created in SYS$SYSDEVICE:[LOGS] (assuming the user has write permission for this directory):

$ define tmp SYS$SYSDEVICE:[LOGS] 

Splash screens may only work with small image files. For larger image files, the image may be only partially displayed.

This release of OpenJDK for VSI OpenVMS provides an option that can be used to limit the maximum length of XML names in XML documents processed by the Java API for XML processing (JAXP).

jdk.xml.maxXMLNameLimit=value

Defining the logical name JAVA$FILE_OPEN_MODE to "3" can cause problems with some Java applications and should not be used. Note that this logical name is deprecated and may be removed in future releases.

The logical name JAVA$XCOMP_SAFE_MODE has been added

In rare situations Java programs run with the –Xcomp option can crash with an ACCVIO error caused by a race condition between threads. The logical name JAVA$XCOMP_SAFE_MODE can be defined (to anything) to prevent this race condition from occurring, at the expense of a small performance penalty.