VSI OpenJDK Version X17.0-13C

Java Flight Recorder (JFR) support is enabled.

An issue with inadequate CPU consumption when waiting for user input has been fixed.

Several important TCP/IP socket bugs have been fixed.

A issue that was causing a hang when starting a child JVM has been fixed.

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 17 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 17 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 17 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$17.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 17 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-3

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$17.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$17.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$17.LIB])

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

C header files (SYS$COMMON:[OPENJDK$17.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$17.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.