Contents

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.

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.

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

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.
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 :
- If you want to deinstall prior versions, see Deinstalling
Other Versions.
- Download the following binary kit:
java141-3.tar
- 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
- 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:
|
|
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. |
- 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.
- Download the following binary kit:
javaapidoc141-3.tar
- 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
- 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)
- 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:
- 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.
- 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, ...)
If you want to deinstall this kit in the future, perform the following
steps as superuser :
- 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
- To delete subsets, enter the
setld -d command.
For example,
setld -d JAVA141 JAVADEV141 JAVADOC141 JAVAAPIDOC141
To deinstall other versions, perform the following steps as superuser :
- Use the
setld -i command to determine what Java
subsets are installed and which you want to delete.
- 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:
- 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.
- 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.
- Set the default system
Java environment version to SDK v 1.4.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
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.
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.

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
The following sections provide useful information and tips for
using the SDK on Tru64 UNIX systems.
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:
- 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
- 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 .
As noted in the Introduction, this kit contains
two virtual machines. The following sections describe how to control
which virtual machine your application uses.
SDK v 1.4.1 lets you control which virtual machine your application
uses, based on the following options:
|
|
-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. |
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
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.
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.
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.
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.
In addition to Sun's options, the java command supports
the following options.
|
|
-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 -Xmp nn, 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.) |

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.
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.
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:
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.
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 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.
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.
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.
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
...
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.
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 -Xss n
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
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.
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 .
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:
- 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.
- 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.
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.
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.
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.)
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 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.
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.
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
To see Java error messages:
- Use the Plug-in Control Panel to enable the console window.
- 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.
The SDK includes the following font support.
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.
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.
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:
- 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:
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
- 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.
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.
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.
To report problems, refer to our Software
Support Web page. |