Note: Based on information made available from Sun Microsystems, J2SE 1.4.2 has reached the end of its service life. Support will continue to be provided through your normal HP Services channels. We do not expect any future general release updates for J2SE 1.4.2. HP recommends that you consider moving to J2SE 5.0, which is available for OpenVMS Alpha.
Contents
Introduction
Thank you for downloading the Software Development Kit (SDK) v
1.4.2-9 for the OpenVMS Alpha Operating System for the Java™
Platform (hereafter called simply the SDK). These release notes
contain installation instructions, new
features, known issues, fixed problems, and other information specific to this
release of the OpenVMS Alpha port of Sun Microsystems' Java 2 SDK,
Standard Edition (J2SDK). In addition to these release notes, the
release-independent User Guide contains
information on getting started using the SDK, using the Fast VM,
using the Plug-in, and troubleshooting. The JDK 1.4.2-9 kit is supported
on OpenVMS Alpha Version 8.2 or higher. Because this version was built
against the OpenVMS Alpha V7.3-2 libraries, it will continue to install
and execute on V7.3-2. However, support on that version is available only for
customers that have a Prior Version Support (PVS) contract for OpenVMS Alpha V7.3-2.
The SDK v 1.4.2-9 kit implements the J2SDK v 1.4.2, and is based
on Sun's J2SDK 1.4.2_19 Solaris Reference Release and Olson timezone
data files tzdata2008i.
It passes all the tests in Sun's Java Compatibility Kit test suite
(JCK V1.4a). Use the
java -version command to check
the version of the SDK that you are using.
This kit contains two virtual machines:
- The classic virtual machine (classic VM, the virtual
machine shipped with prior releases) is based on Sun's reference
implementation. The classic VM contains Just-In-Time (JIT) compiler
technology, but does not have the performance of the Fast Virtual
Machine (Fast VM). However, it provides additional debugging support
not currently available in the Fast VM.
- The Fast Virtual Machine is Just-In-Time (JIT)
compiler technology designed to provide optimal Java runtime performance
on OpenVMS Alpha systems. The Fast VM offers significant performance
advantages over the Classic JIT. Because the Fast VM is included
in this kit, it is not provided as a separate kit. To learn more
about the Fast VM, refer to Using
the Fast VM in the User Guide.
You select which virtual machine (hereafter called VM) to use when
you set up your Java environment. To set up your environment, use
one of the following two commands, as described in Setting
Up the Java Environment in the User Guide:
$ @SYS$COMMON:[JAVA$142.COM]JAVA$142_SETUP FAST ! Use
the Fast VM
$ @SYS$COMMON:[JAVA$142.COM]JAVA$142_SETUP !
Use the classic VM
Note: For simplicity, these release notes assume
you installed the SDK using the default location and therefore reference
SYS$COMMON:[JAVA$142] 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.
IMPORTANT: Please make sure you understand the
Copyright (copyright.html,
installed file) and License (license.html,
installed file) information before using this release.
New
Features
The following sections briefly describe the new features HP has
included in SDK v 1.4.2. HP recommends that you read Sun's Java
2 SDK, Standard Edition, Enhancements and Changes in J2SE™
1.4.2 Platform for a thorough description of all new features
and enhancements available in the J2SDK v 1.4.2.
SDK v 1.4.2-9 New Features
This kit installs SDK v 1.4.2-9, which is a maintenance release with no new features from HP.
SDK v 1.4.2-8 New Features
SDK v 1.4.2-8 was a maintenance release with no new features from HP.
SDK v 1.4.2-7 New Features
SDK v 1.4.2-7 was a maintenance release with no new features from HP.
SDK v 1.4.2-6 New Features
SDK v 1.4.2-6 was a maintenance release with the following new feature from HP:
- Support for user controllable RMS attributes. You can now override the default RMS file operation attributes with attributes of your own choosing. For more information, see Defining RMS Record Attributes.
SDK
v 1.4.2-5 New Features
SDK v 1.4.2-5 was a maintenance release
with no new features from HP.
SDK
v 1.4.2-4 New Features
SDK v 1.4.2-4 was a maintenance release with no new features from
HP.
SDK
v 1.4.2-3 New Features
SDK v 1.4.2-3 was a maintenance release with the following new
feature from HP.
New Fast VM Option:
- The option,
-Xcode<size>, which allows a
larger code region for code generated by the Fast VM, has been
added in this release. Size is the code region maximum allocation
size in bytes. Append the letter k or K to indicate kilobytes,
or m or M to indicate megabytes. You can specify values between
24M and 128M. The default value is -Xcode24M.
SDK
v 1.4.2-2 New Features
SDK v 1.4.2-2 was a maintenance release with the following new
features from HP.
New logical for JAVA$142_SETUP (JAVA$CANCEL_CURRENT)
Beginning with the SDK v 1.4.2-2 release, the setup procedure JAVA$142_SETUP
now defines an additional logical name:
-
JAVA$CANCEL_CURRENT - The value
of this logical is the full file specification of the command
procedure for canceling the setup for the most recent version
of Java set up. For example, if you have most recently done
$ @SYS$COMMON:[JAVA$142.COM]JAVA$142_SETUP.COM then
the value of
JAVA$CANCEL_CURRENT will be SYS$COMMON:[JAVA$142.COM]JAVA$142_CANCEL_SETUP.COM.
This logical allows you to freely type the command, $ @JAVA$CANCEL_CURRENT,
to undefine current Java logicals and symbols without knowing
what the currently-enabled version is.
For more information, see the 'In
the Same Process' section of Switching
Versions in the User Guide.
New Logical for Forcing Stream_LF File Format (JAVA$CREATE_STMLF_FORMAT)
On OpenVMS, when you create a new version of an existing file,
the new file will inherit the record format of the existing file.
The record format preferred/required by the RTE is Stream_LF.
The RTE now allows you to specify a new logical:
$ DEFINE JAVA$CREATE_STMLF_FORMAT TRUE
With this logical defined, the RTE will force any newly-created
file to have a Stream_LF format. This allows the RTE
to override the C Run-Time Library's default of inheriting existing
file format from previous versions, which might not behave correctly
with the RTE.
For more information on Stream_LF, see Stream_LF
File Format Required in the User Guide.
SDK v
1.4.2-1 New Features
SDK v 1.4.2-1 was a maintenance release with the following new
feature from HP.
-Xdynclassgc
When using the Fast VM, the java command now supports
the -Xdynclassgc option. This option instructs the
Fast VM to garbage collect the class data for dynamically generated
classes when those classes are no longer used. By default, the Fast
VM garbage collects only heap objects, not class data structures.
For more information, refer to Garbage
Collection of Class Data for Dynamically Generated Classes in
the User Guide.
Fixed Problems
The following sections provide important information about problems
that HP has fixed in SDK v 1.4.2. HP recommends that you also review
Sun's Java
2 SDK and Runtime Environment Important Bug Fixes and Changes
documentation for information concerning bug fixes that Sun has
made for this release.
Problems Fixed in SDK v 1.4.2-9
SDK v 1.4.2-9 is based on Sun Microsystems' J2SDK 1.4.2_19 Solaris
Reference Release and Olson timezone data files tzdata2008i, and
passes all the tests in Sun's Java Compatibility
Kit test suite (JCK V1.4a). For additional information on the DST changes, please refer to the Java Technology Software (OpenVMS and Tru64™ UNIX®) website. This SDK is a maintenance release and includes the following fixed problems from HP:
- A previous performance problem regarding alignment access fault is fixed.
- The return value of Runtime.getRuntime().maxMemory() was not correct with the ClassicVM and FastVM when the paging file quota was greater than 4194304. This problem is fixed.
- Calling Thread.start with a thread object in a method would not start the thread until the method finished, if it was synchronized with the thread object with the FastVM. This problem is fixed.
- The FastVM might have crashed when running a special jar file that called a static method with the invokevirtual instruction. This problem is fixed.
- Incorrect pathname and filename information might have been appended to the name while attempting to rename files. This problem is fixed.
- There might have been some references that were never garbage-collected with the FastVM. This problem is fixed.
Problems Fixed in SDK v 1.4.2-8
SDK v 1.4.2-8 was based on Sun Microsystems' J2SDK 1.4.2_18 Solaris
Reference Release and Olson timezone data files tzdata2008c, and
passes all the tests in Sun's Java Compatibility
Kit test suite (JCK V1.4a). For additional information on the DST changes, please refer to the Java Technology Software (OpenVMS and Tru64™ UNIX®) website. This SDK is a maintenance release and includes the following fixed problems from HP:
- In previous releases, the FastVM did not recognize multiple –Xbootclasspath/p options. This is now supported in this kit.
- A problem with attaching to a thread has been fixed. Previously, users might have experienced a JNI version error when attaching to a thread.
- Previously, the function TimeZone::getID returned the identifier of the time zone entirely capitalized. This problem has been fixed.
- A problem with the JAVA$142_SETUP.COM procedure has been fixed. Previously, users might have experienced a problem when selecting Fast VM on Itanium, or Hotspot VM on Alpha. The JAVA$142_SETUP.COM command procedure has been extended so that the FAST and HOTSPOT options are synonymous on both platforms. Specifying either one uses the Fast VM on Alpha, or the Hotspot VM on Itanium.
Problems Fixed in SDK v 1.4.2-7
SDK v 1.4.2-7 was based on Sun Microsystems' J2SDK 1.4.2_16 Solaris
Reference Release and Olson timezone data files tzdata2007f, and
passes all the tests in Sun's Java Compatibility
Kit test suite (JCK V1.4a). For additional information on the DST changes, please refer to the Java Technology Software (OpenVMS and Tru64™ UNIX®) website.
This SDK is a maintenance release and
includes the following fixed problems from HP:
- In previous releases, a race condition existed between unloading classes and garbage collection. For some special cases, this race condition caused the Fast VM to dump a core file. This problem is fixed in this release.
- This release includes an enhancement to garbage collection. Previously, under certain uncommon circumstances, the Fast VM garbage collector was unable to allocate a Java object, even though there was sufficient memory. This problem has been addressed in this release.
- A problem with Weak Global References has been fixed. Previously, accessing Weak Global References to objects that had already been garbage collected could result in application failures.
- Previously, a deadlock resulted if a Fast VM garbage collection was taking place during the call of Thread.getAllStackTraces(). This deadlock problem is fixed in this release.
- A problem in the command procedure that is used to set up the Java environment has been fixed. Previously, when specifying the HOTSPOT parameter, the SYS$COMMON:[JAVA$142.COM]JAVA$142_SETUP.COM command procedure would incorrectly define the virtual machine logical names to point to a non-existent virtual machine. The HOTSPOT parameter is now accepted and will set up the Fast Virtual machine. If no parameter or an invalid parameter is specified, the Classic VM will be used.
Problems Fixed in SDK v 1.4.2-6
SDK v 1.4.2-6 was based on Sun Microsystems' J2SDK 1.4.2_13 Solaris Reference Release. It includes the following fixed problems from HP:
- The 2006/2007 daylight saving time rule changes supplied by Sun for the United States, Canada, and Australia (Melbourne and Perth) are fixed in this release. For additional information on the DST changes, please refer to the Java Technology Software (OpenVMS and Tru64™ UNIX®) website.
- Previously, a simple
Java -version crashed with an
Access Violation (ACCVIO) if the logical decc$filename_unix_report
was defined.
This has been corrected.
- Previously, if you had the
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION logical name enabled, then calling the C Run-Time Library function stat()would not resolve logicals correctly when the first logical uses another logical for the device name. This problem has been corrected.
Problems Fixed in SDK v
1.4.2-5
SDK v 1.4.2-5 was based on Sun Microsystems' J2SDK 1.4.2_11 Solaris
Reference Release (which contains fixes to problems with daylight-saving
time in parts of Australia). This SDK is a maintenance release and
contains all the fixes from previous SDK 1.4.2-4 patch kits from
HP. These fixes include:
-Xdynclassgc (stack corruption)
Previous versions of the Fast VM incorrectly computed a branch
offset under rare conditions if the memory had previously been
used by a recently freed class. This could result in a stack corruption.
This issue has been corrected.
- Global memory exhaustion (Out of Memory)
The Fast VM sometimes allocates memory in the global memory region
during garbage collection, but previous versions did not reuse
this memory during subsequent garbage collections. This has been
corrected so that such memory is reused.
- Delete or renaming of a file created a memory leak
When deleting or renaming a file on OpenVMS, memory was allocated
for temporary use but was never freed. This memory leak has been
fixed.
String.intern() (Out of Memory)
Previous versions allocated memory for String.intern()
from the global memory region, and this memory was not garbage
collected. Starting with this kit, String.intern()
results are now allocated as a String object subject to normal
garbage collection.
- Reference Object processing
If a "finalize" method is provided for a PhantomReference
object, the reference object and its referent might not be garbage
collected, and the finalizer would never be run. This problem
has been corrected.
- Miscellaneous small memory leaks
Previous versions had several small memory leaks, which were found
while testing early versions of this kit on long running Java
applications. These problems have been fixed.
-Xdynclassgc (ACCVIO)
Previous versions of the Fast VM incorrectly unloaded interface
classes in some cases when using the -Xdynclassgc
option. This could result in an ACCVIO at random times. This issue
has been fixed.
Problems Fixed in SDK v
1.4.2-4
SDK v 1.4.2-4 was based on Sun Microsystems' J2SDK 1.4.2_05 Solaris
Reference Release and passes all the tests in Sun's Java Compatibility
Kit test suite (JCK V1.4a). This SDK is a maintenance
release and contains the following fixed problem from HP.
- A situation where memory in the Fast VM could become corrupted
and eventually lead to an Access Violation within the garbage
collector, has been corrected.
Problems Fixed in SDK v
1.4.2-3
SDK v 1.4.2-3 was based on Sun Microsystems' J2SDK 1.4.2_05 Solaris
Reference Release and passes all the tests in Sun's Java Compatibility
Kit test suite (JCK V1.4a). This SDK is a maintenance
release and contains the following fixed problems from HP.
- With the logical
DECC$ENABLE_GETENV_CACHE defined,
the virtual machine could calculate the incorrect value for the
local timezone if the logical TZ was not defined. This has been
corrected.
- When running SDK 1.4.x on Multicpu systems, the Classic VM would
randomly crash with an ACCVIO or OPCCUS ("opcode reserved
to customer fault"). Nearly 90% of the crashes occurred while
the virtual machine was in the middle of a garbage collection.
This problem has been corrected in this release.
- Previously, Printing Services attempted to execute a hard-coded
UNIX-style print command. The SDK v 1.4.2-3 release introduces
some new logicals and commmand procedures that cause mapping of
UNIX-style print commands into their OpenVMS counterparts. For
more details, see Using
the Java Print Service API in the User Guide.
Problems Fixed in SDK v
1.4.2-2
SDK v 1.4.2-2 was based on Sun Microsystems' J2SDK 1.4.2_04 Solaris
Reference Release and passed all the tests in Sun's Java Compatibility
Kit test suite (JCK V1.4a). SDK v 1.4.2-2 was
a maintenance release and contained the following fixed problems
from HP:
- This release contains fixes to correct memory leaks in long-running
applications that use DECwindows.
- Previously, calling the
accept()method in the class
java.nio.channels.SelectionKey would incorrectly
throw a java.io.IOException:function not implemented.
This has been corrected.
- Previously, you were required to have the DECwindows Motif libraries
installed even though you were using Java's AWT headless support
feature. This restriction has been lifted. You no longer need
the Motif libraries installed to use this feature.
- In previous versions, the capability to use the
JAVA$ENABLE_SIGQUIT_MAILBOX
logical was lost when updating from SDK v 1.4.1 to SDK v 1.4.2.
This capability has been restored.
- The plugin was not properly initializing
JAVA$DIRECTORY_MAPPING_COUNT
environment variable. This has been corrected.
- Java Networking IPv6 support is now included in this SDK release.
See Prerequisites section for details
on required TCP/IP ECOs.
Problems Fixed in SDK v 1.4.2-1
SDK v 1.4.2-1 was based on Sun Microsystems' J2SDK 1.4.2_03 Solaris
Reference Release and passed all the tests in Sun's Java Compatibility
Kit test suite (JCK V1.4a). SDK v 1.4.2-1 was a
maintenance release and contained the following fixed problems from
HP.
- Under some circumstances when using
JAVA$FORK_PIPE_STYLE=2,
it was possible for the application to fail with a java.io.IOException:
bad file number error. This has been corrected.
- Some
out of memory and virtual address space
is full errors, which previously occurred when using the
Fast VM, have been fixed in this release.
- When using the classic VM and running on a system with low physical
memory, if you attempted to start several virtual machines at
once, some of the virtual machines would fail with an
out
of memory error. This problem has been fixed.
- Previously, the classic VM incorrectly handled SIGTERM signals
from another process. As a result, the virtual machine would hang
instead of exiting properly. This has been corrected.
- Previously, when using the Fast VM, if an object in the Java
heap spanned more than a page of memory, and the compacting garbage
collector performed a sweep operation, in rare cases an access
violation could occur on the subsequent collection. This has been
corrected.
- In previous versions, when running the Fast VM on an eight or
more processors system, the garbage collector could fail with
a
GC: failure in slave threads,... message. This
problem has been fixed in this release.
- Previously, calling the
Select() method in the
class java.nio.channels.Selector would incorrectly
throw a java.io.IOException: socket operation on non-socket
exception. This has been corrected.
Compatibility
SDK v 1.4.2 is compatible with previous versions of the SDK. Most
existing programs will run on the SDK v 1.4.2 platform. However,
some important incompatibilities do exist and are thoroughly discussed
in Sun's Java
2 Platform Compatibility with Previous Releases document. For
specific J2SDK v 1.4.2 incompatibilities refer to the section, Incompatibilities
in the Java 2 Platform, Standard Edition, v1.4.2 (since 1.4.1).
Installation
The following sections describe how to install the SDK v 1.4.2
kit on your OpenVMS Alpha system.
Prerequisites
The prerequisites for running this kit are:
- OpenVMS Alpha V8.2 or higher. See Mandatory
Patches.
- HP TCP/IP Services for OpenVMS Alpha V5.5 or higher (and required
patches).
Note: We do not support MultiNet directly. All
of our testing and certification is done using TCP/IP Services
for OpenVMS; however, because we do not call UCX directly and
use only the socket functions available from HP C, MultiNet may
work with this SDK.
- DECWindows Motif V1.2-6, if you plan on AWT use.
- Kernel support for Thread Manager upcalls must be enabled. Please do not disable Thread Manager upcalls using either the image flags or the MULTITHREAD system parameter.
Mandatory Patches
To successfully install and run the SDK for OpenVMS Alpha, you
must install prerequisite patches for your OpenVMS version (See
the list below. Install the patch versions listed, or later, if
superseded.). These patches can be downloaded from the IT Resource
Center (ITRC) at http://www2.itrc.hp.com/.
Note: First-time users must register.
Patches for OpenVMS Alpha V8.3
- All Rating 1 ECOs (search keyword = 'INSTALL_1' )
- TCPIP-V0506 (TCP/IP V5.6 or latest ECO)
Patches for OpenVMS Alpha V8.2
- All Rating 1 ECOs for V8.2
- TCPIP-V0506-9ECO3-1 (TCP/IP V5.6 or latest ECO)
For more information, refer to the patch
installation page on the Web site.
Installing the Kit
To install the SDK kit:
- Download and install the prerequisite ECOs.
- Download the file
DEC-AXPVMS-JAVA142-V0104-29-1.PCSI_SFX_AXPEXE
(~162,000 blocks) from our Software
Download web page and execute it to unpack it and obtain the
original kit files:
DEC-AXPVMS-JAVA142-V0104-29-1.PCSI$COMPRESSED (~203,000 blocks)
DEC-AXPVMS-JAVA142-V0104-29-1.PCSI$COMPRESSED_ESW (~18 blocks)
$ RUN DEC-AXPVMS-JAVA142-V0104-29-1.PCSI_SFX_AXPEXE
Note: If you are unpacking the file to an
ODS-5 disk, the unpacking operation might convert the filename
into lower case. Convert them to upper case before proceeding;
for example:
$ RENAME dec-axpvms-java142-v0104-29-1.pcsi$compressed -
DEC-AXPVMS-JAVA142-V0104-29-1.PCSI$COMPRESSED
$ RENAME dec-axpvms-java142-v0104-29-1.pcsi$compressed_esw
-
DEC-AXPVMS-JAVA142-V0104-29-1.PCSI$COMPRESSED_ESW
Note: if you copy one of these files to another
directory, you must copy the other as well. They must both reside
in the same directory.
- To extract a local copy of these Release Notes before installing
the SDK:
$ PRODUCT EXTRACT FILE JAVA142 -
/SOURCE=[directory_where_you_put_the_PCSI_file] -
/SELECT=RELEASE_NOTES.HTML -
/DEST=[]
- Install the SDK kit from the
.PCSI file obtained,
using the PCSI (POLYCENTER Software Installation) utility PRODUCT
command:
$ PRODUCT INSTALL/NORECOVERY_MODE JAVA142 -
/SOURCE=[directory_where_you_put_the_PCSI_file]
By default, the SDK gets installed in root directory SYS$COMMON:[JAVA$142].
As an alternative to installing the kit in the default location
SYS$COMMON:[JAVA$142], you can specify /DESTINATION=device-name:[directory-name]on
the PRODUCT command line, and the kit will be installed
at that specified location.
Also, the following files are installed by the PCSI utility
with a file attribute of ARCHIVE:
SYS$COMMON:[JAVA$142.COM]JAVA$142_SETUP.COM
SYS$COMMON:[JAVA$142.JRE.LIB]FONT.PROPERTIES
SYS$COMMON:[JAVA$142.JRE.LIB]FONT_PROPERTIES.JA
If a file having any of these names already exists on the system,
the installation process renames it to a new name with a file
type ending in _OLD, before loading the new copy
from the kit. Only the latest version of the existing file is
preserved (by being renamed to file.type_old) before
PCSI deletes all remaining versions.
For example, an existing SYS$COMMON:[JAVA$142.COM]JAVA$142_SETUP.COM
is renamed to SYS$COMMON:[JAVA$142.COM]JAVA$142_SETUP.COM_OLD
before the new copy is copied from the kit.
If you have previously personalized any of these files, you
might need to merge your personalizations with the new copies.
Notes:
- The PCSI PRODUCT tool for OpenVMS Alpha installs different
versions of the SDK using unique product names. For example:
- SDK v 1.1.8-n and SDK v 1.1.6-n are installed as product
JAVA
- SDK v 1.2.2-n is installed as product
JAVA122
- SDK v 1.3.1-n is installed as product
JAVA131
- SDK v 1.4.0-n is installed as product
JAVA140
- SDK v 1.4.1-n is installed as product
JAVA141
- SDK v 1.4.2-n is installed as product
JAVA142
Therefore, if you decide to update to an earlier or later
version of the SDK within the same product, you should
not use the PCSI PRODUCT REMOVE command. Instead,
use the PRODUCT INSTALL of the desired kit.
By following these instructions you avoid potential shared-file
conflicts.
- Installing in the
SYS$COMMON area requires
privileges. The SYS$COMMON:[JAVA$142]directory
is the supported location for the installation of this kit.
- To use SDK v 1.4.2, you must first set
up the Java environment. You can select either the Fast VM or
the classic VM as your virtual machine.
Because you can have multiple SDK versions installed on your OpenVMS
system, and because you can change from one version to the other,
you need to follow specific steps to set up your Java environment
properly. To run the command procedure to do this, refer to Setting
Up the Java Environment in the User Guide.
- Refer to the User Guide for additional
information on how to use this product in an OpenVMS environment.
Local copies of these Release Notes and User Guide are installed
at
SYS$COMMON:[JAVA$142.DOCS]RELEASE_NOTES.HTML and
SYS$COMMON:[JAVA$142.DOCS]USER_GUIDE.HTML, respectively.
Determining Your Installed Version
After downloading, installing, and running the command procedure
to set up the Java environment, use the java -fullversion
command to display the version. For example:
$ java -fullversion
java full version "1.4.2-n"
where n identifies the specific SDK v 1.4.2
that is installed.
To switch from one version to another, see Switching
Versions in the User Guide.
Contents of the SDK
This section provides a general summary of the files and directories
contained in the SDK once it has been installed on your system.
Note: For simplicity, these release notes assume
you installed the SDK using the default location and therefore reference
SYS$COMMON:[JAVA$142] 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$142.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 Sun's 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 SDK
v 1.4.2 on OpenVMS Alpha.
Run Time Environment (RTE)
In SYS$COMMON:[JAVA$142.JRE]
An implementation of the Run Time Environment (RTE) for use by
the SDK. The runtime environment includes a virtual machine for
Java 2, class libraries, and other files that support the execution
of programs written in the Java programming language. Note:
The RTE included in the SDK is separate from the RTE kit.
Additional Libraries
In SYS$COMMON:[JAVA$142.LIB]
Additional class libraries and support files required by the development
tools.
Demo Applets and Applications
In SYS$COMMON:[JAVA$142.DEMO]
Examples, with source code, of programming for the Java platform.
These include examples that use Swing and other Java Foundation
Classes.
Additional Demos
In SYS$COMMON:[JAVA$142.VMS_DEMO]
Examples that demonstrate what is needed to write native C programs
to interact with Java code.
C Header Files
In SYS$COMMON:[JAVA$142.INCLUDE]
Header files that support native-code programming using the Java
Native Interface and the Java
Virtual Machine Debug Interface, as described on the Sun site.
Source Code
In SYS$COMMON:[JAVA$142]SRC.ZIP
Java programming language source files for all classes that make
up the Java 2 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.
Defining RMS Record Attributes
The SDK v 1.4.2-6 release provides the capability to exercise closer control over Record Management Services (RMS) file attributes used by the CRTL library to manipulate files on behalf of the J2SDK. You can now override the default RMS file operation attributes with attributes of your own choosing.
This is done by defining the OpenVMS logical name JAVA$FILENAME_MATCH_LIST. The value of JAVA$FILENAME_MATCH_LIST consists of file name patterns and RMS attributes. The RMS attributes are passed to the CRTL library by the J2SDK when it asks the CRTL library to manipulate files whose names match the file name patterns.
The value consists of one or more comma separated specifiers, where each specifier is of the form:
"file_match_pattern=<RMS parameter>/<additional RMS parameter>/<..."
Restrictions:
- Patterns/RMS parameters can not contain the ':' character.
- JRE file sharing will NOT be enabled for files matching the file_match_pattern.
- Other Java logical name settings (e.g. JAVA$CREATE_STMLF) may be ignored.
Examples:
$ define JAVA$FILENAME_MATCH_LIST "*.obj=ctx=stm"
This causes the attribute "ctx=stm" to be used when the CRTL library opens a file whose name matches the pattern “*.obj”.
Possible Usage:
On OpenVMS Alpha, *.obj files have variable length record format with a two byte header. By default, the J2SDK relies on the CRTL library to treat all files as if they have Stream_LF record format. This causes problems when using the jar tool to create a .jar file composed of .obj files. As the CRTL library reads the .obj files it converts their records to Stream_LF record format by removing the 2 byte variable length header and adding a <LF> character to the end of each record. When the .obj files are extracted from the .jar file their two byte record header will have been lost and tools such as the OpenVMS linker will not be able to properly read these .obj files.
You can avoid this problem by setting JAVA$FILENAME_MATCH_LIST as specified above. This will cause the jar tool to copy the .obj files into the .jar file without losing their two byte record headers. When the .obj files are restored they can then be converted back to a format that is acceptable to the OpenVMS linker by using the OpenVMS “$ set file/attr=(RFM:VAR)” command.
$ define JAVA$FILENAME_MATCH_LIST "*.*=shr=get,put,upi/rop=rea"
This is the equivalent of:
$ define java$file_open_mode 3
However, without JRE file sharing.
$ define JAVA$FILENAME_MATCH_LIST "*.exe=ctx=stm", -
"*.pcsi_sfx_axpexe=shr=get,put,upi/rop=rea", -
"/apache$root/logs/error*=shr=get,put,upi/rop=rea/fop=dfw,sup/mbc=127"
This example demonstrates combining multiple settings using a single instance of JAVA$FILENAME_MATCH_LIST.
This setting causes:
- *.exe files to be treated as Stream_LF record format.
- *.pcsi_sfx_axpexe files to be opened as shared.
- /apache$root/logs/error* files to be opened as shared, with deferred write, and allocated a larger than normal Multiblock Count (mbc)
For a complete list of the RMS attributes that can be set via this mechanism, see:
http://h71000.www7.hp.com/DOC/83final/5763/5763pro_027.html#fab_rab_keywords_1.
Resolving Domain Names in Java
Domain-name resolving can be done by the sockets API or the JDK itself. To make domain-name resolving work in the JDK on OpenVMS systems, you must configure your system as follows:
- Configure the BIND resolver using the ASCII configuration file TCPIP$ETC:RESOLV.CONF. For more information, refer to the document HP TCP/IP Services for OpenVMS Management.
- Add the directory map into the
java$filename_controls logical:
$ show log java$filename_controls
"JAVA$FILENAME_CONTROLS" = "131592" (LNM$JOB_899A9900)
If the directory mapping bit is not set as in the above example, set it as follows:
$ b=131592+536870912 ! add in the directory mapping bit
$ show sym b
B = 537002504 Hex = 20020208 Octal = 04000401010
$ def java$filename_controls 537002504
- Direct java to get the DNS configuration from
/sys$system/resolv.conf instead of /etc/resolv.conf:
$ DEF JAVA$DIRECTORY_MAPPING_COUNT 1
$ DEF JAVA$DIRECTORY_MAPPING_01 "/etc/resolv.conf=/sys$system/resolv.conf"
Known Issues
This section provides descriptions of the known issues and limitations
that exist in SDK v 1.4.2 for OpenVMS Alpha; these issues include
the following:
- Java Networking IPv6 support is not included in this SDK release.
- The
java.endorsed.dirs property is not supported in
the classic VM.
Important: Review the information in the Interpreting
Commands and OpenVMS Operating System Differences table in the
User Guide and the remaining sections to fully understand the nuances
and differences in this SDK.
Documentation
The SDK v 1.4.2 documentation tree begins at the following location
on the system where the SDK is installed:
SYS$COMMON:[JAVA$142.DOCS]INDEX.HTML
The installed documentation is in HTML format and includes this
release notes file and the user guide file, as well as the aforementioned
index.html file.
Note: For simplicity, these release notes assume
you installed the SDK using the default location and therefore reference
SYS$COMMON:[JAVA$142] 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.
For core API documentation, refer to the following sources:
Also, you can browse the Software
Documentation page on our web site. Optimizing
Java Technology Software Performance on OpenVMS provides tips
on improving Java performance on OpenVMS systems.
For more information on this release, refer to the Release
Notes for the J2SDK v 1.4.2 software from Sun Microsystems,
and to our User Guide for this SDK.
If you are new to the Java programming language, you can browse
or download Sun's Java
Tutorial.
Problem Reporting
To report problems, refer to our Software
Support web page.
|
