Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
»  Contact HP
Java Technology Software
HP.com home

Release Notes

Software Development Kit (SDK) v 1.3.1-8
for the Tru64™ UNIX® Operating System

for the Java™ Platform

Content starts here

Contents

Introduction

Thank you for downloading the Software Development Kit (SDK) v 1.3.1-8 for the Tru64™ UNIX® Operating System for the Java™ Platform (hereafter called the SDK). These release notes contain installation instructions, new features, known issues, fixed problems, usage documentation, and other information specific to the Tru64 UNIX port of Sun Microsystems' Java 2 SDK, Standard Edition (J2SDK).

SDK v 1.3.1-8 implements the J2SDK v 1.3.1, and is based on Sun’s J2SDK 1.3.1_20 Solaris Reference Release. It passes all the tests in Sun's Java Compatibility Kit test suite (JCK V1.3a). 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.1A and higher. If you need to upgrade your version of Tru64 UNIX, please refer to the Tru64 UNIX web site for additional information.

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. To run the classic VM, specify the Java -classic option on the command line.

  • The Fast Virtual Machine is the default virtual machine. It was previously provided as a separate download. Because the Fast VM is included in this kit, it is no longer provided as a separate kit. Refer to Fast Virtual Machine (Fast VM) v 1.3.1 is now the default VM for the SDK for more information.

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.3.1. HP recommends that you read Sun's Java 2 SDK, Standard Edition, version 1.3 Summary of New Features and Enhancements for a thorough description of all new features and enhancements available in the J2SDK v 1.3.

SDK v 1.3.1-8 New Features

This kit installs SDK v 1.3.1-8, which is a maintenance release with no new features from HP.

SDK v 1.3.1-7 New Features

SDK v 1.3.1-7 was a maintenance release with the following new features from HP.

Note: Precompiled standard class files are no longer available with SDK v 1.3.1.

Expiring Certificates Replaced

Expiring certificates in the /usr/opt/java131/jre/lib/security/cacerts file have been replaced with the latest updates.

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 -Xcode32M.

SDK v 1.3.1-6 New Features

SDK v 1.3.1-6 was a maintenance release with no new features from HP.

SDK v 1.3.1-5 New Features

SDK v 1.3.1-5 was a maintenance release with no new features from HP.

SDK v 1.3.1-4 New Features

SDK v 1.3.1-4 was a maintenance release with no new features from HP.

SDK v 1.3.1-3 New Features

SDK v 1.3.1-3 was a maintenance release with the following new features from HP.

Reduced Fast VM Memory Requirements

The Fast VM is optimized for large, long-running programs running on server systems. Many users would like to use the Fast VM on their workstations for client-side applications; however, some of these systems do not have the resources to start up the Fast VM with its default configuration. A -client switch has been added to address these needs. For more information, refer to Reducing Fast VM Memory Requirements for Workstations and Client-side Applications.

SDK v 1.3.1-2 New Features

SDK v 1.3.1-2 was a maintenance release with no new features from HP.

SDK v 1.3.1-1 New Features

SDK v 1.3.1-1 contained the following new features from HP:

Fast Virtual Machine (Fast VM) v 1.3.1 is now the default VM for the SDK

The Fast Virtual Machine (Fast VM) is the default SDK VM. Because it is installed transparently as a part of the SDK v 1.3.1 kit, you no longer need to download and install the Fast VM kit separately.

Benefit: The Fast VM provides optimal runtime performance on Tru64 UNIX systems and offers significant performance advantages over the classic VM.

The classic VM is still provided with the SDK, via the -classic command line option. For more information on VM options, see Selecting the VM and Compatibility.

Compacting Garbage Collector

This version of the Fast VM supports an alternative compacting garbage collector, which compacts live data in-place, rather than copying it as the default collector does. This collector is a hybrid mark-sweep/mark-compact collector, which will avoid moving data when it is not necessary.

Benefit: This collection scheme can have better performance characteristics and lower heap size requirements for applications in which the heap contains a high percentage of long-lived data. This collector can also perform minor collections, rather than collecting the entire heap, when the percentage of live data is moderate. It can also perform sweeps, which free space without moving any data at all. Thus, it may also provide performance advantages for certain applications with a moderate amount of long-lived data, but a high rate of short-lived object turnover.

To use the compacting collector, specify the  -Xgc:compacting  option on the command line. The  -Xgc:copying  option causes the Fast VM to use the default "copying" collector.

Plug-in

SDK v 1.3.1 includes the Plug-in for the Tru64 UNIX Operating System (hereafter called the Plug-in) that enables users to run Java applets and JavaBeans™ components on web pages using the Run Time Environment (RTE) for the Tru64 UNIX Operating System (hereafter called the RTE) as an alternative to using the default Virtual Machine for Java 2 that comes with the web browser. Based on the Java Plug-in 1.3.1 provided by Sun Microsystems, the Plug-in contains similar functionality.  The Open JVM Interface (OJI) Plug-in is now supported. For more information, refer to Using the Plug-in.

Benefit: The SDK v 1.3.1 kit provides the Plug-in so a separate download is not required.

Fixed Problems

The following sections provide important information about problems that HP has fixed in SDK v 1.3.1. 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.3.1-8

This kit installs SDK v 1.3.1-8, and is based on Sun’s J2SDK 1.3.1_20 Solaris Reference Release. It includes the following fixed problem 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.

Problems Fixed in SDK v 1.3.1-7

The SDK v 1.3.1-7 was based on Sun’s J2SDK 1.3.1_12 Solaris Reference Release. It contains the following HP-specific fixes:

  • When running the Fast VM, several SEGV exceptions and Assertion failed:... problems were fixed.

  • The Fast VM now supports the -Xrs option, as described on Sun's site.

  • sun.io.Signal() correctly throws the Signal Already used by VM: Exception.

  • 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 a SEGV exception could occur on the subsequent collection. This has been corrected.

  • This release contains fixes to correct memory leaks in long-running applications that use DECwindows.

  • A problem where the Fast VM aborts with Unable to suspend thread when thread suspension fails has been fixed.

  • Previously, when accessing Java libraries from a C program using JNI and LD_LIBRARY_PATH was not specified, a problem occurred. 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, when invoking the java command using the nohup tool, a Fast VM problem occasionally caused premature process termination. This has been corrected.

Problems Fixed in SDK v 1.3.1-6

SDK v 1.3.1-6 was based on Sun’s J2SDK 1.3.1_08 Solaris Reference Release.

  • This release fixes some IllegalAccessError errors that previously occurred when using the Fast VM.


  • The native stack size for Java threads has been increased to approximately 512 KB.


  • Previously, when running the JIT, an IncompatibleClassChangeError exception could occur. This has been corrected.


  • Previously, if you were using SDK v 1.3.1-4 or v 1.3.1-5 on Tru64 UNIX V5.1B, the SysMan Station Authentication server would quietly fail to start at system boot time. This would cause problems later on when using the SysMan Station operating system tool. This regression has been fixed in this release.


  • A C program that establishes a user defined SIGSEGV handler no longer causes an infinite loop when using the Fast VM.

Problems Fixed in SDK v 1.3.1-5

SDK v 1.3.1-5 was based on Sun’s J2SDK 1.3.1_04 Solaris Reference Release.

  • SDK v 1.3.1-3 and v 1.3.1-4 for Tru64 UNIX introduced a regression in command-line option switch processing. When using the Fast VM, defining the CLASSPATH environment variable would incorrectly override the -classpath option on the command line. This has been corrected so that if the -classpath option is specified on the command line, it will override the definition of the CLASSPATH environment variable.

  • When using the Fast VM, a memory leak involving AWT calls has been corrected.

  • Previously, using the middle mouse button to paste text into a JTextField would result in a NullPointerException or a ClassCastException. This problem has been corrected.

Problems Fixed in SDK v 1.3.1-4

SDK v 1.3.1-4 was based on Sun’s J2SDK 1.3.1_04 Solaris Reference Release.

  • Previously, if libnspr4.so was installed on your system, the Plug-in for Netscape 4.x browsers would fail to initialize and cause Netscape Communicator to exit with the following error:

    INTERNAL ERROR on Browser End: Could not load libjavaplugin_oji.so: linking
    error=dlopen: cannot load directory/.netscape/java/lib/libjavaplugin_oji.so

    System error?:: No such file or directory

    where directory is the user's default directory. This problem has been fixed.
  • Previously, the Plug-in for Netscape 4.x browsers would fail to load if the NPX_PLUGIN_PATH environment variable included a trailing slash.
    The following error was displayed:

    Plugin: couldn't read directory /usr/opt/java131/jre/plugin/lib/
    Exec of /usr/opt/java131/jre/plugin/bin/alpha/native_threads/java_vm failed: 2
    Plugin: Plugin is not enabled or Java VM process has died.


    The restriction that the NPX_PLUGIN_PATH environment variable could not end in a trailing slash has been removed.

Problems Fixed in SDK v 1.3.1-3

SDK v 1.3.1-3 was based on Sun’s J2SDK 1.3.1_03 Solaris Reference Release.

  • Previously, the Fast VM erroneously blocked the SIGTERM signal for threads it created; hence, java.lang.Process.destroy(), or other application functionality that relied on receiving SIGTERM signals, might not work as expected. This has been corrected in this release.

  • A correction was made to the Alt key when using the CDE or Motif window managers, so it now works as expected.

  • Previously, the text for some AWT components was not displayed correctly when using Chinese Big 5 fonts. This problem has been corrected in this release.

Problems Fixed in SDK v 1.3.1-2

SDK v 1.3.1-2 was based on Sun’s J2SDK 1.3.1_01 Solaris Reference Release.

  • When running in the Fast VM, a thread would hang if it attempted to close a socket on which another thread had a read operation pending. This has been fixed in this release.

  • If a garbage collection is triggered when exception handling is in progress, and the heap contains a very deeply nested object tree (more than about 50 levels), memory corruption may occur. This occurs only with the default "copying" garbage collector. It is extremely rare, but can result in a crash or hang in later execution. This has been corrected in this release.

  • This release provides a modified font.properties.ko file, which correctly displays Korean characters when the locale is set to Korean.

  • The Fast VM did not correctly recognize the JNI_CreateJavaVM options for specifying abort, exit, or vfprintf hooks. Also, the Fast VM would not accept the Java 1.1 form of the initialization argument (JDK1_1InitArgs) to JNI_CreateJavaVM. These problems have both been fixed in this release.

  • On Tru64 UNIX systems with small swap files, when the Fast VM was started up, the message "Unable to obtain requested swap space" was sometimes reported, even though the Fast VM would successfully run. This has been corrected in this release.

  • Using the -taso option with the Fast VM could sometimes result in an "Assertion failed" message and termination of the Java image. This has been corrected in this release.

  • In v 1.3.1-1, the JTextArea component would hang when using CTRL C to cut text. This problem has been fixed.

Problems Fixed in SDK v 1.3.1-1

SDK v 1.3.1-1 was based on Sun’s J2SDK 1.3.1_01 Solaris Reference Release.

  • Previously, when you started the Plug-in on Tru64 UNIX using a Netscape browser, Netscape popped up a "subprocess diagnostics" window with the text "No more modules." After you pressed the OK button, everything loaded normally. In SDK v 1.3.1-1, this "subprocess diagnostics" window no longers appears.


  • In SDK v 1.3.0, the Date class would return timezones in a GMT format. It would also have incorrect daylight saving time results. This has been corrected in SDK v 1.3.1-1 so that the correct time and timezone are displayed. If, however, you still receive the time in a GMT format, set the TZ environment variable to one of the values contained in /usr/opt/java131/jre/lib/tzmappings.

  • Previously, problems existed with several of the Chinese locales; this has been corrected, and Chinese characters now display correctly in AWT and Swing components.

  • Japanese characters display correctly in all AWT and Swing components.

  • Previously, a syntax error "fi statement is not correct" occurred when attempting to display some Japanese characters. This problem was due to French characters in the .java_wrapper script and has been corrected.

  • Occasionally seg faults would occur when using JPDA. This problem has been corrected.

  • When using the eXcursion window manager, window decorations would sometimes persist, such as when displaying a splash screen. This has been corrected.

  • Certain numeric keypad keys did not work when using the eXcursion window manager or DIGITAL keyboards. Keys "/", "*", "-", "+", "Home", and "End" now work correctly. These keyboard problems did not exist for PC keyboards when using CDE or Motif.

Compatibility

SDK v 1.3.1 is compatible with previous versions of the SDK. Most existing programs will run on the SDK v 1.3.1 platform. However, some important incompatibilities do exist and are thoroughly discussed in Sun's Java 2 Platform v1.3 Compatibility with Previous Releases document. For specific J2SDK v 1.3.1 incompatibilities refer to the section, Incompatibilities in the Java 2 Platform, Standard Edition, v1.3.

The default VM, the Fast VM, uses more memory than the classic VM; therefore, in SDK v 1.3.1, you might need to adjust your quotas or heap size. Refer to Memory Usage for more information.

The Fast VM does not support the Java Platform Debugger Architecture (JPDA). If you try to debug an application with any debugger that uses the JPDA interface such as jdb, you will see a message stating that the Fast VM does not support JPDA and debugging will continue using the classic VM.

Installation

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

Tru64 UNIX Patches

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

Presently, the SDK v 1.3.1 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 the product page on our Web site for the latest information.

Installing the Kit

With SDK v 1.1.7B and previous versions, you could install only one SDK version on a system. With later versions, you can install and use multiple versions on one system. In addition, you can change the default system Java environment version, which is the version located in /usr/bin.

When you install the SDK v 1.3.1 kit on your system, all files are installed in directories under /usr/opt/java131. In most cases, SDK v 1.3.1 is not installed as the default system Java environment version, and you need to take special actions to use SDK v 1.3.1 after it is installed. See Using SDK v 1.3.1. If you want to change the default system Java environment version, see Making SDK v 1.3.1 the Default System Java environment version.

NOTE

SDK v 1.3.1 is available from our Software Download page and is also bundled with some versions of the 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 4. For additional information about installing the SDK during the Tru64 UNIX installation, see the Tru64 UNIX Installation Guide.

To install, perform the following steps as superuser:

  1. If you want to deinstall prior versions, see Deinstalling Other Versions.
     
     
  2. Download the following binary kit:
       java131-8.tar 
  3. Untar it into a scratch directory, /tmp/java, for example:
       cd /tmp/java 
       tar xf /tmp/java/java131-8.tar

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

       copyright.html 
       license.html
       release_notes.html
  4. Use the setld command to load from that scratch directory:
       setld -l /tmp/java 
    

    There are three subsets that you can install:
     

    • JAVA131 - The mandatory subset, which provides support for running Java programs and applets.
       
    • JAVADEV131 - The development environment, which allows you to compile and debug Java code.
       
    • JAVADOC131 - The documentation subset.

    HP recommends installing all three subsets if you intend to use the SDK in a development capacity.

    Tru64 UNIX Subset Names

    The Software Download page uses the subset names listed in Step 4. However, if SDK v 1.3.1 has been installed as part of the 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.3.1, you must first deinstall these subsets. See Deinstalling Other Versions for instructions.

     

  5. Once you have installed the desired subsets, you can delete the scratch directory unless you also download the API reference documentation.

Installing the API Reference Documentation

You can also download and install the API reference documentation for SDK v 1.3.1. Allow 105 MB of disk space for the installed API reference files.

To install, perform the following steps as superuser:

  1. Download the following binary kit:
    javaapidoc131-8.tar
  2. Untar it into a different scratch directory from the one you used for the software kit, for example /tmp/java/api:
    cd /tmp/java/api
    tar xf /tmp/java/api/javaapidoc131-8.tar
  3. Use the setld command to load from that scratch directory:
    setld -l  /tmp/java/api

    There is only one subset that you can install:

         JAVAAPIDOC131 - The API documentation

    Browse the documentation using the following location:

       /usr/opt/java131/docs/api/index.html
  4. Once you have installed the desired subsets, you can delete the scratch directory.

Determining Your Installed Version

After you have installed SDK v 1.3.1, the /usr/opt/java131/bin/java -version command should display the following for this kit:

  % /usr/opt/java131/bin/java -version 
    java version "1.3.1" 
    Java(TM) 2 Runtime Environment, Standard Edition 
    Fast VM (build 1.3.1-8, native threads, mixed mode, ...)

Deinstalling the SDK v 1.3.1 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.3.1 subsets are installed. For example:
       setld -i | grep JAVA | grep 131 | grep installed 
    
  2. To delete subsets, enter the setld -d command. For example,
       setld -d JAVA131 JAVADEV131 JAVADOC131 JAVAAPIDOC131
    

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 
   JAVA122     installed     Java 1.2.2-12  Environment (General Applications) 
   JAVADEV122  installed     Java 1.2.2-12  Development Environment 
   JAVADOC122  installed     Java 1.2.2-12  Online Documentation 
 
   % setld -d JAVA122 JAVADEV122 JAVADOC122

Making SDK v 1.3.1 the Default System Java Environment Version

Note: Use caution when changing the default system Java environment to SDK v 1.3.1 for the following reasons:

  • If you run applications on your system that depend on SDK v 1.1.n being the default system Java environment version, they may not execute properly.
     
  • Tru64 UNIX V5.0A includes some Java-based tools that depend on the Java environment version that ships with the operating system and is installed in /usr/bin. If you change the default system Java environment version, some operating system tools, such as the SysMan Station, the SysMan Station authentication daemon, and the Logical Storage Manager (LSM) Storage Administrator, will not work correctly. Starting with Tru64 UNIX V5.1, these tools are not affected by the user changing the default version.

See Using SDK v 1.3.1 for more information on using SDK v 1.3.1 when it is not the default system Java environment version.

When you make SDK v 1.3.1 the default system Java environment version, system files such as /usr/bin/java are modified so that SDK v 1.3.1 is used whenever Java commands are entered. If a default system Java environment version is not found during installation, SDK v 1.3.1 is installed as the default system Java environment version. Otherwise, perform the following steps as superuser to make SDK v 1.3.1 the default system Java environment version:

  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 system Java environment version
                                #       is executed.
  2. Unset the default system Java environment version:
     
    • If Step 1 resulted in a "command not found" message, there is no default system Java environment version and nothing needs to be removed. Proceed to Step 3.
       
    • If SDK v 1.1.7B or a previous version is the default system Java environment version and no one on your system needs it, deinstall the old default system Java environment version (see Deinstalling Other Versions). Proceed to Step 3.
       
    • If a version later than SDK v 1.1.7B, such as SDK v 1.1.8, is the default, do the following to unset it as the default:
         /usr/opt/java118/bin/unset_java_default.sh

      After invoking this command, SDK v 1.1.8 still exists on the system but is no longer the default system Java environment version.

  3. Set the default system Java environment version to SDK v 1.3.1:
       /usr/opt/java131/bin/set_java_default.sh
    
  4. Verify that SDK v 1.3.1 is now the default version:
      % /usr/bin/java  -version 
        java version "1.3.1" 
        Java(TM) 2 Runtime Environment, Standard Edition 
        Fast VM (build 1.3.1-8, native threads, mixed mode, ...)
    

To switch the default system Java environment version from SDK v 1.3.1 back to SDK v 1.1.8, use the following commands:

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

Troubleshooting Multiple Versions

If you have multiple Java environment versions installed on your system and have trouble 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 to insure that PATH is set properly. See Changing Your PATH to Use SDK v 1.3.1.

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.

Development Tools

(In the bin subdirectory.) 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.

Run Time Environment (RTE)

(In the jre subdirectory.) 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.

Additional libraries

(In the lib subdirectory.) Additional class libraries and support files required by the development tools.

Demo Applets and Applications

(In the demo subdirectory.) Examples, with source code, of programming for the Java platform. These include examples that use Swing and other Java Foundation Classes. The demos are installed in the following directory:

   /usr/opt/java131/demo

C header Files

(In the include subdirectory.) Header files that support native-code programming using the Java Native Interface and the Java Virtual Machine Debugger Interface, as described on the Sun site.

Source Code

(In src.jar archive file.) 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.jar 

Do not modify core API source files. To extend the behavior of the core API, write subclasses of the core API classes.

For core API documentation, refer to the following sources:

  • The Java Platform API Specification:

    This document provides brief descriptions of the API with an emphasis on specifications, not on examples.

  • The Java Class Libraries, Second Edition, published by Addison-Wesley Longman as part of The Java Series, as described on Sun's site. These volumes include much more elaborate descriptions, with definitions of terminology and examples for practically every class, interface, and member.

Known Issues

This section provides descriptions of the known issues and limitations in the SDK; they include the following:

  • When using a 16-bit Elsa Gloria graphics card, fonts may not appear at all on Swing components. Also, colors may not be represented correctly in Swing components. By turning off DoubleBuffering, the fonts display correctly. To do this, add the following line to your program:

       RepaintManager.currentManager(frame).setDoubleBufferingEnabled(false);

    where "frame" is the JFrame component in your application. This problem does not occur when using 8-bit or 24-bit graphics. Another workaround is to set the graphics card back to 8-bit graphics, which will cause the fonts and colors to display properly.

  • The -hotspot option is silently ignored, and the -Xincgc option is not supported. This tuning option is specific to Sun's HotSpot™ virtual machine. For more information refer to Restrictions.

  • Starting with SDK v 1.3.0-1, the SDK contains better graphic performance than previous SDK v 1.2.2 releases. However, some graphics operations remain slower in the releases beginning with SDK v 1.3.0-1 than they do in SDK v 1.1.n releases.

With Java 2, Sun changed the underlying architecture of the graphics subsystem. In Sun's JDK V1.1.n, more of the graphics operations were done using native code. For example, the drawLine() method would result in a call to XDrawLine. With Java 2, the rendering of graphics has been moved to Java code, which computes the image and sends the pixels out to the display. As a result, the performance of graphical operations can be slower with J2SDK v 1.3.1, particularly when displaying to a remote machine.

Consequently, the slow performance that you see with some graphics operations is not specific to the SDK, but is inherent in the architecture of Java 2.

Sun has received a number of bug reports on this performance problem. For example, see the following list of bug reports in the Bug Database at Sun's Java Developer web site: 4204845, 4185726, 4217446, and 4210230. Once you have logged in (you must register, but it is free), follow the link to the Bug Database.

  • Java Sound is not supported. The following error is reported if you attempt to use Java Sound:
       Java Sound support not currently available
  • The HotJava browser provided by Sun is not designed to work with Java 2 SDK.

  • If you encounter problems regarding fonts when running your Java application, see the Font Support section that appears later in these release notes.

  • The Fast VM does not support the Java Platform Debugger Architecture (JPDA). See Compatibility for further information.

  • If you use an OpenVMS keyboard (LK461) with CDE or Motif as the window manager, the Delete key will delete to the right when you edit text inside a TextField or TextArea, instead of the expected behavior of deleting to the left. This problem will not be fixed. Newer PC keyboards have Backspace and Delete keys; the Backspace key will delete to the left, and the Delete key will delete to the right. The PC keyboard behavior has been preserved.

  • The java.awt.font.TextLayout.getBounds() may return invalid height and width values.

Using the SDK on Tru64 UNIX Systems

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

Using SDK v 1.3.1

In most cases, SDK v 1.3.1 is not installed as the default system Java environment version (See Installing the Kit.). As a result, you must do one of the following to use SDK v 1.3.1:

Changing Your PATH to Use SDK v 1.3.1

If SDK v 1.3.1 is not the default system Java environment version, you can conveniently use SDK v 1.3.1 by changing the PATH environment variable as follows:

  1. Place the directory, /usr/opt/java131/bin, first in your PATH so that it is searched before the system directories. Directory /usr/opt/java131/bin contains the SDK v 1.3.1 executables. For example, using csh(1):
       setenv PATH /usr/opt/java131/bin:$PATH
  2. Verify that you are using SDK version 1.3.1:
      % java  -version
        java version "1.3.1"
        Java(TM) 2 Runtime Environment, Standard Edition
        Fast VM (build 1.3.1-8, native threads, mixed mode, ...)

To stop using SDK v 1.3.1, remove /usr/opt/java131/bin from your PATH.

Note: If you are using Tru64 UNIX V5.0A, you must remove /usr/opt/java131/bin from your PATH when using some Java-based tools that ship with the operating system. These tools, including the SysMan Station, the SysMan Station authentication daemon, and the Logical Storage Manager (LSM) Storage Administrator, depend on the Java environment version that ships with the operating system and is installed in /usr/bin. These tools will not work correctly if a different Java environment version is used due to your PATH definition.

Selecting the VM

As noted in the Introduction, this kit contains two virtual machines. The following sections describe how to control which virtual machine your application uses.

VM Options

SDK v 1.3.1 lets you control which virtual machine your application uses, based on the following options:

Option

Function

-fast, -fast32 -fast and -fast32 perform the same operation. This is the default option and instructs the java command to use the Fast VM, using 32-bits to store pointers into objects.
-fast64 Instructs the Fast VM to use 64-bits for pointers.
-classic Directs the java command to use the classic virtual machine (classic VM, the virtual machine shipped with prior releases). The classic VM is based on Sun's reference implementation.

Using the Classic VM with Java 2 Development Tools

By default, the Fast VM is used when running the Java 2 development tools (for example, javac, javadoc, javap, jar, appletviewer, and so on). You can also use the classic VM by specifying the -classic option when you invoke the tool. For example, the following command uses the classic VM when running the appletviewer:

appletviewer -classic runtest.html

The Classic VM Environment Variable

You can also use the classic VM by defining the environment variable JAVA_CLASSIC_VM. If this environment variable is defined, the classic VM is always used when the java command or the Java tools are invoked even if -classic is not specified.

The Fast VM 64-bit Addressing Environment Variable

To use the Fast VM (with 64-bit pointers), you can define the new environment variable JAVA_FAST64_VM. If you do not define this environment variable, by default the Fast VM is invoked in 32-bit mode.

Setting both environment variables, JAVA_CLASSIC_VM and JAVA_FAST64_VM, invokes the Fast VM in 64-bit mode. Note that using  a 'java' command line option overrides the setting of a Java virtual machine environment variable.

If you neither set an environment variable nor specify a command line option, the Fast VM with 32-bit pointers is invoked by default.

Command Line Options

Standard Options

The java command supports all standard options, as described on Sun's site. SDK v 1.3.1 includes the Fast VM, which is designed for high performance on Tru64 UNIX Alpha systems rather than Sun's HotSpot virtual machine. The -hotspot standard option is silently ignored. For more information, refer to Restrictions.

Non-Standard Options

By default, the java command supports most non-standard options, as described on Sun's site. The following options are supported by the classic VM and not by the Fast VM: -Xdebug, -Xnoclassgc, and -Xrunhprof. If your application uses one of these options, you must use the classic VM by specifying the -classic option. -Xprof is not supported; however, -Xrunhprof is available for classic VM profiling.

Additional Options

In addition to Sun's options, the java command supports the following options:

Option

Function

-fast, -fast32 -fast and -fast32 perform the same operation. This is the default option and instructs the java command to use the Fast VM, using 32-bits to store pointers into objects.
-fast64 Instructs the Fast VM to use 64-bits for pointers.
-taso Load the executable in 31-bit addressable address range.
-client Initializes the Fast VM with a maximum heap size of 64 MB, a maximum global region size of 128 MB and the compacting collector. Refer to Reducing Fast VM Memory Requirements for Workstations and Client-side Applications for more information.
-Xglobal<size> Specifies the global region maximum allocation size. The global region contains class definitions, string constants, and other data internal to the VM. -Xglobal can be used to override the default size of 240 MB or the -client setting of 128 MB. Refer to Reducing Fast VM Memory Requirements for Workstations and Client-side Applications for more information.
-Xgc:compacting Instructs the Fast VM to use the alternative compacting garbage collector, which compacts live data in-place, rather than copying it as the default collector does. This collector is a hybrid mark-sweep/mark-compact collector, which will avoid moving data when it is not necessary. (See also Dynamic Heap Management.)
-Xgc:copying Instructs the Fast VM to use the default "copying" garbage collector.
-Xmp When used with the compacting garbage collector, this specifies the minimum percentage of heap space that the collector should try to free for new objects. Thus, it dictates when a full compaction must occur, rather than a sweep or minor compaction. Values from 0 to 100 may be specified in the form -Xmpnn, for example, -Xmp25. The default value is 25.

Tuning and Performance

Refer to the following sections (Memory Usage, Reducing Fast VM Memory Requirements for Workstations and Client-side Applications, Dynamic Heap Management, Controlling Stack Size, Using the Fast VM for Applications Requiring a Large Virtual Address Space, Applications Using a Large Number of Threads, and Swap Space Problems) for specific tuning and performance information.

Memory Usage

The Fast VM has been tuned for large memory systems and, in addition, a number of tradeoffs have been made that favor speed of execution over memory usage. As a result, the Fast VM uses more physical and virtual memory for the same application, often as much as 50% more. This can lead to excessive paging and degraded performance if the system is not tuned correctly or if there is insufficient physical memory on the system. If you notice that your application runs more slowly with the Fast VM than with the classic JIT, you should do the following:

  • Experiment with explicit -Xmx and -Xms values rather than letting the Fast VM pick the defaults. (See Dynamic Heap Management.)
  • Increase process quotas based on the amount of available physical memory.
  • Add physical memory.

Note that a smaller heap that results in more garbage collections is preferable to allowing your application to page fault too often due to a large heap size. For more information on system tuning and resource limits, see the following:

Reducing Fast VM Memory Requirements for Workstations and Client-side Applications

The Fast VM is optimized for large, long-running programs running on server systems. Many users would like to use the Fast VM on their workstations for client-side applications; however, some of these systems do not have the resources to start up the Fast VM with its default configuration. A -client switch addresses these needs.

The client configuration significantly reduces the Fast VM memory footprint.

The -client switch is a convenience switch, analogous to setting the following switches on a command line:

java -Xmx64m -Xglobal28m -Xgc:compacting

The individual switch settings that make up the -client switch can be overridden. For example:

java -client -Xmx256m

will initialize the Fast VM with a maximum heap size of 256 MB, with a maximum global region size of 128 MB, and with the compacting collector.

Dynamic Heap Management

Rather than use fixed values for the default settings for the memory allocation pool (Java heap), the Fast VM determines the defaults for the initial heap size (-Xms) and the maximum heap size (-Xmx) dynamically based on the environment in which it is executing as shown below:

max_memory = min (physical memory on machine, total memory available to the process)

default initial heap size = 10% of max_memory 

default maximum heap size = 60% of max_memory

By setting heap size defaults automatically, the Fast VM adjusts the heap size based on the available amount of memory. This generally produces better results than specifying fixed -Xmx and -Xms values, especially for an application that is executed on different systems with varying amounts of memory. It is sometimes possible to obtain better results by specifying -Xmx and -Xms rather than letting the Fast VM pick the defaults. To determine what values to use you should use the -verbosegc command line option to monitor your application's heap activity. If you notice that many garbage collections are occurring, increase the heap size as much as possible without causing excessive page faults. See Memory Usage for additional information.

-Xgc:compacting

The Fast VM supports an alternative compacting garbage collector, which compacts live data in-place, rather than copying it as the default collector does. This collector is a hybrid mark-sweep/mark-compact collector, which will avoid moving data when it is not necessary. You can use the -Xgc:compacting switch to enable the compacting garbage collector. This can significantly improve performance characteristics for applications with long-lived data. This is also a multi-threaded collector, so it can scale very well on multiprocessors.

Benefit: This collection scheme can have better performance characteristics and lower heap size requirements for applications in which the heap contains a high percentage of long-lived data. This collector can also perform minor collections, rather than collecting the entire heap, when the percentage of live data is moderate. It can also perform sweeps, which free space without moving any data at all. Thus, it may also provide performance advantages for certain applications with a moderate amount of long-lived data, but a high rate of short-lived object turnover.

To use the compacting collector, specify the  -Xgc:compacting  option on the command line. The  -Xgc:copying  option causes the Fast VM to use the default "copying" collector.

Controlling Stack Size

By default, the native stack size for Java threads on Tru64 UNIX systems is approximately 512 KB. You can increase or decrease the native stack size using the -Xssn command line switch. Note that decreasing the native thread stack size can save memory but can also result in stack overflow exceptions if the native thread stacks are too small.

Example:

   java -Xss256k MyApp 

Using the Fast VM for Applications Requiring a Large Virtual Address Space

By default, the Fast VM uses 32-bits to store pointers in objects, which limits the amount of virtual memory available to Java applications. With the default, the memory allocation pool (Java heap) is limited to about 3 GB. The Fast VM provides an option to use 64-bits for pointers, which significantly increases the amount of memory available to Java applications. To use the 64-bit option, specify java -fast64 or define the new environment variable JAVA_FAST64_VM.

Applications Using a Large Number of Threads

If you experience a "java.lang.OutOfMemoryError" when attempting to create a large number of threads, consider increasing the proc subsystem attribute, max_threads_per_user. This attribute allows you to increase the maximum number of threads that can be allocated at any one time to each user, except superuser.

The Tru64 UNIX Best Practice guide recommends the following:

The default value of the max_threads_per_user attribute is based on the value of the maxusers attribute, so you can increase the maximum number of threads by increasing the maxusers attribute. You can also explicitly increase the maximum number of threads by increasing the max_threads_per_user attribute.

Use a value that is equal to or greater than the maximum number of threads that are allocated at one time on the system. For example, you could increase the value of the max_threads_per_user attribute to 512. On a busy server with sufficient memory or an Internet server, increase the value of the max_threads_per_user attribute to 4096. If the value of the max_threads_per_user attribute is 0 (zero), there is no limit on threads; this is not recommended.

You must reboot the system to use the new value of max_threads_per_user.

Swap Space Problems

If you see one of the following messages:

"Unable to obtain requested swap space"
"swap space below 10 percent free"

your machine may be low on swap space and require some system tuning to correct the problem. Note that the Fast VM, which is the default, requires more memory than the classic VM, so you might not have received these messages in the past. You can reduce the Fast VM's memory requirements by using the -client option (see Reducing Fast VM Memory Requirements for Workstations and Client-side Applications), by using the -Xglobal<size> option to specify a smaller global region size, or by using the -Xmx<size> option to specify a smaller heap size. Another option is to use the classic VM by specifying -classic, which runs slower but requires less memory. Please see the Tru64 UNIX System Configuration and Tuning manual. For Tru64 UNIX V5.1B systems, the following sections may be helpful (similar sections would apply for other versions):

  • 4.4.1.8 Modifying the Swap Allocation Mode
  • 12.2 Configuring Swap Space for High Performance
  • 12.3.3 Displaying Swap Space Usage by Using the swapon Command

Creating a VM in C/C++ Programs Using the Invocation API

By default, this release supports the ability to create and invoke the Fast VM in C/C++ programs using the Invocation API. The Invocation API is an integral part of the Java Native Interface (JNI) that allows you to initialize virtual machine arguments, create, and load a virtual machine into your application, and then unload or destroy the virtual machine. For additional information about the Invocation API and how to use it, refer to the Sun JNI specification on Sun's site.

To take advantage of the Invocation API functionality, your C/C++ program (new and existing programs) must first create the virtual machine so that the Java code can be executed. Once the virtual machine is embedded into the program, the program can then load Java classes and execute Java methods. Assume that you have a C++ program called invokejvm.cxx: This program creates a virtual machine and then calls a Java method. The following is an example of a C++ command line that compiles and links a C++ program that invokes the Fast VM:

cxx -pthread \
  -I/usr/opt/java131/include \
  -I/usr/opt/java131/include/alpha \
    invokejvm.cxx \
    /usr/opt/java131/jre/lib/alpha/fast64/libjvm.so \
  -o invokejvm

Note that 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 multithreading problems, even if your Java and C/C++ code does not explicitly use threads. For more information about the  -pthread  flag, please see the C/C++ manpages.

Before running the resulting invokejvm, you must define LD_LIBRARY_PATH so that the following shared library directories are searched when loading the executable:

/usr/opt/java131/jre/lib/alpha/
/usr/opt/java131/jre/lib/alpha/fast64
/usr/opt/java131/jre/lib/alpha/native_threads

For example, you can do this using the following csh commands:

setenv JLIB /usr/opt/java131/jre/lib/alpha
setenv LD_LIBRARY_PATH ${JLIB}:${JLIB}/fast64:${JLIB}/native_threads

If your C or C++ main program is built with the -xtaso or -xtaso_short option to use 32-bit pointers, you should substitute fast32 for fast64 in the above cxx command line and LD_LIBRARY_PATH definition.

Using the Plug-in

Plug-in v 1.3.1 enables users to run Java applets and JavaBeans components on web pages using the RTE as an alternative to using the default Virtual Machine for Java 2 that comes with the web browser. It is based on the Java Plug-in 1.3.1 provided by Sun Microsystems and contains similar functionality.

For additional information on topics such as Java Plug-in security, using Signed Applets, JNI and the Java Plug-in, using the Java Plug-in in Intranet Environments, and how Proxy Configuration works in the Java Plug-in, please see the Sun Microsystems Java Plug-in 1.3 Documentation web site; the documentation is the same for Java Plug-in 1.3.1.

Note: You must be running Netscape Communicator 4.51 or higher, or Mozilla 0.7 or higher.

Installing the Plug-in

For Netscape 4.x browsers:

Set the NPX_PLUGIN_PATH environment variable to the location of the Plug-in (the directory in which the javaplugin.so file is located):

NPX_PLUGIN_PATH=/usr/opt/java131/jre/plugin/alpha/ns4

For Mozilla and Netscape 6.x browsers:

Create a symbolic link in the browser's plugins directory to the path of the libjavaplugin_oji.so file. This file is located at /usr/opt/java131/jre/plugin/alpha/ns600/libjavaplugin_oji.so.

For example:

cd ${MOZILLA}/plugins
ln -s /usr/opt/java131/jre/plugin/alpha/ns600/libjavaplugin_oji.so

Start your browser, or restart it if it is already running.

Restart your browser a second time. (This is a workaround to a browser bug.)

Converting Your HTML Pages

The Plug-in does not replace Navigator's underlying Virtual Machine for Java 2. Rather, it enables you to specify the use of the RTE instead of the default Navigator Virtual Machine for Java 2.

To use the Plug-in (instead of the browser's default Java environment version) when Netscape Navigator® browses a web page, you need to modify your web page source file(s). You can do this manually, using the OBJECT tag and the EMBED tag in your HTML specification. Alternatively, you can use the HTML Converter to automate modifications of your web page source files. For more information on HTML web page changes required by the Plug-in, see Sun's Java Plug-in HTML Specification.

The Plug-in HTML Converter

The HTML Converter easily and automatically modifies HTML pages to specify the use of the Plug-in rather than the browser's default Java runtime. The SDK v 1.3.1 kit provides the Plug-in HTML Converter so that a separate download is not required.

To run the GUI version of the HTML Converter, invoke the following command:

/usr/opt/java131/bin/HtmlConverter -gui

To run the command line version of the HTML converter, invoke the HTML Converter and specify the file to convert. For example:

/usr/opt/java131/bin/HtmlConverter file.html

For more information about the HTML Converter, see Sun's Java Plug-in HTML Converter Features and Sun's Plug-in HTML Converter Installation and Use web pages.

The Plug-in Control Panel

A Plug-in Control Panel lets you change Plug-in options such as proxies and enabling of the console window. It also allows you to switch the RTE version you want to run with your Plug-in. To run the Control Panel, enter the following command:

/usr/opt/java131/jre/bin/ControlPanel

Or you can use the Netscape Navigator browser to visit the Control Panel applet page that was installed as /usr/opt/java131/jre/bin/ControlPanel. For example:

netscape /usr/opt/java131/jre/ControlPanel.html

Some of the Control Panel features are discussed below. Please refer to Sun's Java Plug-In Control Panel web page for information about additional features and uses of the Java Plug-in Control Panel.

Selecting the VM to Use in the Plug-in

By default, the Fast VM is used when running the Plug-in. You can have the Plug-in use the classic VM by defining the environment variable JAVA_PLUGIN_CLASSIC_VM prior to running your web browser.

To use the Fast VM (with 64-bit pointers), you can define the environment variable JAVA_PLUGIN_FAST64_VM. If you do not define this environment variable, by default the Fast VM is invoked in 32-bit mode.

Setting both environment variables, JAVA_PLUGIN_CLASSIC_VM and JAVA_PLUGIN_FAST64_VM, invokes the Fast VM in 64-bit mode.

If you don't set an environment variable, the Fast VM with 32-bit pointers is invoked by default.

Viewing Tracing Information

You can view a moderate amount of Plug-in tracing information in Netscape Alert Panels by setting the JAVA_PLUGIN_TRACE environment variable. If you set JAVA_PLUGIN_TRACE and want the output to go to the standard output/error (usually your terminal window), edit the following lines in your .Xdefaults or .Xresources file in your home directory.

Change "True" to "False":

*useStderrDialog:  False
*useStdoutDIalog:  False

Then reload resources by typing the following command:

xrdb -merge .Xdefaults

Displaying Java Error Messages

To see Java error messages:

  1. Use the Plug-in Control Panel to enable the console window.
  2. Exit Netscape Navigator and then restart it.

With the console window enabled, when you next visit a Plug-in enabled page, a separate window will come up to display error messages.

Font Support

The SDK includes the following font support.

Role of the font.properties File

Starting with SDK v 1.2.1, Java applications require a font property file to properly display the application's AWT windowing and Java2D components. This file contains mappings of Java logical font names to physical fonts on the X server. With SDK v 1.3.1, a font.properties file is installed by this kit in jre/lib/font.properties, which identifies fonts that should be available on your X server.

If you prefer to use fonts other than those that have been predefined by the property file for your use, copy the file installed by this kit from jre/lib/font.properties to your $HOME directory and modify it. When a Java application is run, it will use your local font property file instead of the one installed by this kit.

Multiple font.properties Files Provided

It is difficult to supply a font.properties file that is ideal for use in all environments. As a result, this kit contains two font.properties files:

  • font.properties

    This is the default font.properties file and generally should work fine for displaying your application.

  • font.properties.rotation

    This alternate font.properties file has been modified for your use if your application uses Java2D features such as displaying rotated text. This file uses TrueType fonts supplied by Sun that ship with the Java 2 SDK. Not all of the fonts in this property file support the display of rotated text. Only the "SansSerif" and "Monospaced" font families were changed to use Sun's fonts.

    If your application displays text as rotated, you will need to follow a few simple steps in order to successfully use this Java2D feature. In your program, for all of the occurrences of text that you wish to display as rotated, you will need to call the setFont() method to change the font name for the text to "SansSerif" or to "Monospaced". Additionally, you will need to use this font property file on a user local or system-wide basis.

Both of the font property files shipped with SDK v 1.3.1 kit reside in /usr/opt/java131/jre/lib/. The one actually named font.properties is the one that will be used. This file is a system-wide file and is used for the display of all Java programs that are run on that system. The SDK supports local customizations of the font property file which can take affect on a user or system-wide basis. When the Java runtime needs to find a font.properties file, it starts its search in $HOME. A local version of the font.properties file takes precedence over a system-wide version. Therefore, you can make either of these two files your user local font.properties by copying the font.properties file of your choice to a file named font.properties in $HOME.

Alternatively, if you want to use the font.properties.rotation file as a system-wide file for use by all users on the system (thus overriding the default font.properties file), perform the following steps:

   % cp /usr/opt/java131/jre/lib/font.properties \ 
        /usr/opt/java131/jre/lib/font.properties.orig  
   
   % cp /usr/opt/java131/jre/lib/font.properties.rotation \ 
        /usr/opt/java131/jre/lib/font.properties  

If later you wish to revert to the original file that shipped with SDK v 1.3.1, you would copy font.properties.orig to font.properties.

If you prefer to use fonts other than those that have been predefined by the font properties file for your use, copy the file installed by this kit from /usr/opt/java131/jre/lib/font.properties to your $HOME directory and modify it. When a Java application is run, it will use your local font properties file instead of the one installed by this kit.

Retired Fonts

Starting with Tru64 UNIX V4.0F, all Adobe fonts under /usr/lib/X11/fonts/Type1Adobe are retired and no longer ship with the operating system.

If your Java application used 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.

Troubleshooting Font Problems

If you encounter one of the following warnings, you are probably referencing a font in your font.properties file that is not available on your system. Check your font path by issuing the UNIX command xset -q. If your display is not what you expect, you might need to change the search order. Also, make sure that the font property file does reference fonts that are installed on your system; you may be attempting to use a font that is not available.

   "Font specified in font.properties not found [-*-helvetica-bold-r-normal...]"

If you are having problems with fonts when you display remotely to a PC using eXcursion™, you might need to upgrade to a newer version of the eXcursion software and install additional fonts. Also, make sure that the font property file references fonts that are installed on your PC.

Screen Resolution Display Problems

Font display problems can occur when running Java applications and displaying to systems that use certain graphics cards. Specifically, the fonts will appear jagged due to improper scaling. This problem is typically seen on graphics cards that default to a screen resolution of 1024x768. For example, the PowerStorm 4D10T (also known as the ELSA Gloria Synergy) card has the problem. These cards typically support higher screen resolutions but default to a lower resolution to support smaller monitors.

There are two workarounds to this font scaling problem. Both involve editing the X Server configuration file /usr/var/X11/Xserver.conf, which contains startup information for the X Server. Note that on a Tru64 UNIX V5.x system, this file is a context-dependent symbolic link (CDSL). In a cluster environment, there exists one version of this file per cluster member. Be sure to make the edits on the appropriate cluster member or using an explicit path such as:

/usr/var/cluster/members/memberN/X11/Xserver.conf

where N is the appropropriate member number.

The two workarounds are:

  1. If the system has a monitor that supports a higher resolution such as 1280x1024, configure the X Server for this higher screen resolution as follows:
  • Edit the file /usr/var/X11/Xserver.conf and search for the following lines, which are typically at the bottom of the file:
  • ! you specify command line arguments here
    args <
            -pn
    >
  • Adjust the screen resolution by adding -screen 1280x1024 after the -pn option. For example:
            -pn -screen 1280x1024

Note that the -screen option can be specified as -screenN for multiheaded systems.

  • As superuser, stop and then restart the X Server so these changes will take effect:
    # /sbin/init.d/xlogin stop
    # /sbin/init.d/xlogin start
  1. Tell the X Server to use either 100 dpi or 75 dpi fonts explicitly. For example, by default, a 1024x768 monitor is configured to use 75 dpi fonts. Tell the X Server to operate at 75 explicitly:
  • Edit the file /usr/var/X11/Xserver.conf and search for the following lines, which are typically at the bottom of the file:
    ! you specify command line arguments here
    args <
            -pn
    >
  • Add -dpi 75 after the -pn option. For example:
            -pn -dpi 75

Typically, 75 dpi is a good choice for monitors with a resolution of 1024x768. If you would like the fonts to be uniformly larger, use 100 dpi fonts by specifying -dpi 100.

For more detailed information on changing X Server screen settings, refer to section "Adjusting Your Screen Settings" of the Tru64 UNIX Best Practice guide.

Window Managers Supported by the SDK

The CDE desktop window manager (dtwm), and the Motif window manager (mwm), are fully supported. You may also use the DIGITAL eXcursion™ window manager when running your Java application on a Tru64 UNIX system and redirecting the display back to a PC.

Non-standard window managers such as fvwm and twm are not supported. Therefore, you may experience some unusual behavior when using them.

Restrictions

  • The SDK v 1.3.1 kit does not include support for Sun's HotSpot™ virtual machine.


  • Native methods used with the Fast VM must conform to the Java Native Interface (JNI) specification, as described on Sun's site. The Fast VM does not support native method conventions older than the JNI specification.

Documentation and Other Information

Documentation

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

   /usr/opt/java131/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).

Note: The documentation in JAVADOC131 does not include the API reference documentation. If you want to use the API reference documentation locally, download and install the separate javaapidoc131-8.tar file as described in the Installation section. Browse the API documentation using the following location:

   /usr/opt/java131/docs/api/index.html

Also, you can browse the Software Documentation page on our Web site.

There is also 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 Java environment version that was shipped; the manpage is not updated by this kit.

More Information

For more information on this release, refer to the Release Notes for the J2SDK v 1.3.1 software from Sun Microsystems, and our Frequently Asked Questions (FAQ) web page.

If you are new to the Java programming language, you will want to browse or download the Java Tutorial on Sun's site.

Problem Reporting

To report problems, refer to our Software Support web page.

 

© 2001, 2004, 2007 Hewlett-Packard Development Company, L.P.

Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.

The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation.

Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

Printed in the US

Privacy statement Using this site means you accept its terms Feedback to Webmaster
© 2007 Hewlett-Packard Development Company, L.P.