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 http://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html.
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
- Removal of the permanent generation
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 http://www.oracle.com/technetwork/java/javase/8u144-relnotes-3838694.html). 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- The sun.security.provider.Sun 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.
- 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.
- 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.
- 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.
- 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.
- 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 (http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html). For a more complete list of the bug fixes included in this release, see the JDK 8u144 Bug Fixes page (http://www.oracle.com/technetwork/java/javase/2col/8u144-bugfixes-3839149.html ).
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.
- 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 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
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
assuming a default installation) for setting the
JAVA$M_MULTI_DOT_KEEP_LAST to accommodate
particular file name mapping requirements.
- Changes to use of
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
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
java.awt.headless to false either via the
java command line ("-Djava.awt.headless=false")
As a specific example, if you use the Archive
Backup System (ABS) graphical user interface,
the start-up script
should be modified to include
on the Java command line, as follows:
$ java "-Xmx64M" "-Djava.awt.headless=false"
- 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
- 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> sysconfig "-c" "sctp"
- 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
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):
$ SHOW DEV $2$DKB400 /FULL
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):
$ RUN HPE-I64VMS-JAVA80-V0800-144A-1.PCSI_SFX_I64EXE
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:
$ PRODUCT INSTALL JAVA80/DEST=$2$DKB400:
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.
* 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).
$ java -XshowSettings:all
Max. Heap Size (Estimated): 2.55G
Ergonomics Machine Class: server
Using VM: Java HotSpot(TM) 64-Bit Server VM
awt.toolkit = sun.awt.X11.XToolkit
file.encoding = ISO8859-1
file.encoding.pkg = sun.io
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
java.io.tmpdir = /SYS$SCRATCH
java.library.path = /usr/lib
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 18.104.22.168-vms-b1
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 1.8
java.vendor = Hewlett-Packard Enterprise
java.vendor.url = https://www.hpe.com/global/java/alpha/
java.vendor.url.bug = https://www.hpe.com/global/java/alpha/
java.version = 22.214.171.124-OpenVMS
java.vm.info = mixed mode
java.vm.name = Java HotSpot(TM) 64-Bit Server VM
java.vm.specification.name = 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
os.name = OpenVMS
os.version = V8.4-1H1
path.separator = :
sun.arch.data.model = 64
sun.boot.class.path = /disk$i64sys/sys0/syscommon/java$80/jre/lib/resources.jar
sun.cpu.endian = little
sun.io.unicode.encoding = UnicodeLittle
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = ISO8859-1
sun.management.compiler = HotSpot 64-Bit Server Compiler
sun.os.patch.level = unknown
user.dir = /sys$sysdevice/cameron
user.home = /sys$sysdevice/cameron
user.language = en
user.name = CAMERON
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 http://www.oracle.com/technetwork/java/javase/documentation/index.html 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
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)
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
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
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
Simple example code that illustrate using the JNI to call C code from Java? and to call Java? (invoke a JVM instance) from C.
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.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:
Alternatively, you can modify the default buffer size value in the system:
- 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.
$ 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)
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.
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
- 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.