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

Release Notes

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

for the Java™ Platform

Content starts here

Contents

Back to top
Introduction

Thank you for downloading the Software Development Kit (SDK) v 1.4.1-3 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).

The SDK v 1.4.1-3 kit implements the J2SDK v 1.4.1, and is based on Sun's J2SDK 1.4.1_07 Solaris Reference Release. It passes all the tests in Sun's Java Compatibility Kit test suite (JCK V1.4a). Use the java -version command to check the version of the SDK that you are using.

This kit 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.

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

Back to top
New Features

The following sections briefly describe the new features HP has included in SDK v 1.4.1. The Java™ 2 Platform, Standard Edition, v 1.4.1 has reached End of Life (EOL). Refer to Sun's Java™ 2 SDK, Standard Edition Documentation Version 1.4.1 archive page for a description of the features and enhancements in the J2SDK v 1.4.1.

SDK v 1.4.1-3 New Features

This kit installs SDK v 1.4.1-3, which is a maintenance release with the following new features from HP.

New Fast VM Options:

  • When using the Fast VM, the java command now supports the -Xdynclassgc option. This option instructs the Fast VM to garbage collect the class data for dynamically generated classes when those classes are no longer used. By default, the Fast VM garbage collects only heap objects, not class data structures. For more information, refer to Garbage Collection of Class Data for Dynamically Generated Classes.

  • The option, -Xcode<size>, which allows a larger code region for code generated by the Fast VM, has been added in this release. Size is the code region maximum allocation size in bytes. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. You can specify values between 24M and 128M. The default value is -Xcode24M.

SDK v 1.4.1-2 New Features

SDK v 1.4.1-2 was a maintenance release with no new features from HP.
Note: Precompiled standard class files are no longer available with this kit.

SDK v 1.4.1-1 New Features

SDK v 1.4.1-1 was a maintenance release with no new features from HP.
Note: Precompiled standard class files are no longer available with this kit.

Back to top
Fixed Problems

The following sections provide important information about problems that HP has fixed in SDK v 1.4.1. Refer to Java™ 2 SDK, Standard Edition Documentation Version 1.4.1 on Sun's site for information concerning their bug fixes.

Problems Fixed in SDK v 1.4.1-3

SDK v 1.4.1-3 is based on Sun Microsystem's J2SDK 1.4.1_07 Solaris Reference Release and contains the following fixed problem from HP:

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

  • Memory leaks in Fast VM garbage collection have been corrected.

  • The Fast VM now supports the Java system property java.endorsed.dirs. This property is not available when using the classic VM.

  • Previously, printing from a Java application could result in a Not accepting jobs status. This problem 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.

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

  • Java programs previously, would sometimes fail with the message GC: failure in slave threads, file .... This has been corrected.

  • Beginning in 1.4.1-2, the Fast VM could fail as follows when compiling a method:

    Assertion failed: !bvec_contains(enqueued, next), file /vobs/JavaGroup/Products/Java/J2SDK/fastvm/srcjava/runtime/typeinfo.c, line 187

    This problem has been fixed.

Problems Fixed in SDK v 1.4.1-2

SDK v 1.4.1-2 was based on Sun Microsystem's J2SDK 1.4.1_03 Solaris Reference Release and contains the following fixed problems from HP:

  • This release provides a modified /usr/opt/java141/jre/lib/font.properties.th file that supports the proper displaying of Thai characters using the Thai locales "th_TH" and "th_TH.TACTIS". This supports displaying both Swing and AWT components.
  • This release has added support for converting lock initialization to "shared" rather than "private" if a very high rate of lock conversion (private=>shared) is detected. This release has also added -Xlock:{private|shared} options for overriding the default. For more information, see Fast VM Lock Initialization Options.

  • The native stack size for Java threads has been increased to approximately 512 KB.
  • In SDK v 1.4.1-1, the jre/lib/security/cacerts file was empty. Root certificates are now provided in the file.
  • Previously, on rare occasions, faulty execution could have occurred in programs running dynamically generated class methods. The program would fail with a exception message stating that there were multiple internal errors. This problem has been fixed.
  • Previously, the method sun.awt.font.NativeFontWrapper.getFontPath() would return a string with an incorrect directory name. This has been corrected.

Problems Fixed in SDK v 1.4.1-1

SDK v 1.4.1-1 was based on Sun Microsystem's J2SDK 1.4.1_01 Solaris Reference Release and contained the following fixed problem from HP:

  • Under rare conditions, the Fast VM's Compacting Garbage Collector could report Internal error 2 in compacting GC or trigger a SEGV exception. The problem was fixed in this release.

Back to top
Compatibility

SDK v 1.4.1 is compatible with previous versions of the SDK. Most existing programs will run on the SDK v 1.4.1 platform. However, some important incompatibilities do exist and are discussed in Sun's Java 2 Platform Compatibility with Previous Releases document.

The default VM, the Fast VM, uses more memory than the classic VM; therefore, in SDK v 1.4.1, you might need to adjust your limits 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.

Back to top
Installation

The following sections describe how to install the SDK v 1.4.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.4.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 our product page 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.4.1 kit on your system, all files are installed in directories under /usr/opt/java141. In most cases, SDK v 1.4.1 is not installed as the default system Java environment version, and you need to take special actions to use SDK v 1.4.1 after it is installed. See Using SDK v 1.4.1. If you want to change the default system Java environment version, see Making SDK v 1.4.1 the Default System Java Environment Version.

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:
       java141-3.tar
  3. Untar it into a scratch directory, /tmp/java, for example:
       cd /tmp/java 
       tar xf /tmp/java/java141-3.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 
    

    Of the following subsets that you can install, HP recommends installing all three if you intend to use the SDK in a development capacity:

    Subset

    Function

    JAVA141

    This mandatory subset provides support for running Java programs and applets.

    JAVADEV141

    This development environment allows you to compile and debug Java code.

    JAVADOC141

    This is the documentation subset.


  5. Once you have installed the desired subsets, you can delete the scratch directories.

Installing the API Reference Documentation

You can also download and install the API reference documentation for SDK v 1.4.1. Allow 155 MB of disk space for the installed API reference files. Note: A subset of the full API specification is provided on the kit as a convenience. If you encounter broken links, refer to the Java 2 Platform, Standard Edition, v 1.4.1 API Specification on Sun's site.
 

  1. Download the following binary kit:
    javaapidoc141-3.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/javaapidoc141-3.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:

        JAVAAPIDOC141 - The API documentation

    Browse the documentation using the following location:

    /usr/opt/java141/docs/api/index.html (frames)
    /usr/opt/java141/docs/api/overview-summary.html (no frames)

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

Installing Java Web Start

With Java Web Start, an application-deployment technology bundled with SDK v 1.4.1, you can launch applications by clicking on a Web page link. If the application is not on your computer, Java Web Start automatically downloads all necessary files. It then caches the files on your computer so the application is always ready to be relaunched. For more information, refer to Java Web Start on Sun's site.

Included with SDK v 1.4.1, javaws-1_2_0_01-unix-alpha-i.zip contains Java Web Start. To install Java Web Start:

  1. Copy javaws-1_2_0_01-unix-alpha-i.zip to a local directory (preferably outside the SDK directory) using commands like the following:
        cd ~
        cp /usr/opt/java141/jre/javaws-1_2_0_01-unix-alpha-i.zip.
  2. Unzip the file and run the extracted install.sh script:
    unzip javaws-1_2_0_01-unix-alpha-i.zip
    ./install.sh

Determining Your Installed Version

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

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

Deinstalling the SDK v 1.4.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.4.1 subsets are installed. For example:
       setld -i | grep JAVA | grep 141 | grep installed 
    
  2. To delete subsets, enter the setld -d command. For example,
       setld -d JAVA141 JAVADEV141 JAVADOC141 JAVAAPIDOC141
    

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 
   JAVA131     installed     Java 1.3.1-5  Environment (General Applications) 
   JAVADEV131  installed     Java 1.3.1-5  Development Environment 
   JAVADOC131  installed     Java 1.3.1-5  Online Documentation 

   % setld -d JAVA131 JAVADEV131 JAVADOC131

Making SDK v 1.4.1 the Default System Java Environment Version

Note: Use caution when changing the default system Java environment version to SDK v 1.4.1 for the following reason. 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.

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

When you make SDK v 1.4.1 the default system Java environment version, system files such as /usr/bin/java are modified so that SDK v 1.4.1 is used whenever Java commands are entered. If a default system Java environment version is not found during installation, SDK v 1.4.1 is installed as the default system Java environment version. Otherwise, perform the following steps as superuser to make SDK v 1.4.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 ensure 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.4.1:
       /usr/opt/java141/bin/set_java_default.sh
    
  1. Verify that SDK v 1.4.1 is now the default version:
      % /usr/bin/java  -version 
        java version "1.4.1" 
        Java(TM) 2 Runtime Environment, Standard Edition 
        Fast VM (build 1.4.1-3, native threads, mixed mode, ...)
    

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

   /usr/opt/java141/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 environment version on system 

Then check your definitions of PATH and CLASSPATH:

   printenv PATH
   printenv CLASSPATH

If you encounter the error "java: Permission denied", check to ensure that PATH is set properly. See Changing Your PATH to Use SDK v 1.4.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/java141/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.zip 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.zip

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:

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

Back to top
Known Issues

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

  • Java Networking IPv6 support, as defined in Sun's Networking IPv6 User Guide for J2SDK/JRE 1.4 requires SDK v 1.4.1 and higher and Tru64 UNIX V5.1B and higher.

    Partial IPv6 support is available with this SDK release on Tru64 UNIX V5.1A. However, you must explicitly specify the property -Djava.net.preferIPv6Addresses=true on your java command if you want to use Java Networking IPv6 support when running on these operating system versions.

    Note that even after specifying the property -Djava.net.preferIPv6Addresses=true, you may encounter problems with IPv4 mapped multicast addresses on IPv6 sockets when running on the Tru64 UNIX V5.1A release.

  • When displaying graphics-intensive Java applications on remote host displays (via TCP/IP), setting the Java property sun.java2d.pmoffscreen to false may significantly increase the application's graphics performance. This property is set via the Java command line, e.g.,

    -Dsun.java2d.pmoffscreen=false

    For further information, see Sun's High Performance Graphics, specifically, the "Runtime Flag for Solaris and Linux" section.

  • When using -Xdebug to start an application with the debugger enabled, use the -Djava.compiler=NONE option to disable the JIT compiler. Otherwise, you will experience fatal errors when trying to connect remotely with jdb. For example,

    % java -classic -Xdebug -Djava.compiler=NONE
    -Xrunjdwp:transport=dt_socket,server=y,address=8000 mytest &

    % jdb -attach 8000

Back to top
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.4.1

In most cases, SDK v 1.4.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.4.1:

Changing Your PATH to Use SDK v 1.4.1

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

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

To stop using SDK v 1.4.1, remove /usr/opt/java141/bin from your PATH.

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.4.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, define the 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.4.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 HotSpot Virtual Machine in Functionalities That Differ on Tru64 UNIX.

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.

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

-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.
-Xcode<size> Allows a larger code region for code generated by the Fast VM. Size is the code region maximum allocation size in bytes. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. You can specify values between 24M and 128M. The default value is -Xcode24M.
-Xdynclassgc Instructs the Fast VM to garbage collect the class data for dynamically generated classes when those classes are no longer used. By default, the Fast VM garbage collects only heap objects, not class data structures. Refer to Garbage Collection of Class Data for Dynamically Generated Classes 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 compacting garbage collector (the default), which compacts live data in-place, rather than the copying garbage collector. 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 and Fast VM Garbage Collection Options.)
-Xgc:copying Instructs the Fast VM to use the "copying" garbage collector. (See also Fast VM Garbage Collection Options.) 
-Xgc:full_explicit Instructs the Fast VM to perform a full garbage collection when an explicit garbage collector call is made (system.gc()). By default, it may perform only a partial collection, depending on the current heap utilization.
-Xgc:ignore_explicit Instructs the Fast VM to ignore explicit garbage collector calls.
-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.
-Xlock:private Always initializes monitor locks as private. (See also Fast VM Lock Initialization Options.)
-Xlock:shared Always initializes monitor locks as shared. (See also Fast VM Lock Initialization Options.)

 

Back to top
Functionalities That Differ on Tru64 UNIX

The following functionalities either work differently on other UNIX platforms than they do on Tru64 UNIX, or Tru64 UNIX does not support them.

Displaying Chinese Characters

This kit provides /usr/opt/java141/jre/lib/font.properties.zh_GB18030 and /usr/opt/java141/jre/lib/font.properties.zh_GBK files that support displaying Chinese characters using the Simplified Chinese encodings GB18030 and GBK, respectively. Note that only Tru64 UNIX V5.1A and higher contains full Chinese language support and fonts for these encodings. The font set used by HP to support the GB18030 encoding does not work well with the Java programming language, and therefore the font.properties.zh_GB18030 file has been replaced with the contents of the GBK font property file so that the majority of the GB18030 characters are displayed properly for AWT and Swing components.

Elsa Gloria Graphics Card

When using a 16-bit Elsa Gloria graphics card, colors may not be represented correctly in Swing components. This problem does not occur when using 8-bit or 24-bit graphics. To work around this problem, set the graphics card back to 8-bit graphics; the colors will display properly.

HotSpot Virtual Machine

  • The SDK v 1.4.1 kit does not include support for Sun's HotSpot™ virtual machine.
  • The -hotspot option is silently ignored, and the -Xincgc option is not supported. This tuning option is specific to Sun's HotSpot™ virtual machine.

Java Sound Not Supported

Java Sound is not supported. The following error is reported if you attempt to use Java Sound:

   Java Sound support not currently available.

Fast VM Support

  • The Fast VM does not support the Java Platform Debugger Architecture (JPDA). See Compatibility for further information.
  • 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.

Using an OpenVMS Keyboard with CDE or Motif

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.

Back to top
Tuning and Performance

For specific tuning and performance information, refer to the following sections: Memory Usage, Reducing Fast VM Memory Requirements for Workstations and Client-side Applications, Dynamic Heap Management, Garbage Collection of Class Data for Dynamically Generated Classes, Fast VM Garbage Collection Options, Fast VM Garbage Collection Profiling Options, Controlling Stack Size, Using the Fast VM for Applications Requiring a Large Virtual Address Space, Applications Using a Large Number of Threads, Swap Space Problems, and Address Space Problems.

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

Garbage Collection of Class Data for Dynamically Generated Classes

Garbage collection in the Fast VM manages memory allocated in the heap. In other words, it reclaims memory associated with objects in the heap if it can be determined that these objects can not be referenced anymore. However, the Fast VM does not release the memory resources allocated while loading classes at any time during its run. This characteristic could result in memory being exhausted during the execution of long-running applications that dynamically create and execute classes (such as those that call into some class methods in the sun.reflect.* package). To remedy this situation, option -Xdynclassgc instructs the VM to manage memory resources allocated while loading dynamically generated classes, if they are no longer used. The -Xdynclassgc option is recommended for use by long-running applications that have encountered memory leak problems.

Fast VM Garbage Collection Options

The Fast VM provides two garbage collectors, which suit different heap usage patterns and memory configurations. The default is a multi-threaded compacting garbage collector. This collector is a hybrid mark-sweep/mark-compact collector, which will avoid moving data when it is not necessary.

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 that free space without moving any data at all. Thus, it also has performance advantages for applications with a moderate amount of long-lived data, but a high rate of short-lived object turnover. This collector is multi-threaded to provide better scaling on multiprocessor systems.

The second collector is a copying collector, which copies live data to an unused portion of the heap at collection time. This is best suited for applications with very small amounts of long-lived data relative to overall heap size. It may also have advantages on uniprocessor systems with small heap sizes, since the compacting collector's advantage of multithreading is lost there. To use this collector, specify the -Xgc:copying option on the command line.

Under the default compacting collector, explicit garbage collector calls (system.gc()) do not necessarily cause a full compaction. Depending on the current heap utilization and the free space goal specified by -Xmp, a partial compaction or a sweep may occur instead. However, for applications where it makes sense, the -Xgc:full_explicit option can be specified to force system.gc calls to perform full compactions. Generally, it is best to avoid calling system.gc() and to allow the Fast VM to decide when a collection is necessary. To specify that the Fast VM should ignore system.gc() calls entirely, use the -Xgc:ignore_explicit option. This may be useful if, for example, a third-party library containing unnecessary system.gc() calls is used.

Under the copying garbage collector, all explicit garbage collector calls cause full collections, unless -Xgc:ignore_explicit is used.

Fast VM Garbage Collection Profiling Options

This section describes the Fast VM Garbage Collection (GC) profiling options, which allow you to get heap dumps and allocation profiles at each garbage collection.

Option

Function

-Xverbosegc:alloc

Print an object allocation profile after each garbage collection

-Xverbosegc:file:<filename>

Print output of all -Xverbosegc options to specified file

-Xverbosegc:heap

Print pre- and post-garbage collection heap profiles

-Xverbosegc:heap_pre

Print pre-garbage collection heap profile

-Xverbosegc:heap_post

Print post-garbage collection heap profile


-Xverbosegc:file:<filename>

This option allows a file to be specified to which the output of all of the -Xverbosegc options given on the command line will be printed, instead of to the terminal.

-Xverbosegc:heap,-Xverbosegc:heap_pre,-Xverbosegc:heap_post

These options print heap profiles, sorted in descending order by bytes allocated of each object type in each size range, at each garbage collection. -Xverbosegc:heap prints a profile both before and after the collection, while heap_pre and heap_post allow you to specify only one or the other. For example, the output at the third garbage collection when running the SPECjbb2000 benchmark with the -verbose and -Xverbosegc:heap options and an initial/maximum heap size of 4 MB looks like:

--- Pre-GC Profile ---

   Bytes Objects     Sizeof Space%    Cum% Type
  537760    5729     64-512 28.25%  28.25% [C
  312160    5877       8-64 16.40%  44.65% [C
  279000   11625         24 14.66%  59.31% java/lang/String
  119624      13     4K-32K  6.28%  65.60% [B
   85152    2661         32  4.47%  70.07% spec/jbb/Item
   85088    2659         32  4.47%  74.54% spec/jbb/infra/Collections/nodeKeyRef
   65600       4     4K-32K  3.45%  77.99% [C
   60816     759     64-512  3.20%  81.18% [Ljava/lang/Object;
   55120     381     64-512  2.90%  84.08% [J
   49672      60   512-4096  2.61%  86.69% [B
   32784       1   32K-256K  1.72%  88.41% [Ljava/lang/Object;
   30408     153     64-512  1.60%  90.01% [I
   29216     332         88  1.53%  91.54% java/util/SimpleTimeZone
   26352    1098         24  1.38%  92.93% java/util/Hashtable$Entry
   12128     379         32  0.64%  93.56% spec/jbb/infra/Collections/longBTreeNode
    8080       1     4K-32K  0.42%  93.99% [S
    7384     219       8-64  0.39%  94.38% [I
    6912     144         48  0.36%  94.74% java/util/HashMap
    6328       2   512-4096  0.33%  95.07% [Ljava/util/Hashtable$Entry;
    6144     256         24  0.32%  95.40% java/util/HashMap$Entry
    5600     174       8-64  0.29%  95.69% [B
    4368     138       8-64  0.23%  95.92% [Ljava/util/HashMap$Entry;
    4016       1   512-4096  0.21%  96.13% [[B
    3952      82       8-64  0.21%  96.34% [Ljava/lang/Object;
    3800      95         40  0.20%  96.54% java/math/BigInteger
    3640       4   512-4096  0.19%  96.73% [Ljava/lang/Object;
    3232      12     64-512  0.17%  96.90% [B
    2608      14     64-512  0.14%  97.04% [Ljava/util/Hashtable$Entry;

...

<GC: Garbage Collection #3 with 4.00 MB Heap>

<GC:   Time since last collection     :       0.63 seconds>
<GC:   Time spent collecting          :       0.05 seconds>
<GC:   Data live before collection    :       1.96 MB>
<GC:   Data live after collection     :       1.22 MB>
<GC:   Data pinned during collection  :       0.27 MB>
--- Post-GC Profile ---
   Bytes Objects     Sizeof Space%    Cum% Type
  274120    2929     64-512 25.49%  25.49% [C
  154536    2908       8-64 14.37%  39.86% [C
  141144    5881         24 13.13%  52.99% java/lang/String
   85152    2661         32  7.92%  60.91% spec/jbb/Item
   65600       4     4K-32K  6.10%  67.01% [C
   60640     758     64-512  5.64%  72.65% [Ljava/lang/Object;
   55120     381     64-512  5.13%  77.78% [J
   32832       4     4K-32K  3.05%  80.83% [B
   32784       1   32K-256K  3.05%  83.88% [Ljava/lang/Object;
   29216     332         88  2.72%  86.59% java/util/SimpleTimeZone
   25872    1078         24  2.41%  89.00% java/util/Hashtable$Entry
   13136      16   512-4096  1.22%  90.22% [B
   12128     379         32  1.13%  91.35% spec/jbb/infra/Collections/longBTreeNode
    8080       1     4K-32K  0.75%  92.10% [S
    7296     216       8-64  0.68%  92.78% [I
    6328       2   512-4096  0.59%  93.37% [Ljava/util/Hashtable$Entry;
    5952     124         48  0.55%  93.92% java/util/HashMap
    5664     236         24  0.53%  94.45% java/util/HashMap$Entry
    3800      95         40  0.35%  94.80% java/math/BigInteger
    3744      33     64-512  0.35%  95.15% [I
    3640       4   512-4096  0.34%  95.49% [Ljava/lang/Object;
    3248     118       8-64  0.30%  95.79% [Ljava/util/HashMap$Entry;
    3232      12     64-512  0.30%  96.09% [B
    2544       1   512-4096  0.24%  96.33% [I
    2504      13     64-512  0.23%  96.56% [Ljava/util/Hashtable$Entry;
    2080     130         16  0.19%  96.75% java/util/jar/Attributes$Name

...

-Xverbosegc:alloc

This option tells the Fast VM to keep track of allocation points and to compile a list of how many objects/bytes of what type are allocated at each call site. An object allocation profile, sorted in descending order by bytes allocated, is printed after each garbage collection report. The object allocation profile is cumulative up until each garbage collection, and starts over again after each garbage collection. By default, the output goes to the terminal. The output tends to wrap because of fully specified method names in the method call information for every call site, so a wide terminal window is optimal for viewing these stack traces.

For example, the output of the second garbage collection report and object allocation profile when running the SPEC JVM98 benchmarks with the -Xverbosegc:alloc option and an initial/maximum heap size of 4 MB begins with:

<GC: Garbage Collection #2 with 4.00 MB Heap>

<GC:   Time since last collection     :       4.06 seconds>
<GC:   Time spent collecting          :       0.03 seconds>
<GC:   Data live before collection    :       1.96 MB>
<GC:   Data live after collection     :       0.77 MB>
<GC:   Data pinned during collection  :       0.23 MB>
Object Allocation Profile #2:
 objects      bytes alloc% class
---------------------------------
       1     160016   8.8% [I
			   46: spec/benchmarks/_205_raytrace/Canvas.<init>(II)
			   61: spec/benchmarks/_205_raytrace/RayTracer.run([Ljava/lang/String;)
			    2: spec/benchmarks/_205_raytrace/RayTracer.inst_main([Ljava/lang/String;)
			   65: spec/benchmarks/_227_mtrt/Main.runBenchmark([Ljava/lang/String;)
			    1: spec/benchmarks/_227_mtrt/Main.harnessMain([Ljava/lang/String;)
			   84: spec/harness/ProgramRunner.runOnce(Ljava/lang/Object;IJILjava/util
/Properties;) 481: spec/harness/ProgramRunner.runBenchmark2() 43: spec/harness/ProgramRunner.runBenchmark() 8: spec/harness/ProgramRunner.run() 221: spec/harness/RunProgram.run(Ljava/lang/String;ZLjava/util/Properties
;Lspec/harness/BenchmarkDone;) 16: SpecApplication.runBenchmark(Ljava/lang/String;Z) 609: SpecApplication.main([Ljava/lang/String;) 1695 138064 7.6% [C 56: java/lang/String.<init>([CII) 7: java/lang/String.copyValueOf([CII) 202: java/io/DataInputStream.readLine() 304: spec/benchmarks/_205_raytrace/Scene.ReadPoly(Ljava/io/DataInputStream;I) 186: spec/benchmarks/_205_raytrace/Scene.LoadSceneOrig(Ljava/lang/String;) 8: spec/benchmarks/_205_raytrace/Scene.LoadScene(Ljava/lang/String;) 6: spec/benchmarks/_205_raytrace/Scene.<init>(Ljava/lang/String;) 11: spec/benchmarks/_205_raytrace/Runner.run() 1719 137904 7.6% [C 56: java/lang/String.<init>([CII) 7: java/lang/String.copyValueOf([CII) 202: java/io/DataInputStream.readLine() 202: spec/benchmarks/_205_raytrace/Scene.ReadPoly(Ljava/io/DataInputStream;I) 186: spec/benchmarks/_205_raytrace/Scene.LoadSceneOrig(Ljava/lang/String;) 8: spec/benchmarks/_205_raytrace/Scene.LoadScene(Ljava/lang/String;) 6: spec/benchmarks/_205_raytrace/Scene.<init>(Ljava/lang/String;) 11: spec/benchmarks/_205_raytrace/Runner.run() 3438 137520 7.5% java/lang/FloatingDecimal

...

In the second entry of the above object allocation profile, 1695 objects totaling 138064 bytes and of type [C (array of char) were allocated with the call chain shown, and account for 7.6% of the total bytes allocated from the first up until the second garbage collection.

For primitive types, the type names are defined as follows:

    V - void
B - byte
Z - boolean
C - char
S - short
I - int
F - float
J - long
D - double

For array types, the names shown are prefixed with [. For object types, the names shown are prefixed with L.

Note: The overhead of allocation profiling will dramatically decrease your application performance.

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 -Xss512k 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 environment variable JAVA_FAST64_VM.

Applications Using a Large Number of Threads

If you experience a "java.lang.OutOfMemoryError" error 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 now 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.1 systems, the following sections may be helpful (similar sections would apply for other versions):

  • 2.3.2.2 Choosing a Swap Space Allocation Mode
  • 2.3.2.3 Determining Swap Space Requirements
  • 6.3.3 Displaying Swap Space Usage by Using the swapon Command

Address Space Problems

If you see the following message:

Fast VM cannot allocate its internal data.
Please check process stack size and virtual address space limit.
Stack size may be too large, or virtual address space too small.

the Fast VM cannot allocate certain memory regions that it requires to start up. This is not because the Fast VM requires a large space, but because it requires that certain parts of its space be in 32-bit addressable memory regions. This problem generally occurs if process quotas are set inappropriately:

  1. Too large a process stack size. The stack then consumes too much of 32-bit addressable space, so the Fast VM cannot start up. The most common configuration problem that causes this is a stack size of 4 GB, which consumes all of 32-bit addressable space. You can solve this by changing the stack quota with a ulimit command, or by changing the default process stack size with the sysconfig utility.
  2. Too small an address space limit. If the stack is not the problem, check the virtual address space limit with ulimit -a , and try increasing it.

For further information, refer to Tru64 UNIX System Configuration and Tuning.

Fast VM Lock Initialization Options

In the Fast VM, Java monitors, which are locks used for code synchronization, are implemented using an optimized sequence of monitor states. They are initialized as "private" (to a thread), which allows extremely lightweight locking. If threads share a monitor, the monitor is promoted to a "shared" state. If the Fast VM determines that promotion to the shared state is extremely common, it may instead begin initializing monitors in that state, to avoid the cost of promotion.

In some rare instances, application performance might benefit from forcing the Fast VM to always initialize monitors as private or shared, regardless of how often promotion does or does not occur. The -Xlock option allows you to specify the initial lock state, but should only be used if you are very familiar with your application's locking behavior.

-Xlock:private — Always initialize monitor locks as private.
-Xlock:shared — Always initialize monitor locks as shared.

Back to top
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/java141/include \
  -I/usr/opt/java141/include/alpha \
    invokejvm.cxx \
    /usr/opt/java141/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/java141/jre/lib/alpha/
/usr/opt/java141/jre/lib/alpha/fast64
/usr/opt/java141/jre/lib/alpha/native_threads

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

setenv JLIB /usr/opt/java141/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.

Loading the Java Executable in 31-bit Addressable Range

If your Java application invoked JNI C/C++ code that was linked using the ld -taso options, then use the java-taso command to run your Java application. The Java -taso option has been replaced by the java-taso command.

Back to top
Using the Plug-in

Plug-in v 1.4.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.4.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 Sun's Java Plug-in Product web site.

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/java141/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/java141/jre/plugin/alpha/ns600/libjavaplugin_oji.so.

For example:

cd ${MOZILLA}/plugins

ln -s /usr/opt/java141/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

For Netscape 4.x browsers: The Plug-in does not replace the underlying Virtual Machine for Java 2 for Netscape Navigator®; 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 Using OBJECT, EMBED and APPLET Tags in Java Plug-in on Sun's site.

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.4.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/java141/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/java141/bin/HtmlConverter file.html

For more information about the HTML Converter, see Using the HTML Converter to Convert Applet Tags for Java Plug-in on Sun's site.

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/java141/jre/bin/ControlPanel

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

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

Some of the Control Panel features are discussed in the following sections. Refer to Using the Java Plug-in Control Panel to Set Plug-in Behavior/Options on Sun's site 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.

Back to top
Font Support

The SDK includes the following font support.

Role of the font.properties File

Starting with J2SDK 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.4.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 the SDK v 1.4.1 kit reside in /usr/opt/java141/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 RTE 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/java141/jre/lib/font.properties \ 
        /usr/opt/java141/jre/lib/font.properties.orig  

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

If later you wish to revert to the original file that shipped with SDK v 1.4.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/java141/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 Version 4.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.

Back to top
Documentation and Other Information

Documentation

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

   /usr/opt/java141/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 the index.html file (which contains a brief summary of important instructions you should perform before you install this kit).

Note: The documentation in JAVADOC141 does not include the API reference documentation. If you want to use the API reference documentation locally, download and install the separate javaapidoc141-3.tar file as described in Installing the API Reference Documentation. Browse the API documentation using the following location:

/usr/opt/java141/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.4.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 Sun's Java Tutorial.

Back to top
Problem Reporting

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

© 2002, 2004 Hewlett-Packard Development Company, L.P.

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

Hewlett-Packard shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is subject to change without notice.

INFORMATION PROVIDED HEREWITH IS PROVIDED “AS IS” “WHERE IS” WITHOUT ANY WARRANTY WHATSOEVER. THE ENTIRE RISK ASSOCIATED WITH THE USE OF MATERIALS RESIDES WITH LICENSEE. ALL OTHER WARRANTIES, EITHER EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, ACCURACY, CONDITION, OWNERSHIP, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS.

Privacy statement Using this site means you accept its terms Feedback to Java on Alpha
© 2004 Hewlett-Packard Development Company, L.P.