                                               Release Notes
                             Compaq Software Development Kit (SDK) v 1.1.8-14
[COMPAQ]                           for the Tru64 UNIX Operating System
                                          for the Java Platform

  ------------------------------------------------------------------------

Contents

   * Introduction
   * New Features
   * Fixed Problems
   * Compatibility
   * Known Issues
   * Installation
        o Tru64 UNIX Patches
        o Installing the Kit
        o Deinstalling the SDK v 1.1.8 Kit
        o Deinstalling Other Versions
   * Using Multiple Versions
        o Changing Your PATH to Use SDK v 1.1.8
        o Making SDK v 1.1.8 the Default System Java Environment Version
        o Switching the Default Version
        o Making Applications Insensitive to Changes in the Default Java
          Environment Version
        o Troubleshooting Multiple Versions
   * Using the SDK on Tru64 UNIX Systems
        o Determining Your Java Environment Version
        o Determining Your Default Java Environment Version
        o Controlling Heap Size
        o Controlling Stack Size
        o Mandatory Flag for Compiling C/C++ Code for JNI on Tru64 UNIX
        o Using the SDK with a Large Number of Threads
   * Prior Releases
   * Documentation and Other Information
        o More Information
   * Problem Reporting

Introduction

Thank you for downloading the Compaq Software Development Kit (SDK) v
1.1.8-14 for the Tru64 UNIX Operating System for the Java Platform
(hereafter called the Compaq SDK or, simply, the SDK). These release notes
contain installation instructions, known issues, new features, and other
information specific to the Tru64 UNIX port of Sun Microsystems' Java
Development Kit (JDK).

This kit installs SDK v 1.1.8-14, an update to SDK v 1.1.8-13. The SDK v
1.1.8-14 update kit is based on Sun's JDK 1.1.8_009 Solaris Reference
Release. This kit includes all the functionality and bug fixes that are in
Sun Microsystems' JDK V1.1.8 and passes all the tests in Sun's Java
Compatibility Kit test suite (JCK V1.1.8A). Use the java -version command
to check the version of the SDK that you are using.

This kit can be used to develop and run Java applets and programs on
systems installed with Tru64 UNIX V4.0F, V4.0G, or V5.0A and higher. If you
need to upgrade your version of Tru64 UNIX, refer to the Compaq Tru64 UNIX
web site for additional information.

Because these release notes are provided in both .txt and .html format, the
URLs for hotlinks within this file are explicitly stated, or "installed
files" are referenced (see the Documentation section of these release
notes).

IMPORTANT: Please make sure you understand the Copyright (COPYRIGHT,
installed file) and License (LICENSE, installed file) information before
using this release.

New Features

SDK v 1.1.8 is primarily a bug-fix release. Changes made to the JDK by Sun
Microsystems since the first 1.1 beta release are in the file named
changes.txt in the installed SDK documentation.

This release also includes the following new features from Compaq:

   * The SDK v 1.1.8 release provides better packing of class fields on
     Tru64 UNIX systems. The allocation of non-static class fields has been
     changed in SDK v 1.1.8 to improve the memory usage of the JVM at
     runtime. This change does not have any effect on class files. The
     improved memory usage is limited to the in-memory classes once they
     have been loaded into the JVM. This change in field allocation will be
     transparent to most users. However, see the Compatibility section for
     when you will need to recompile native methods.

   * Starting with SDK v 1.1.8 from Compaq, you can have multiple SDK
     versions installed on your Tru64 UNIX system, and the ability to
     change the default version. See Using Multiple Versions.

Fixed Problems

This kit installs SDK v 1.1.8-14. The following sections provide important
information about problems that Compaq has fixed in current and previous
releases of SDK v 1.1.8.

Problems Fixed in SDK v 1.1.8-14

This kit is based on the JDK 1.1.8_009 Solaris Reference Release from Sun
Microsystems and is provided for your use on Tru64 UNIX systems. This kit
also fixes the following problem:

   * Previously, using SDK v 1.1.8-13, the jar command created .jar files
     which could not be read. This problem has been fixed in this release.

See sun_changes_1_1_8_009.txt for a list of other problems fixed by Sun in
the 1.1.8_009 Solaris Reference Release.

Problems Fixed in SDK v 1.1.8-13

The SDK v 1.1.8-13 kit is based on the JDK 1.1.8_008 Solaris Reference
Release from Sun Microsystems and is provided for your use on Tru64 UNIX
systems. This kit also fixes the following problems:

   * Many improvements have been made to SDK v 1.1.8 handling of Chinese
     and Japanese fonts.

   * Problems that caused earlier versions of SDK v 1.1.8 to hang or seg
     fault have been resolved.

   * Incompatibility involving zlib and SDK v 1.1.8 has been resolved.

Problems Fixed in SDK v 1.1.8-10

The SDK v 1.1.8-10 kit is based on the JDK 1.1.8_008 Solaris Reference
Release from Sun Microsystems and is provided for your use on Tru64 UNIX
systems. This kit also fixes the following problems:

   * A problem that caused a memory leak when doing garbage collection on
     classes has been fixed.

   * A correction was made to the Numeric Keypad so that it works correctly
     in the context of AWT classes when the Num Lock key is set.

   * A correction was made for JTextField and JTextArea classes so that the
     Caps Lock key works correctly when displaying on Motif or CDE.

   * A correction was made for JTextField and JTextArea classes so that the
     Delete key works correctly.

Problems Fixed in SDK v 1.1.8-7

The SDK v 1.1.8-7 kit is based on the JDK V1.1.8-003 patch version from Sun
Microsystems, and is provided for your use on Tru64 UNIX systems. This kit
also fixes the following problems:

   * A problem that caused the Java Virtual Machine to occasionally crash
     when running on multi-processor machines has been fixed.

   * The number of array elements was previously limited to 67,108,863 due
     to a bug which assumed a 32-bit limit. This has been corrected such
     that 64-bits are utilized and the maximum array elements has grown
     substantially.

Problems Fixed in SDK v 1.1.8-5

The SDK v 1.1.8-5 kit is based on the JDK V1.1.8-002 patch version from Sun
Microsystems, and is provided for your use on Tru64 UNIX systems. This
patch version fixes the following problems:

   * This kit incorporates Sun's code fix for bug #4081779 titled
     "Container.remove(component) does not release the component from
     GridBagLayout" and #4170095 "Unintentional memory retention in
     GridBagLayout". Previously, this could lead to memory leaks in certain
     applications.

   * The SDK v 1.1.8-5 kit now provides font properties files to correctly
     support the display of Japanese and Chinese text.

   * Previously, Chinese input could not be entered for TextField
     components. The Sun bug numbers that are related to this problem are
     bug #4105612 and bug #4196573. This problem has been corrected.

   * Previously, when running the DateTimeFormat demo program and selecting
     Japanese as the language, Japanese characters could not be input to
     the pattern field. This problem has been corrected.

   * Sun bug #4267381 (Focus Lost problem) has been corrected for this
     release.

   * Previously, when using the eXcursion window manager, the following
     would occur:

        o A frame would jump back to a previous location.
        o A ComponentMoved event was not being recognized.

     These problems have been fixed. The frame no longer jumps and the
     ComponentMoved events are now recognized for a frame.

   * Previously, when using the Motif window manager or eXcursion window
     manager, the titlebar and border of the window frame would
     occasionally appear off the screen. This problem has been fixed.

Problems Fixed in SDK v 1.1.8-2

   * The SDK v 1.1.8-2 kit provides a modified
     /usr/opt/java118/lib/font.properties.ja file, which correctly displays
     English text when the locale is set to Japanese.

   * Previously, when remotely displaying to a Tru64 UNIX machine, the
     components (such as JPEGs, GIFs, and Swing components) of a top-level
     window might not display properly. This problem has been fixed.

Compatibility

There are some compatibility issues with SDK v 1.1.8:

   * Unlike prior SDK releases, this kit does not necessarily install SDK v
     1.1.8 as the default version. You may need to define your PATH
     environment variable or make SDK v 1.1.8 the system default before you
     can use SDK v 1.1.8. See Using Multiple Versions.

   * You should not put /usr/lib/classes.zip in your CLASSPATH if you have
     multiple versions installed. Many Java users routinely include
     /usr/lib/classes.zip in their CLASSPATH, but that can result in
     unexpected program behavior when using a non-default version of the
     SDK. See Using Multiple Versions for more information.

   * Because of the new way that SDK v 1.1.8 packs class fields, you might
     need to recompile some of your native methods. Native methods that use
     header files created by running javah without the jni switch should be
     recompiled.

     In this case, the generated header file reveals the runtime structure
     of fields in a class. The javah command generates a C struct
     declaration with extra fields, named _PADn_, in between the
     user-defined fields. These _PADn_ fields are sometimes needed to
     assure the proper alignment of the user-defined fields. With the
     change to field allocation, the number and placement of the _PADn_
     fields can be different.

     To ensure proper functionality with this release of the SDK, you
     should run javah and recompile any native methods that require the new
     header files.

     Here is an example to illustrate the change. Consider the following
     Java code:

             class fieldtest {
                 int f1;
                 long f2;
                 int f3;
             }

     javah in SDK v 1.1.8 generates the following struct:

             typedef struct Classfieldtest {
                 int f1;
                 char _PAD8_[4];
                 int64_t f2;
                 int f3;
             } Classfieldtest;

     javah in earlier releases of the SDK generated this struct:

             typedef struct Classfieldtest {
                 int f1;
                 char _PAD8_[4];
                 int64_t f2;
                 char _PAD24_[8];
                 int f3;
             } Classfieldtest;

     The _PADn_ fields should not be referenced by the native methods, so
     just recompiling with the new header file is sufficient.

Known Issues

This kit passes the complete set of tests in the current version (V1.1.8A)
of the Java Compatibility Kit (JCK) made available by Sun to licensees.
However, there are some known problems in this release. They are:

Font Point Sizes

The JDK V1.1.8 as implemented by Sun for Solaris and Win32 incorrectly
implements font point sizes. To correct this problem, our kit includes a
font properties file named lib/font.properties.truepointsize which
implements correct point sizes for Java fonts. To use this file, copy it to
lib/font.properties. If you then wish to revert to the incorrect font sizes
used by Sun, just delete lib/font.properties.

Retired Fonts

As of Compaq Tru64 UNIX Version 4.0F, all Adobe fonts under
/usr/lib/X11/fonts/Type1Adobe are retired and no longer ship with the
operating system. For more details on this, please refer to the section
"Features and Interfaces Scheduled for Retirement" in the Release Notes for
the Tru64 UNIX operating system.

If your Java application uses the retired Type1Adobe outline fonts, it
might be affected. For example, when characters are displayed on the
screen, they might not scale as expected. If you customized your
font.properties file to use these outline fonts, you might need to modify
it to use alternative fonts that are available on your operating system. No
replacements are being provided by the operating system. However, a smaller
set of outline fonts is still available in /usr/lib/X11/fonts/Type1 and
/usr/lib/X11/fonts/Speedo for your use.

Problem with Component.getCursor()

In SDK v 1.1.8, getCursor() might return null when called on a component
that has not had its cursor explicitly set. This behavior is a bug.
Existing applications that assume getCursor() will not return null might
not work properly with the SDK or software for the Compaq Run Time
Environment (RTE) v 1.1.8 for the Tru64 UNIX Operating System for the
Java Platform (hereafter called the Compaq RTE or, simply, the RTE). The
bug will be fixed in a future release of the SDK software.

Unexpected Backspace Key Behavior

If you use a non-PC style keyboard, or you display to a PC using
eXcursion, the Backspace key might not behave as expected when used in the
context of one of the Swing text widgets (JTextField, JTextArea,...).

Problem Description:

Pressing the Backspace key deletes the character that the cursor is on as
opposed to the character preceding the cursor. This is not a bug with the
SDK. It has to do with the keycode sent by the Backspace key.

Workaround:

This behavior can be modified by instructing the keyboard driver to send a
Backspace keycode instead of a Delete keycode.

For eXcursion:

  a. Go to directory \win32app\xcursion\keysyms and copy the appropriate
     keyboard mapping file (keysym) to delfix.txt.

     Determining your keysym file:

        o keysym files all start with "isenh".

        o The next letter is either a 'd' or 'i'. (d is for Digital, i is
          for IBM compatible). Use the one that you have selected in your
          Control Panel keymapping style.

        o The next 2 letters are a Country code. Use the one for your
          country.


  b. Edit the file delfix.txt:

     Under the main keypad section, modify:

        0x0E unshifted XK_Delete

     to be:

        0x0E unshifted XK_BackSpace

  c. Save and exit the file.
  d. Bring up the Control Panel for eXcursion.
  e. Select the Custom Keyboard tab.
  f. Under Primary Mapping, select Custom Key Def File.
  g. Select delfix.txt.
  h. Save and restart the Server.

This should reprogram your backspace key to send "backspace" instead of
"delete".

For X11 with non-PC style keyboard:

Execute the command:

   xmodmap -e "keysym Delete = BackSpace Delete"

Installation

The following sections describe how to install the SDK v 1.1.8 kit on your
Tru64 UNIX system.

Tru64 UNIX Patches

This kit requires Tru64 UNIX V4.0F, V4.0G, or V5.0A and higher.

Presently, this SDK v 1.1.8-14 release does not require any operating
system patches. However, the need for patches may be discovered after this
release becomes available. Therefore, we recommend that you check our patch
installation page for Compaq Tru64 UNIX for the latest information.

Installing the Kit

If your system currently has a previous SDK v 1.1.8 kit installed, then you
must deinstall that kit before installing the SDK v 1.1.8-14 kit.

If your system currently has a SDK v 1.2.n or SDK v 1.1.7B or earlier SDK
kit installed, then you do not need to deinstall the kit to use the SDK v
1.1.8 Update release. Starting with SDK v 1.1.8, you can have multiple SDK
versions installed on your system and can change the system default Java
environment version under some circumstances. If there is not a default
Java environment version on your system when this kit is installed, SDK v
1.1.8 is made the default. Otherwise, SDK v 1.1.8 is installed but not as
the default system version. In this case you need to define your PATH
environment variable or make SDK v 1.1.8 the system default before you can
use SDK v 1.1.8. See Using Multiple Versions.

                                   NOTE

 SDK v 1.1.8 is available from our Software Download Page and is also
 bundled with some versions of the Compaq Tru64 UNIX operating system.
 However, the Java subset names are different. Kits downloaded from our
 Software Download Page begin with the subset name "JAVA." In contrast,
 Java subsets included with the Tru64 UNIX operating system begin with
 the name "OSF".

 For a description of both Java subsets, see Step 5. For additional
 information about installing the SDK during the Compaq Tru64 UNIX
 installation, see the Compaq Tru64 UNIX Installation Guide.

To install SDK v 1.1.8, perform the following steps as superuser:

  1. You may leave any SDK v 1.1.n installed kit in place. The SDK v 1.1.n
     kit remains the default and allows the SDK v 1.1.8 kit to be enabled
     when the PATH environment variable is modified. If you want to
     deinstall prior versions, see Deinstalling Other Versions.

  2. If you installed a previous SDK v 1.1.8 kit, use the setld command to
     delete it:

       a. Use the setld -i command to determine which SDK v 1.1.8 subsets
          are installed:

             setld -i | grep JAVA118 | grep installed

       b. To delete all of the old Java subsets found, enter the setld -d
          command. For example:

             setld -d JAVA118 JAVADEV118 JAVADOC118

  3. Download the following binary kit:

        java118-14.tar

  4. Untar it into a scratch directory, /tmp/java, for example:

        cd /tmp/java
        tar xf /tmp/java/java118-14.tar

     The scratch directory now contains the kit plus the following files:

        release_notes.txt
        COPYRIGHT
        LICENSE

  5. Use the setld command to load from that scratch directory:

        setld -l /tmp/java

     There are three subsets that you can install:

        o JAVA118 - The mandatory subset that provides support for running
          Java programs and applets.

        o JAVADEV118 - The development environment, which allows you to
          compile and debug Java code.

        o JAVADOC118 - The documentation subset.

     We recommend that you install all three subsets if you intend to use
     the SDK in a development capacity.

                   Compaq Tru64 UNIX Subset Names

       The Software Download Page uses the subset names listed
       in Step 5. However, if SDK v 1.1.8 has been installed as
       part of the Compaq Tru64 UNIX operating system
       installation, it will have the following subset names:

          * OSFJAVAnnn - The mandatory subset that provides
            support for running Java programs and applets.

          * OSFJAVADEVnnn - The development environment, which
            allows you to compile and debug Java code.

          * OSFJAVADOCnnn - The documentation subset.

       where nnn refers to the base operating system version
       number.

       Note that if you are updating to a later version of SDK
       v 1.1.8, you must first deinstall these subsets. See
       Deinstalling Other Versions for instructions.


  6. Once you have installed the desired subsets, you can delete the
     scratch directory.

The SDK v 1.1.8 kit is installed under its own directory tree. This means
that all the binary files, include files, library files, and so on, are
listed in appropriate directories under /usr/opt/java118.

As noted above, SDK v 1.1.8 may or may not be the default system Java
environment after installation and you may need to take action before you
can use SDK v 1.1.8. See Using Multiple Versions.

Once you are set up to use SDK v 1.1.8 by means of one of these methods,
the java -version command should display the following for this kit:

   % java -version
   java version "1.1.8-14"

Deinstalling the SDK v 1.1.8 Kit

If you want to deinstall this kit in the future, perform the following
steps as superuser:

  1. Use the setld -i command to determine which SDK v 1.1.8 subsets are
     installed. For example:

        setld -i | grep JAVA | grep 118 | grep installed

  2. To delete subsets, enter the setld -d command. For example,

        setld -d JAVA118 JAVADEV118 JAVADOC118

Deinstalling Other Versions

To deinstall other versions, perform the following steps as superuser:

  1. Use the setld -i command to determine what Java subsets are installed
     and which you want to delete.
  2. Use the setld -d command to delete the Java subsets.

For example:

   % setld -i | grep JAVA | grep installed
   OSFJAVA440     installed     Java 1.1.7B-5 Environment (General Applications)
   OSFJAVADEV440  installed     Java 1.1.7B-5 Development Environment
   OSFJAVADOC440  installed     Java 1.1.7B-5 Online Documentation

   % setld -d OSFJAVA440 OSFJAVADEV440 OSFJAVADOC440

Using Multiple Versions

With SDK v 1.1.7B and previous versions, it was possible to install only
one SDK version on a system. Starting with SDK v 1.1.8 and SDK v 1.2.1, you
can install and use multiple versions on one system. In addition, you can
change the version that is used by default when you type Java commands.

When you install SDK v 1.1.8, all files are installed in directories under
/usr/opt/java118. In addition:

   * If a default system Java environment version (/usr/bin/java) is not
     found during installation, SDK v 1.1.8 is installed as the default
     system Java environment version on the system and no special actions
     are required before using SDK v 1.1.8. In this case, the java -version
     command should display the following after installation:

        % java -version
        java version "1.1.8-14"

   * If a default system Java environment version is found during
     installation, SDK v 1.1.8 is installed on the system but is not made
     the default Java environment version. In this case, you need to take
     one of the following actions before you can use it:

        o Change your PATH environment variable so that the directory
          containing the SDK v 1.1.8 binaries is searched before the system
          directories. See Changing Your PATH to Use SDK v 1.1.8.

        o Make SDK v 1.1.8 the system default. See Making SDK v 1.1.8 the
          Default System Java Environment Version. You can make SDK v 1.1.8
          the default Java environment version on your system at any time,
          provided that no SDK version prior to SDK v 1.1.8 is installed.
          When you make SDK v 1.1.8 the default, system files such as
          /usr/bin/java are modified so that SDK v 1.1.8 is used whenever
          Java commands are entered, and defining your PATH is not
          necessary.

Changing Your PATH to Use SDK v 1.1.8

If SDK v 1.1.8 is not the default Java environment version on your system,
you must either specify the full pathname of the java command or change
your PATH environment variable to use it.

   * To specify the full pathname of the java command:

          % /usr/opt/java118/java -version
          java version "1.1.8-14"

   * To switch to using SDK v 1.1.8:

       1. Place directory /usr/opt/java118/bin first in your PATH. This is
          the directory that contains the SDK v 1.1.8 executables. For
          example, using csh(1):

             setenv PATH /usr/opt/java118/bin:$PATH

       2. Verify that you are using SDK v 1.1.8:

             % java -version
             java version "1.1.8-14"

       3. Check your CLASSPATH to make sure that you won't use the
          classes.zip file for a version of the SDK other than SDK v 1.1.8:

             % printenv CLASSPATH

          To avoid the possibility of using the wrong classes.zip file, you
          should:

             + Remove /usr/lib/classes.zip from your CLASSPATH.
             + Remove /usr/opt/javannn/lib/classes.zip from your CLASSPATH
               for any version nnn other than 118.

          Using classes.zip from one version of the SDK with Java commands
          from another can result in unexpected program behavior. For
          example, if SDK v 1.1.7B is the default version and your
          CLASSPATH contains /usr/lib/classes.zip, your program will use
          the SDK v 1.1.7B classes.zip. If you then define your PATH to use
          SDK v 1.1.8, it is likely that your program will get a
          segmentation fault.

          If your CLASSPATH is not set, the correct classes.zip file will
          be used by default when you modify your PATH as described above.
          If you want to explicity reference the SDK v 1.1.8 classes.zip in
          your CLASSPATH, you should modify your CLASSPATH to include
          /usr/opt/java118/lib/classes.zip.

   * To stop using SDK v 1.1.8, remove /usr/opt/java118/bin from your PATH.

Making SDK v 1.1.8 the Default System Java Environment Version

Perform the following steps as superuser to make SDK v 1.1.8 the default
system Java environment version on your system:

  1. Determine what the default system Java environment version is on your
     system by using the following command:

        /usr/bin/java -version   # Note: Use /usr/bin/java to insure
                                 #       that the default Java is executed.

  2. Choose one of the following actions based on the version of the
     default system Java environment version:

        o If the above command results in a "command not found" message,
          there is currently no default system Java environment version on
          your system, and therefore nothing needs to be removed. After
          doing the following, SDK v 1.1.8 will be the default:

             /usr/opt/java118/bin/set_java_default.sh

        o If a version later than SDK v 1.1.7B, say SDK v 1.2.2, is the
          default, do the following to remove it as the default and to set
          SDK v 1.1.8 as the new default:

             /usr/opt/java121/bin/unset_java_default.sh
             /usr/opt/java118/bin/set_java_default.sh

        o If SDK v 1.1.7B or a previous version is the default and no one
          on your system needs it, deinstall the old default (see
          Deinstalling Other Versions) and then make SDK v 1.1.8 the
          default version by doing:

             /usr/opt/java118/bin/set_java_default.sh

  3. Verify that SDK v 1.1.8 is now the new default version:

        /usr/bin/java -version
        java version "1.1.8-14"

Switching the Default Version

If any versions prior to SDK v 1.1.8 are installed, this section does not
apply. You need to deinstall any older versions before you can make SDK v
1.1.8 or later the default version. See Deinstalling Other Versions.

If you have made SDK v 1.1.n the default version (for n greater or equal to
8), this section shows how to switch the default version to SDK v 1.2.n.
Also, in the future, users can have an arbitrary number of different SDK
versions; this section gives a general recipe for switching from one to
another.

Assume that SDK v 1.1.n and SDK v 1.2.n are currently installed and that
SDK v 1.1.n is the current default. To make SDK v 1.2.n the default Java
environment version, perform the following steps as superuser:

  1. Verify that SDK v 1.1.n is the current default:

        /usr/bin/java -version   # Note: Use /usr/bin/java to insure
                                 #       that the default Java is executed.

  2. Remove SDK v 1.1.n as the current default:

        /usr/opt/java11n/bin/unset_java_default.sh

     Note that this script does not deinstall SDK v 1.1.n. You can make SDK
     v 1.1.n the default again later if desired.

  3. Make SDK v 1.2.n the current default version:

        /usr/opt/java12n/bin/set_java_default.sh

  4. Verify that SDK v 1.2.n is now the default version:

        /usr/bin/java -version

Making Applications Insensitive to Changes in the Default Java Environment
Version

You may have applications that rely on SDK v 1.1.8. To safeguard them
against future changes in the default Java environment version, you can run
them from scripts that set the PATH to SDK v 1.1.8. See Changing Your PATH
to Use SDK v 1.1.8.

Troubleshooting Multiple Versions

If you have multiple versions installed on your system and have troubles
running Java applications, first check what Java environment version you
are using and what the default Java environment version is on the system:

   % java -version                  # Check version being used
   % /usr/bin/java -version         # Check default Java on system

Then check your definitions of PATH and CLASSPATH:

   printenv PATH
   printenv CLASSPATH

If you encounter the error "java: Permission denied", check that PATH is
set properly. See Changing Your PATH to Use SDK v 1.1.8.

If you get a seg fault or other unexpected behavior when running your Java
application, check your CLASSPATH to make sure that you are not using a
classes.zip from an SDK version other than SDK v 1.1.8. See Changing Your
Path to Use SDK v 1.1.8.

Using the SDK on Tru64 UNIX Systems

The following sections provide some useful tips for using the SDK on Tru64
UNIX systems.

Using SDK v 1.1.8

See Changing Your PATH to Use SDK v 1.1.8 for information about defining
your PATH environment variable to use SDK v 1.1.8. Also, see Making SDK v
1.1.8 the Default System Java Enviornment Version if you want to make SDK v
1.1.8 the default Java environment version on your system.

Determining Your Java Environment Version

Use the following command to see what Java environment version you are
using (refer to Frequently Asked Questions for an explanation of this
version-naming convention):

   % java -version
   java version "1.1.8-14"

Determining Your Default Java Environment Version

Use the following command to determine the Java environment version you are
currently using:

   % /usr/bin/java -version
   java version "1.1.8-14"

Controlling Heap Size

The initial heap size (-ms) and maximum heap size (-mx) command-line
options control the size of the Java heap. The default values for these
are:

   initial heap size =  1048576 bytes

   maximum heap size = 16777216 bytes

The Java heap, by default, is allocated at address 0x10000. The maximum
heap size prior to SDK v 1.1.7B was limited to 2147475455 by its underlying
int type. (This value is slightly less than INT_MAX because of a rounding
calculation applied to the user-specified value.) Starting with SDK v
1.1.7B, the -mx and -ms command-line option values are treated as longs,
allowing much larger heaps.

Example:

    java -mx40000m MyApp

Heaps larger than 2147475455 are allocated at address 0x20000000000. Note
that there may be a noticeable start-up delay in initializing the heap's
internal data structures if you specify a very large initial heap value
(for example, -ms4000m). You can avoid this by using a smaller initial heap
size. This effectively spreads the cost of expanding the heap structures
over the execution of the application.

For JNI users who create JVM's from native code, the minHeapSize and
maxHeapSize fields in the JDK1_1InitArgs structure remain as jints.
However, you can use the macros SET_MIN_HEAP_SIZE and SET_MAX_HEAP_SIZE,
defined in jni.h, to specify values for heaps larger than 2147475455.
Please see the comments in the file jni.h for more information.

Your system must be properly set up to allow very large heaps. The garbage
collector initialization code will try to allocate the maximum sized heap.
If this fails, it will continually apply a "backoff" factor of .75 and will
try again. Heap allocation succeeds if the heap size successfully allocated
is not less than the -ms value. Thus, it may appear as if you got the
maximum heap size you asked for when you did not.

To avoid excessive page faulting, consider the amount of physical memory
available to your process when choosing the maximum heap size. Garbage
collection tends to walk through the entire heap, so you'll need at least
enough to insure that none of the heap is paged out.

For more information on system tuning and resource limits, see the
following:

   * Tru64 UNIX System Configuration and Tuning, specifically the section
     Increasing Address Space
   * C shell commands limit and unlimit, specifically addressspace
   * manpages setrlimit(2) and getrlimit(2)

Controlling Stack Size

You can increase or decrease the maximum native stack size using the -ssn
command-line switch. Note that decreasing the native thread stack size can
save memory but can also result in segmentation violation errors or other
problems if the native thread stacks are too small.

Mandatory Flag for Compiling C/C++ Code for JNI on Tru64 UNIX

All C/C++ code compiled for use with JNI must be built (compiled and
linked) with the C/C++ -pthread flag. Otherwise, your application will
encounter severe multi-threading problems, even if your Java code and C/C++
code do not explicitly use threads. For more information about the -pthread
flag, please see the C/C++ man pages.

Using the SDK with a Large Number of Threads

If you experience a "java.lang.OutOfMemoryError" when attempting to create
a large number of threads, consider increasing the system (that is, kernel)
parameter vm-vpagemax. A recommended setting is the number of 8k pages used
in the program's virtual address space. For example, for a 1Gbyte virtual
address space, vm-vpagemax should be set to 128000.

This parameter is described in the Tru64 UNIX System Configuration and
Tuning manual. Relevant tools are briefly described by man sysconfig and
man sysconfigdb. To change the vm-vpagemax parameter, use the
/sbin/sysconfigdb command to update a section of /etc/sysconfigtab. For
example, to modify vm-vpagemax to be 128000, the input file to the
/sbin/sysconfigdb command (specified using the -f option) would contain the
following:

   vm:
   vm-pagemax = 128000

The default value for vm-vpagemax is 16384. Use the following command to
determine the value of vm-vpagemax on a running system:

   %    > sysconfig -q vm vm-vpagemax
   vm:
   vm-vpagemax = 16384

Prior Releases

Features of the SDK v 1.1.7B Release

   * With SDK v 1.1.7B, the amount of heap space that can be used for Java
     objects has been increased so that Java programs can take full
     advantage of 64-bit addressing on Alpha. With previous versions, the
     heap space used for Java objects was limited to 2,147,475,455 bytes.
     Note, however, that the Java Debugger (jdb) does not support heap
     sizes larger than 2,147,475,455.

     With SDK v 1.1.7B, the way the SDK allocates the heap has changed:
     first, the SDK makes an initial check to insure that the maximum
     requested heap size, as specified by the -mx switch, can be allocated.
     Then the SDK allocates a minimum heap size and grows the heap
     incrementally to the maximum heap size.

     This means that the amount of heap space used by your Java program
     depends on how much it actually needs. In previous SDK releases, the
     maximum requested heap size was allocated by the SDK at program
     startup, regardless of whether or not it was actually used by your
     Java program.

   * The SDK v 1.1.7B kit includes the Sun Java demos.

     These demos are included in the OSFJAVADOCxxx subset of the kit (where
     xxx represents a number such as 440, which corresponds to the version
     of the operating system). The demos are installed in:

        /usr/share/doclib/java/demo

Features of the SDK v 1.1.6 Release

The SDK v 1.1.6 release fixes a garbage collector bug in previous SDK v
1.1.n releases that could lead to segmentation faults when running Java
programs.

The -taso option is supported for RTE. See the next section for information
on the -taso option.

Features of the SDK v 1.1.3 Release

The -taso Option

The SDK v 1.1.3 release supports the -taso option. This option causes all
Virtual Machine addresses to be mapped into 31-bit address space. Specify
the -taso option if your Java program calls native methods that were built
with 32-bit pointers. This includes, for example, native methods that were
compiled with the cc options -xtaso and -xtaso_short.

To use the java -taso option:

    java -taso my_class_file
 or
    java_g -taso my_class_file

To use -taso with appletviewer:

    appletviewer -J-taso my_class_file

Features of the SDK v 1.1.1 Release

Audio Support

The SDK v 1.1.1 release contains support for Java Audio classes.

Features of the SDK v 1.1 Release

POSIX Threads

SDK v 1.1 is implemented using POSIX threads. This allows different Java
threads in your application to run on different processors, provided that
you have a multi-processor machine. It also means that your Java
application will run properly when linked with native APIs (such as DCE)
that also are implemented using POSIX threads.

Just-in-Time Compiler

The SDK v 1.1 release contains a Just-in-Time (JIT) compiler to
substantially increase run-time performance. The JIT compiler provides
on-the-fly compilation of your application's Java byte-codes and runtime
calls into native Alpha machine code. This results in significantly faster
execution of your Java application compared with running it using the Java
interpreter, while maintaining the same behavior.

Please see our Compaq web page for benchmark results.

The JIT compiler runs by default when you enter the java command. If you
want to run the interpreter when you enter the java command, use the -nojit
option. For example:

   java -nojit ...

The Java Debugger runs the interpreter. Running the Java Debugger with the
JIT compiler is not supported.

The JIT compiler runs by default when you run appletviewer. To run
appletviewer using the interpreter, use the -J-nojit option. For example:

   appletviewer -J-nojit ...

Documentation and Other Information

Documentation

If the optional documentation subset (JAVADOC118) is installed, then the
SDK documentation tree begins at the following location on the system where
the SDK is installed:

   /usr/opt/java118/docs/index.html

The installed documentation is in html format and includes this release
notes file (which describes SDK information specific to Tru64 UNIX systems)
and a readme.txt file (which contains general information on using the Java
programming language). It also includes the Java Language Specification and
API reference documentation.

You can browse the Software Documentation page on our web site.

Lastly, there is a java manpage that describes the java command and points
to the installed documentation. The java manpage ships with the operating
system and describes the version of the SDK that was shipped; the manpage
is not updated by this kit.

More Information

For more information on this release, refer to our Frequently Asked
Questions (FAQ) web page.

If you are new to the Java programming language, you will want to browse or
download Sun's Java Tutorial at http://java.sun.com/docs/books/tutorial/.

Problem Reporting

To report problems, refer to our Contact Us web page.

  ------------------------------------------------------------------------
  2002 Compaq Information Technologies Group, L.P.
 Compaq Registered in U.S. Patent and Trademark Office.
 Java and all Java-based marks are trademarks or registered trademarks of
 Sun Microsystems, Inc. in the U.S. and other countries.
 All other product names mentioned herein may be trademarks or registered
 trademarks of their respective companies.
 Compaq shall not be liable for technical or editorial errors or omissions
 contained herein. The information in this document is subject to change
 without notice.
