Release Notes

Java? Development Kit (JDK) 8
for the OpenVMS Integrity servers Operating System
Content starts here



Thank you for downloading the Java? Development Kit (JDK) 8 for the OpenVMS Integrity servers Operating System for the Java? Platform (hereafter called the JDK). This release notes document contains installation instructions, details of new features, known issues, and other information specific to this release of the OpenVMS Integrity servers port of Oracle's Java? Platform. This kit can be used to develop and run Java? programs on OpenVMS Integrity server systems, Version 8.4 and higher. This includes HPE OpenVMS version 8.4 for HPE Integrity server systems and OpenVMS version 8.4-1H1 and higher from VMS Software Inc.

This release of Java? for OpenVMS Integrity servers is based on the Oracle Java? 8u144 release and supersedes the previous 8u51 release.

The JDK contains the HotSpot Virtual Machine that is designed for maximum program execution speed for applications running in a server environment.

To set up your Java? environment, use the following command:


Please ensure that you understand the copyright (copyright.txt, installed file) and license (license.txt, installed file) information before using this release.

JDK 8.0 new features

Java? 8 is a major release that includes numerous new features and enhancements. For an overview of what is new in JDK 8, please see

Some of the more notable new language features and API?s include:

  • Lambda expressions

  • Method references

  •  Default Methods (defender methods)

  •  A new Stream API

  • Introduction of the Optional class (for avoiding null return values)

  • A new Date/Time API

  • The Nashorn Javascript engine

  • Removal of the permanent generation

Fixed Problems

It is recommended that you review Oracle's Java? Development Kit 8 Update Release Notes for detailed information about bug fixes that Oracle has made for each of the JDK 8 releases (see This release of Java? 8 for OpenVMS is based on the 8u144 release.

In addition to the fixed problems and updates included in the 8u144 release, following bug fixes for Java? 8 for OpenVMS are included in this update:

  1. InetAddress.getLocalHost().getHostName() method not returning fully qualified domain name (inconsistent with Java? 6 for OpenVMS)
    The return value of this method was not consistent with that of Java? 6. It is noted that the return value is somewhat dependent on how the TCP/IP has been configured and the result being returned by Java? 8 on OpenVMS was not necessarily incorrect; however for backwards compatibility the method should be consistent with Java? 6. This incompatibility is resolved by this update.
  2. File.listRoots() method returns null instead of a list of mounted disk devices
    The method was returning null regardless of there being mounted disks. This problem has been fixed and the method now correctly returns an array of device names as per Java? 6.
  3. JAVA$CACHING_INTERVAL not used by File.exists() and File.isDirectory() methods
    The logical name JAVA$CACHING_INTERVAL can be used to significantly improve the performance of Java I/O operations on OpenVMS that involve calls to the CRTL stat() function. The functionality that is enabled when this logical name is defined was not being correctly utilized by the Java methods in question. This has been fixed.
  4. An ?invalid argument? error is reported when the logical JAVA$FILENAME_MATCH_LIST is defined.
    The logical name JAVA$FILENAME_MATCH_LIST can be used to define specific RMS-related options to be used when opening specified file types. When the logical name is defined, the CRTL open() function is called using LIB$CALLG_64() in order to supply the open() call with the required variable length argument list that includes the relevant RMS options. Unlike Java? 6 for OpenVMS, Java? 8 for OpenVMS is built almost exclusively using 64-bit pointers and it is observed that the CRTL open() function does not accept 64-bit string pointers for the optional RMS-related arguments. The code has been updated to address the problem.
  5. In rare situations some Java applications have been observed to fail on start-up with the following message being displayed:

    ?%SYSTEM-I-BREAK_APPL, application break instruction fault, break code=0000000000048005, ??

    This is caused by a thread synchronization issue involving the parallel just-in-time deferred compilation of two or more interdependent classes. A workaround was suggested for this problem involving use of the -XX:CompileThreshold=0 option; however this has been observed to yield poor performance for some applications. This issue has been resolved.
  6. The security provider could trigger an ACCVIO when using PRNG (pseudo-random number generation) support in a multi-threaded scenario. It was determined that the underlying PRNG code in JAVA$PRNG_SHR.EXE was not thread-safe. This issue has been resolved.
  7. Incorrect caching of directory details. Java on OpenVMS implements a simple caching mechanism to improve the performance of various I/O-related operations. The successful operation of this caching requires its consistent application through the use of various jacket routines (as opposed to direct calls to the CRTL). The Java 1.8 port was not using the relevant jacket routine when creating directories, which could in some situations cause subsequent correctly jacketed calls to fail or return incorrect results. The code has been updated to address the problem.
  8. Incorrectly reporting file last modified times. Java on OpenVMS was incorrectly reporting file last modified times under certain circumstances. Specifically, incorrect last modified times were being reported when a list of files was constructed using the File.listFiles() method based on an OpenVMS-style directory specification. The result was that invalid file names were getting passed into the CRTL stat() function, causing the stat() function to return an error status whereupon Java sets the last modified time to 0. The code has been updated to address the problem.
  9. JAVA$PRNG_SHR.EXE unnecessarily depending on SSL$LIBCRYPTO_SHR.EXE. The shareable image JAVA$PRNG_SHR.EXE (for generation of pseudo-random numbers) was unnecessarily linked with SSL$LIBCRYPTO_SHR.EXE. This caused problems on OpenVMS systems that did not have SSL 1.4 for OpenVMS installed (JAVA$PRNG_SHR.EXE would not load). The dependency on SSL$LIBCRYPTO_SHR.EXE has been removed.
  10. JAVA$CANCEL_CURRENT incorrectly defined. The logical name JAVA$CANCEL_CURRENT was being incorrectly defined to point to the file JAVA$8U144_CANCEL_SETUP.COM, which does not exist. This has been fixed and JAVA$CANCEL_CURRENT now correctly points to the file JAVA$80_CANCEL_SETUP.COM.
  11. Missing codeset for Japanese OpenVMS. The codeset for Japanese OpenVMS was not included, causing issues when using the default locale for Japanese OpenVMS. This problem has been fixed and the codeset is now included in the kit.

This release also contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory ( For a more complete list of the bug fixes included in this release, see the JDK 8u144 Bug Fixes page ( ).


The 8.0 JDK is largely compatible with previous JDK versions and most existing Java? programs will run without change on the 8.0 platform. However, some incompatibilities do exist and these are discussed in Oracle's Compatibility Guide for JDK 8 document.

Compatibility with previous Java? versions for OpenVMS

The following list identifies various differences between Java? 6 for OpenVMS and Java? 8 for OpenVMS that may impact the operation of some programs.

  • Exclusive use of 64-bit pointers
    For Java? 6, 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. Java? 8 for 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 Java? 8 for OpenVMS will not necessarily match those of the equivalent Java? 6 images. Any C or C++ application code using the Java? Native Interface (JNI) that links with these shareable images will need to be relinked.
    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 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 be very long; however the facility was little used for any other purpose. In Java? 8 for OpenVMS the JVM 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 arguments has a leading ?$? or not. It should also be noted that Java? 8 supports the use of wildcards (?*?) in class path specifications. This feature can also often 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 Java? interprets and maps file names (between UNIX and OpenVMS formats). This logical name now default to a value of 8, as this value generally affords greatest flexibility and most predicable results.
    Be sure to define JAVA$FILENAME_CONTROLS appropriately for your environment, particularly if an ODS-2 filesystem is used for .jar and/or .class files. See examples in JAVA$FILENAME_CONTROLS.COM (found in SYS$COMMON:[JAVA$80.COM] assuming a default installation) for setting the variable JAVA$M_MULTI_DOT_KEEP_LAST to accommodate particular file name mapping requirements.
  • Changes to use of JAVA$FORK_PIPE_STYLE
    In Java? 6 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 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 the inter-process communication). This is still the case for Java? 8 on 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 Java? 8 for OpenVMS does not provide debug versions of executable programs and shareable images.
  • Case sensitivity of file names
    This release of Java? 8 for OpenVMS is more sensitive to the case of file names and in general 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 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
    Previous versions of Java? for 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 in Java? 8 for 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 Java? 8 for 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"
  • Logical name DECC$READDIR_DROPDOTNOTYPE defined in Java? 8 setup procedure
    This logical name controls how the OpenVMS C RTL treats file names with no extension (no file type). Without this logical name defined, 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 default C RTL behavior when scanning a directory to return a list of file names; this behavior is overridden by defining DECC$READDIR_DROPDOTNOTYPE.
  • Exit status
    Upon normal successful completion, java, javac, and all other executable utilities will consistently exit with a status of "%X00000001". This behavior differs from previous releases of Java? on OpenVMS.
  • Location of error logs
    In the event of a crash (an unrecoverable error condition), the JVM will attempt to create a log file containing potentially useful information about the crash. Previous versions of Java? on 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
    Java? 8 for 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 Analyzer
    The Availability Manager Analyser kit includes a compatible JRE (Java Runtime Environment). Availability Manager Analyser will not work correctly with Java? 8 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 Java? 8 will be made available in due course.
  • SCTP Support
    Java? 8 for OpenVMS supports SCTP (Stream Control Transmission Protocol). If you intent to use SCTP, be aware that it may be necessary to enable it. For HPE TCP/IP Services, SCTP is not enabled by default and must be explicitly enabled as follows:
    $ tcpip
    TCPIP> sysconfig "-c" "sctp"
    TCPIP> exit
  • JAVA$DAEMONIZE_MAIN_THREAD logical name deprecated
    In previous releases 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 Java? 8. The logical name JAVA$DAEMONIZE_MAIN_THREAD therefore serves no purpose and defining it will have no effect on JVM operation.


The following sections describe how to install the JDK 8.0 kit on your OpenVMS Integrity servers system.


The prerequisites for running this kit are:

  • Installation of the Java? 8u144 kit requires the new (February 2018) V1.2-1 binary checker to be installed in order for kit validation to be performed by PCSI. For HPE OpenVMS V8.4, the HP-I64VMS-HPBINARYCHECKER-V0102-1-1 kit should be installed prior to installing Java? 8u144, and for VMS Software Inc. OpenVMS V8.4-1H1 and higher the VSI-I64VMS-HPBINARYCHECKER-V0102-2-1 kit must be installed.

  • JDK 8 must be installed on an ODS-5 formatted disk.

  • OpenVMS Integrity servers V8.4 or higher

  • The OpenVMS internationalization data kit (VMSI18N kit) must be installed in order for the Java? debugger (jdb) and other utilities to operate correctly

  • TCP/IP Services for OpenVMS Integrity servers V5.7 or higher with latest ECO (note that testing and certification has been performed using TCP/IP Services for OpenVMS; however, because the JDK calls into and uses only the socket functions available from OpenVMS C RTL, MultiNet TCP/IP for OpenVMS should work with this JDK)

  • DECWindows Motif V1.5, if you intend to use the AWT

  • 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)

Installing the Kit

As noted previously, you must install the JDK on an ODS-5 enabled disk. Verify that the destination device is an ODS-5 volume by entering a command similar to the following (assuming $2$DKB400 is the disk where you want to install the JDK):

Disk $2$DKB400: (NODE11), device type COMPAQ BD018635C4, is online, mounted, file-oriented device, shareable, served to cluster via MSCP Server, error logging is enabled.

Volume Status: ODS-5, subject to mount verification, file high-water marking write-back caching enabled.

To install the JDK kit, download the file HPE-I64VMS-JAVA80-V0800-144A-1.PCSI_SFX_I64EXE from the Software Download web page and run the downloaded file to extract it into two files (be sure that the two files remain together in the same directory and that the file names are uppercase):

You should now have the following two files (note that a copy of the release notes is also included in the ZIPEXE file):


Install the kit by entering the following command, where $2$DKB400 is the name of the ODS-5 enabled disk where you want to install the JDK:


For a description of the features you can specify with the PRODUCT INSTALL command when starting an installation, see the POLYCENTER Software Installation Utility User's Guide

As the installation procedure progresses, the system displays the following information:

Performing product kit validation of signed kits ...

The following product has been selected:
    HPE I64VMS JAVA80 V8.0-144A             Layered Product [Installed]

Do you want to continue? [YES]

Configuration phase starting ...

You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.

Configuring HPE I64VMS JAVA80 V8.0-144A: JAVA for OpenVMS Itanium

 Copyright 2018 Hewlett-Packard Development Company, L.P.

    HP Enterprise

* This product does not have any configuration options.

Execution phase starting ...

The following product will be installed to destination:
    HPE I64VMS JAVA80 V8.0-144A             DISK$I64SYS:[VMS$COMMON.]

Portion done: 0%...10%...60%...70%...80%...90%...100%

The following product has been installed:
    HPE I64VMS JAVA80 V8.0-144A             Layered Product

HPE I64VMS JAVA80 V8.0-144A: JAVA for OpenVMS Itanium

    Post-installation tasks are required.

    To use Java, users must execute the following command:


Post Installation Tasks

Once the installation process has completed, you may wish to verify that the Java? has installed correctly by running the following commands and verifying that the output is similar to that shown below (there may be some differences in the output, depending on operating system version, installation destination, available memory, locale settings, and so on).

$ @sys$startup:java$
$ java -XshowSettings:all
VM settings:
    Max. Heap Size (Estimated): 2.55G
    Ergonomics Machine Class: server
    Using VM: Java HotSpot(TM) 64-Bit Server VM

Property settings:
    awt.toolkit = sun.awt.X11.XToolkit
    file.encoding = ISO8859-1
    file.encoding.pkg =
    file.separator = /
    java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
    java.awt.headless = true
    java.awt.printerjob = sun.print.PSPrinterJob
    java.class.path = .
    java.class.version = 52.0
    java.endorsed.dirs = /disk$i64sys/sys0/syscommon/java$80/jre/lib/endorsed
    java.ext.dirs = /disk$i64sys/sys0/syscommon/java$80/jre/lib/ext
    java.home = /disk$i64sys/sys0/syscommon/java$80/jre = /SYS$SCRATCH
    java.library.path = /usr/lib = Java(TM) SE Runtime Environment
    java.runtime.version = = Java Platform API Specification
    java.specification.vendor = Oracle Corporation
    java.specification.version = 1.8
    java.vendor = Hewlett-Packard Enterprise
    java.vendor.url =
    java.vendor.url.bug =
    java.version = = mixed mode = Java HotSpot(TM) 64-Bit Server VM = Java Virtual Machine Specification
    java.vm.specification.vendor = Oracle Corporation
    java.vm.specification.version = 1.8
    java.vm.vendor = Hewlett-Packard Enterprise
    java.vm.version = 25.11-b1
    line.separator = \n
    os.arch = ia64 = OpenVMS
    os.version = V8.4-1H1
    path.separator = : = 64
    sun.boot.class.path = /disk$i64sys/sys0/syscommon/java$80/jre/lib/resources.jar
    sun.boot.library.path =
    sun.cpu.endian = little
    sun.cpu.isalist = = UnicodeLittle = SUN_STANDARD
    sun.jnu.encoding = ISO8859-1 = HotSpot 64-Bit Server Compiler
    sun.os.patch.level = unknown
    user.dir = /sys$sysdevice/cameron
    user.home = /sys$sysdevice/cameron
    user.language = en = CAMERON
    user.timezone =

Locale settings:
    default locale = English
    default display locale = English
    default format locale = English
    available locales = , ar, ar_AE, ar_BH, ar_DZ, ar_EG, ar_IQ, ar_JO,
        ar_KW, ar_LB, ar_LY, ar_MA, ar_OM, ar_QA, ar_SA, ar_SD,
        ar_SY, ar_TN, ar_YE, be, be_BY, bg, bg_BG, ca,
        ca_ES, cs, cs_CZ, da, da_DK, de, de_AT, de_CH,
        de_DE, de_GR, de_LU, el, el_CY, el_GR, en, en_AU,
        en_CA, en_GB, en_IE, en_IN, en_MT, en_NZ, en_PH, en_SG,
        en_US, en_ZA, es, es_AR, es_BO, es_CL, es_CO, es_CR,
        es_CU, es_DO, es_EC, es_ES, es_GT, es_HN, es_MX, es_NI,
        es_PA, es_PE, es_PR, es_PY, es_SV, es_US, es_UY, es_VE,
        et, et_EE, fi, fi_FI, fr, fr_BE, fr_CA, fr_CH,
        fr_FR, fr_LU, ga, ga_IE, hi, hi_IN, hr, hr_HR,
        hu, hu_HU, in, in_ID, is, is_IS, it, it_CH,
        it_IT, iw, iw_IL, ja, ja_JP, ja_JP_JP_#u-ca-japanese, ko, ko_KR,
        lt, lt_LT, lv, lv_LV, mk, mk_MK, ms, ms_MY,
        mt, mt_MT, nl, nl_BE, nl_NL, no, no_NO, no_NO_NY,
        pl, pl_PL, pt, pt_BR, pt_PT, ro, ro_RO, ru,
        ru_RU, sk, sk_SK, sl, sl_SI, sq, sq_AL, sr,
        sr_BA, sr_BA_#Latn, sr_CS, sr_ME, sr_ME_#Latn, sr_RS, sr_RS_#Latn, sr__#Latn,
        sv, sv_SE, th, th_TH, th_TH_TH_#u-nu-thai, tr, tr_TR, uk,
        uk_UA, vi, vi_VN, zh, zh_CN, zh_HK, zh_SG, zh_TW

Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)
where options include:
    -d32          use a 32-bit data model if available
    -d64          use a 64-bit data model if available
    -server       to select the "server" VM
    -client       is a synonym for the "server" VM  [deprecated]
    -hotspot      is a synonym for the "server" VM  [deprecated]
                  The default VM is server,
                  because you are running on a server-class machine.

                  A : separated list of directories, JAR archives,
                  and ZIP archives to search for class files.
                  set a system property
                  enable verbose output
    -version      print product version and exit
                  Warning: this feature is deprecated and will be removed
                  in a future release.
                  require the specified version to run
    -showversion  print product version and continue
    -jre-restrict-search | -no-jre-restrict-search
                  Warning: this feature is deprecated and will be removed
                  in a future release.
                  include/exclude user private JREs in the version search
    -? -help      print this help message
    -X            print help on non-standard options
                  enable assertions with specified granularity
                  disable assertions with specified granularity
    -esa | -enablesystemassertions
                  enable system assertions
    -dsa | -disablesystemassertions
                  disable system assertions
                  load native agent library , e.g. -agentlib:hprof
                  see also, -agentlib:jdwp=help and -agentlib:hprof=help
                  load native agent library by full pathname
                  load Java programming language agent, see java.lang.instrument
                  show splash screen with specified image
See for more details..

Assuming that the installation was successful and Java? is functioning as expected, you can now use the JDK to compile and run your Java?-based applications.

Contents of the JDK

This section provides a general summary of the files and directories contained in the JDK once it has been installed on your system.

Note: For simplicity, these release notes assume you installed the JDK using the default location and therefore reference SYS$COMMON:[JAVA$80] throughout the text. However, if you specified a destination and installed the kit in that alternate location, substitute that location for the default while reading the examples in this document.

  • Development Tools SYS$COMMON:[JAVA$80.BIN]

    This area contains programs that will help you develop, execute, debug, and document programs written in the Java? programming language. For further information, see Oracle's JDK Tools and Utilities page.

    Important: Review the information in the Interpreting Commands and OpenVMS Operating System Differences table in the User Guide to understand fully the nuances and differences in JDK 8.0 on OpenVMS Integrity servers.

  • Runtime Environment (JRE) SYS$COMMON:[JAVA$80.JRE]

    An implementation of the Runtime Environment (JRE) for use by the JDK. 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:[JAVA$80.LIB]
    Additional class libraries and support files required by the development tools.

  • C header files SYS$COMMON:[JAVA$80.INCLUDE])
    Header files that support native-code programming using the Java? Native Interface (JNI) and the JVM Tools Interface, as described on the Oracle site.

  • Source code (SYS$COMMON:[JAVA$80]SRC.ZIP)
    Java? programming language source files for all classes that make up the Java? core API (that is, source files for the java.*, javax.* and org.omg.* packages, but not for com.sun.* packages). This source code is provided for informational purposes only, to help developers learn and use the Java? programming language. These files do not include platform-specific implementation code and cannot be used to rebuild the class libraries.

  • JNI example code (SYS$COMMON:[JAVA$80.examples.jni])
    Simple example code that illustrate using the JNI to call C code from Java? and to call Java? (invoke a JVM instance) from C.

Known Issues

This section provides descriptions of the known issues and limitations that exist in JDK 8 for OpenVMS Integrity servers. These issues are listed below:

  • Use of the JAVA$READDIR_CASE_DISABLE logical name:

    Java? program performance can 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, (ODS-2 ?auto case? correction for ?readdir? entries) if it is not needed. In such cases, for ODS-2 filename formats, the Java? compiler (javac) fails with the ?cannot find symbol? error when referencing Java? programs with mixed-case 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 these privileges, these Java methods behave as follows:

    • If the receive or send buffer size requested is greater than the default receive or send buffer size set on the system, the methods will fail.
    • If receive or send buffer size requested is less than or equal to the default receive or send buffer size set on the system, the system returns the default receive or send buffer size.

    Alternatively, you can modify the default buffer size value in the system:
    $ sysconfig -r inet tcp_revspace=<default_tcp_receive_buffer_size>
    $ sysconfig -r inet tcp_sendspace=<default_tcp_send_buffer_size>
    $ sysconfig -r inet udp_recvspace=<default_udp_receive_buffer_size>
    $ sysconfig -r inet udp_sendspace=<default_udp_receive_buffer_size>

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

  • The Java? debugger (jdb) fails with ?UTF ERROR? at start-up (similar problems may also be observed with other utilities)

    The Java? jdb utility uses the C RTL iconv family of functions to perform UTF-8 character conversions. The database files required by the RTL for these conversions are not installed by default on all operating system versions that support the Java? 8 JDK. To overcome this issue, you must ensure that the VMSI18N kit is installed on your system. This kit is provided on the OpenVMS media set as OpenVMS kit. It is installed by default for OpenVMS 8.4-2 and higher.

  • Java? will not run properly after the DCL command set process/case=sensitive is executed.

  • Java? will not run correctly if either of the logical names DECC$FILENAME_UNIX_ONLY or DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION are defined. Running Java? with these logical names set is not supported. Other DECC$* logical names (or combinations of such logical names) may also result in incorrect Java? operation.

  • The jhat, jinfo, jmap, jps, jrunscript, jsadebugd, jstack, jstat, and jstatd troubleshooting tools and utilities are considered by Oracle to be experimental, and not supported on OpenVMS Integrity servers.

  • 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 Java? 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). The maximum length can be changed by using the -Djdk.xml.maxXMLNameLimit=value option, where value is a positive integer. A value of 0 or a negative number sets no limits (0 is the default). It is also possible to set this limit by adding the following line to your file:

  • 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.
Java™ and all Java based trademarks and logos are trademarks or registered trademarks of Oracle America and/or its affiliates in the United States and other>