Release Notes Java(tm) SE Development Kit (JDK) 8.0 for the OpenVMS Integrity servers Operating System for the Java(tm) Platform Contents * Introduction * JDK 8.0 New Features * Fixed Problems * Compatibility * Installation o Prerequisites o Installing the Kit o Contents of the JDK * Known Issues Introduction Thank you for downloading the Java(tm) SE Development Kit (JDK) 8.0 for the OpenVMS Integrity servers Operating System for the Java(tm) Platform (hereafter called the JDK). This release notes document contains installation instructions, new features, known issues, and other information specific to this release of the OpenVMS Integrity servers port of Oracle's Java(tm) Platform. This kit can be used to develop and run Java(tm) applets and 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. The JDK kit contains the HotSpot Virtual Machine that is designed for maximum program execution speed for applications running in a server environment. To set up up your Java environment, use the following command: $ @SYS$MANAGER:JAVA$80_SETUP.COM JDK 8.0 New Features Java(tm) 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 * The Nashorn Javascript engine * Removal of the permanent generation Fixed Problems This is a new product release; however platform-specific fixes implemented in for earlier versions have been incorporated into this new release where applicable. HPE recommends you that you review Oracle's Java(tm) Development Kit 8 Update Release Notes for detailed information about bug fixes that Oracle has made for each of the JDK 8 releases, seehttp://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html. Compatibility The 8.0 JDK is largely compatible with previous JDK versions and most existing Java(tm) 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(tm) versions for OpenVMS The following list identifies various differences between Java(tm) 6 for OpenVMS and Java(tm) 8 for OpenVMS that may impact the operation of some programs. * Exclusive use of 64-bit pointers For Java(tm) 6, the HotSpot Java(tm) 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(tm) class libraries used only 32-bit pointers. Java(tm) 8 for OpenVMS uses 64-bit pointers exclusively. As a consequence of this, any C or C++ application code using the Java(tm) 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 Somewhat related to the above, symbol vectors in sharable images shipped with Java(tm) 8 for OpenVMS will not necessarily match those of the equivalent Java(tm) 6 images. Any C or C++ application code using the Java(tm) 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(tm) 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(tm) for OpenVMS to help get around this issue such that any argument specified on the Java(tm) 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(tm), thereby avoiding issues with command line length. This facility was most commonly used to specify the Java(tm) 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(tm) 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(tm) 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(tm) 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(tm) 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(tm) 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(tm) Virtual Machine is such that building a debug version is not possible and consequently Java(tm) 8 for OpenVMS does not provide debug versions of executable programs and shareable images. * Case sensitivity of file names This release of Java(tm) 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(tm) 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(tm) 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(tm) 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(tm) 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(tm) 8 for OpenVMS. For Java(tm) 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(tm) 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(tm) 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(tm) on OpenVMS would attempt to create these files in the equivalent of the UNIX/Linux temporary 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 temporary. * HPE Secure Web Browser compatibility Java(tm) 8 for OpenVMS is not compatible with the HPE Secure Web Browser for OpenVMS. A compatible browser plug in may be provided at a later date. * Not compatible with Availability Manager Analyzer The Availability Manager Analyzer kit includes a compatible JRE (Java Runtime Environment). Availability Manager Analyzer will not work correctly with Java(tm) 8 and the use of the bundled JRE should not be overridden or bypassed in any way. An updated Availability Manager Analyzer that can be used with Java(tm) 8 will be made available in due course. * SCTP Support Java(tm) 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(tm) 8. The logical name JAVA$DAEMONIZE_MAIN_THREAD therefore serves no purpose and defining it will have no effect on JVM operation. Installation The following sections describe how to install the JDK 8.0 kit on your OpenVMS Integrity servers system. Prerequisites The prerequisites for running this kit are: * JDK 8 must be installed on an ODS-5 formatted disk. * OpenVMS Integrity servers V8.4. * The OpenVMS internationalization data kit (VMSI18N kit) must be installed in order for the Java(tm) 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. 1. 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. 2. Download the file HPE-I64VMS-JAVA80-V0800--1.PCSI_SFX_I64EXE (~807,400 blocks) from the Software Download web page and run the file to extract it into 2 files: $ RUN HP-I64VMS-JAVA60-V0106-6-1.PCSI_SFX_I64EXE HP-I64VMS-JAVA60-V0106-6-1.PCSI$COMPRESSED (~1,117,000 blocks) HP-I64VMS-JAVA60-V0106-6-1.PCSI$COMPRESSED_ESW (18 blocks) Important: If you move the above files, make sure that they remain together in the same directory, and ensure they are in UPPERCASE. 3. 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 Layered Product 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: JAVA for OpenVMS Itanium (c) Copyright 2017 Hewlett Packard Enterprise Company LP HPE * This product does not have any configuration options. Execution phase starting ... The following product will be installed to destination: HPE I64VMS JAVA80 V8.0 $2$DKB400:[VMS$COMMON.] Portion done: 0%...10%...60%...70%...80%...90%...100% The following product has been installed: HPE I64VMS JAVA80 V8.0 Layered Product HPE I64VMS JAVA80 V8.0: JAVA for OpenVMS Itanium Post-installation tasks are required. To use Java, users must execute the following command: $ @SYS$STARTUP:JAVA$80_SETUP.COM Post Installation Tasks Once the installation process has completed, you may wish to verify that the Java(tm) 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$80_setup.com $ java -XshowSettings:all VM settings: Max. Heap Size (Estimated): 782.50M 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 = 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 = 1.8.0.03-vms-rc1 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 = 1.8.0.03-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.51-b02 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 /disk$i64sys/sys0/syscommon/java$80/jre/lib/rt.jar /disk$i64sys/sys0/syscommon/java$80/jre/lib/sunrsasign.jar /disk$i64sys/sys0/syscommon/java$80/jre/lib/jsse.jar /disk$i64sys/sys0/syscommon/java$80/jre/lib/jce.jar /disk$i64sys/sys0/syscommon/java$80/jre/lib/charsets.jar /disk$i64sys/sys0/syscommon/java$80/jre/lib/jfr.jar /disk$i64sys/sys0/syscommon/java$80/jre/classes sun.boot.library.path = sun.cpu.endian = little sun.cpu.isalist = 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/biggles user.home = /sys$sysdevice/biggles user.language = user.language.format = en user.name = BIGGLES user.timezone = Locale settings: default locale = default display locale = 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. -cp -classpath A : separated list of directories, JAR archives, and ZIP archives to search for class files. -D= set a system property -verbose:[class|gc|jni] enable verbose output -version print product version and exit -version: require the specified version to run -showversion print product version and continue -jre-restrict-search | -no-jre-restrict-search include/exclude user private JREs in the version search -? -help print this help message -X print help on non-standard options -ea[:...|:] -enableassertions[:...|:] enable assertions with specified granularity -da[:...|:] -disableassertions[:...|:] disable assertions with specified granularity -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions -agentlib:[=] load native agent library , e.g. -agentlib:hprof see also, -agentlib:jdwp=help and -agentlib:hprof=help -agentpath:[=] load native agent library by full pathname -javaagent:[=] load Java programming language agent, see java.lang.instrument -splash: show splash screen with specified image For more details, see http://www.oracle.com/technetwork/java/javase/documentation/index.html. Assuming that the installation was successful and Java(tm) is functioning as expected, you can now use the JDK to compile and run your Java(tm)-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 In 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 Differencestable in the User Guide to understand fully the nuances and differences in JDK 8.0 on OpenVMS Integrity servers. Runtime Environment (JRE) In 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. (Note: The JRE included in the JDK is separate from the JRE kit). Additional Libraries In SYS$COMMON:[JAVA$80.LIB] Additional class libraries and support files required by the development tools. C header files In SYS$COMMON:[JAVA$80.INCLUDE]) Header files that support native-code programming using the Java(tm) Native Interface (JNI) and the JVM Tools Interface, as described on the Oracle site. Source Code In 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. To extract these files, use this command: $ jar xvf src.zip Do not modify core API source files. To extend the behavior of the core API, write subclasses of the core API classes. JNI example Code In SYS$COMMON:[JAVA$80.examples.ini] Simple example code that illustrate using the JNI to call C code from Java(tm) and to call Java(tm) (invoke a JVM instance) from C. Known Issues This section provides descriptions of the known issues and limitations that exist in JDK 8.0 for OpenVMS Integrity servers; these issues include the following: * Using JAVA$READDIR_CASE_DISABLE: Java(tm) 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(tm) compiler (javac) fails with the "cannot find symbol" error when referencing Java(tm) programs with mixed-case class names. * To set the receive or send buffer size using setReceiveBufferSize(int)or setSendBufferSize(int) method, process must contain either of the SYSPRV, BYPASS, or OPER OpenVMS process privileges; these restrictions are imposed by TCP/IP services. Without these privileges, these Java methods behave as follows: 1. If receive or send buffer size requested is greater than the default receive or send buffer size set on the system, these methods fail. 2. 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= $ sysconfig -r inet tcp_sendspace= $ sysconfig -r inet udp_recvspace= $ sysconfig -r inet udp_sendspace= * If process does not have either of the SYSPRV, BYPASS, or OPER OpenVMS process privileges, the invocation of setBroadcast(boolean) method fails. * The Java(tm) debugger (jdb) fails with "UTF ERROR" at start-up (similar problems may also be observed with other utilities). The Java(tm) 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(tm) 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(tm) 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(tm) with these logical names set is not supported. Other DECC$* logical names (or combinations of such logical names) may also result in incorrect Java(tm) operation. * The jinfo, jmap, jsadebugd, and jstack troubleshooting tools, introduced in JDK 5.0, are not supported on OpenVMS Integrity servers. * In very rare situations some Java(tm) applications can fail on start-up with the following message being displayed: "%SYSTEM-I-BREAK_APPL, application break instruction fault, break code=0000000000048005, ..." This problem is to be due to a thread synchronization issue involving the parallel just-in-time deferred compilation of two or more interdependent classes. Until such time as this issue is fully resolved, a workaround is to specify the option -XX:CompileThreshold=0 on the java command line. This option specifies the number of method invocations (method calls) that will be performed by the Java(tm) Virtual Machine (JVM) before just-in-time compilation occurs. The default value for server applications is 10000. By specifying a value of 0, compilation will begin to occur immediately as opposed to being deferred. It should be noted that specifying a value of 0 can impact program start-up times; however there will be no subsequent impact to run-time performance. * 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. Java(tm) 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 countries.