Contents
Introduction
Thank you for downloading the Software Development Kit (SDK) v
1.3.1-7 for the Tru64™ UNIX® Operating System for the
Java™ Platform (hereafter called the SDK). These release notes
contain installation instructions, new
features, known issues, fixed problems, usage documentation, and other information specific to the Tru64
UNIX port of Sun Microsystems' Java 2 SDK, Standard Edition (J2SDK).
SDK v 1.3.1-7 implements the J2SDK v 1.3.1, and is based on Sun’s
J2SDK 1.3.1_012 Solaris Reference Release. It passes all the tests
in Sun's Java Compatibility Kit test suite (JCK V1.3a). Use the
java -version command to
check the version of the SDK that you are using.
This kit can be used to develop and run Java applets and programs
on systems installed with Tru64 UNIX V4.0F, V4.0G, or V5.1A and
higher. If you need to upgrade your version of Tru64 UNIX, please
refer to the Tru64 UNIX web site for additional information.
This kit contains two virtual machines:
- The classic virtual machine (classic VM, the virtual
machine shipped with prior releases) is based on Sun's reference
implementation. The classic VM contains Just-In-Time (JIT) compiler
technology, but does not have the performance of the Fast Virtual
Machine (Fast VM). However, it provides additional debugging support
not currently available in the Fast VM. To run the classic VM,
specify the Java
-classic option on the command line.
- The Fast Virtual Machine is the default virtual machine.
It was previously provided as a separate download. Because
the Fast VM is included in this kit, it is no longer provided
as a separate kit. Refer to Fast Virtual
Machine (Fast VM) v 1.3.1 is now the default VM for the SDK
for more information.
IMPORTANT: Please make sure you understand the
Copyright (copyright.html, installed
file) and License (license.html, installed
file) information before using this release.
New Features
The following sections briefly describe the new features HP has
included in SDK v 1.3.1. HP recommends that you read Sun's
Java 2 SDK, Standard Edition, version 1.3 Summary of New Features
and Enhancements for a thorough description of all new features
and enhancements available in the J2SDK v 1.3.
SDK v 1.3.1-7 New
Features
This kit installs SDK v 1.3.1-7, which is a maintenance release
with the following new features from HP.
Note: Precompiled standard class files are no
longer available with SDK v 1.3.1.
Expiring Certificates Replaced
Expiring certificates in the /usr/opt/java131/jre/lib/security/cacerts
file have been replaced with the latest updates.
New Fast VM Option
The option, -Xcode<size>, which allows a larger
code region for code generated by the Fast VM, has been added in
this release. Size is the code region maximum allocation size in
bytes. Append the letter k or K to indicate kilobytes, or m or M
to indicate megabytes. You can specify values between 24M and 128M.
The default value is -Xcode32M.
SDK v 1.3.1-6 New
Features
SDK v 1.3.1-6 was a maintenance release with no new features from
HP.
SDK v 1.3.1-5 New
Features
SDK v 1.3.1-5 was a maintenance release with no new features from
HP.
SDK v 1.3.1-4 New
Features
SDK v 1.3.1-4 was a maintenance release with no new features from
HP.
SDK v 1.3.1-3 New Features
SDK v 1.3.1-3 was a maintenance release with the following new
features from HP.
Reduced Fast VM Memory Requirements
The Fast VM is optimized for large, long-running programs running
on server systems. Many users would like to use the Fast VM on their
workstations for client-side applications; however, some of these
systems do not have the resources to start up the Fast VM with its
default configuration. A -client switch has been added
to address these needs. For more information, refer to Reducing
Fast VM Memory Requirements for Workstations and Client-side Applications.
SDK v 1.3.1-2 New Features
SDK v 1.3.1-2 was a maintenance release with no new features from
HP.
SDK v 1.3.1-1 New Features
SDK v 1.3.1-1 contained the following new features from HP:
Fast Virtual Machine (Fast VM) v 1.3.1 is now
the default VM for the SDK
The Fast Virtual Machine (Fast VM) is the default SDK VM. Because
it is installed transparently as a part of the SDK v 1.3.1 kit,
you no longer need to download and install the Fast VM kit separately.
Benefit: The Fast VM provides optimal runtime performance
on Tru64 UNIX systems and offers significant performance advantages
over the classic VM.
The classic VM is still provided with the SDK, via the -classic
command line option. For more information on VM options, see Selecting
the VM and Compatibility.
Compacting Garbage Collector
This version of the Fast VM supports an alternative compacting
garbage collector, which compacts live data in-place, rather than
copying it as the default collector does. This collector is a hybrid
mark-sweep/mark-compact collector, which will avoid moving data
when it is not necessary.
Benefit: This collection scheme can have better performance
characteristics and lower heap size requirements for applications
in which the heap contains a high percentage of long-lived data.
This collector can also perform minor collections, rather than collecting
the entire heap, when the percentage of live data is moderate. It
can also perform sweeps, which free space without moving any data
at all. Thus, it may also provide performance advantages for certain
applications with a moderate amount of long-lived data, but a high
rate of short-lived object turnover.
To use the compacting collector, specify the -Xgc:compacting
option on the command line. The -Xgc:copying
option causes the Fast VM to use the default "copying"
collector.
Plug-in
SDK v 1.3.1 includes the Plug-in for the Tru64 UNIX Operating System
(hereafter called the Plug-in) that enables users to run Java applets
and JavaBeans™ components on web pages using the Run Time
Environment (RTE) for the Tru64 UNIX Operating System (hereafter
called the RTE) as an alternative to using the default Virtual Machine
for Java 2 that comes with the web browser. Based on the Java Plug-in
1.3.1 provided by Sun Microsystems, the Plug-in contains similar
functionality. The Open JVM Interface (OJI) Plug-in is now
supported. For more information, refer to Using
the Plug-in.
Benefit: The SDK v 1.3.1 kit provides the Plug-in so a
separate download is not required.
Fixed Problems
The following sections provide important information about problems
that HP has fixed in SDK v 1.3.1. HP recommends that you also review
Sun's
Java 2 SDK and Runtime Environment Important Bug Fixes and Changes
documentation for information concerning bug fixes that Sun has
made for this release.
Problems
Fixed in SDK v 1.3.1-7
This kit installs SDK v 1.3.1-7, and is based on Sun’s J2SDK
1.3.1_12 Solaris Reference Release. It contains the following HP-specific
fixes:
- When running the Fast VM, several SEGV exceptions and
Assertion
failed:... problems were fixed.
- The Fast VM now supports the
-Xrs option, as described
on Sun's
site.
sun.io.Signal() correctly throws the Signal
Already used by VM: Exception.
- Previously, when using the Fast VM, if an object in the Java
heap spanned more than a page of memory, and the compacting garbage
collector performed a sweep operation, in rare cases a SEGV exception
could occur on the subsequent collection. This has been corrected.
- This release contains fixes to correct memory leaks in long-running
applications that use DECwindows.
- A problem where the Fast VM aborts with
Unable to suspend
thread when thread suspension fails has been fixed.
- Previously, when accessing Java libraries from a C program using
JNI and LD_LIBRARY_PATH was not specified, a problem occurred.
This has been corrected.
- In previous versions, when running the Fast VM on an eight or
more processors system, the garbage collector could fail with
a
GC: failure in slave threads,... message. This
problem has been fixed in this release.
- Previously, when invoking the
java command using the
nohup tool, a Fast VM problem occasionally caused premature
process termination. This has been corrected.
Problems
Fixed in SDK v 1.3.1-6
SDK v 1.3.1-6 was based on Sun’s J2SDK 1.3.1_08 Solaris Reference
Release.
- This release fixes some
IllegalAccessError errors
that previously occurred when using the Fast VM.
- The native stack size for Java threads has been increased to
approximately 512 KB.
- Previously, when running the JIT, an
IncompatibleClassChangeError
exception could occur. This has been corrected.
- Previously, if you were using SDK v 1.3.1-4 or v 1.3.1-5 on
Tru64 UNIX V5.1B, the SysMan Station Authentication server would
quietly fail to start at system boot time. This would cause problems
later on when using the SysMan Station operating system tool.
This regression has been fixed in this release.
- A C program that establishes a user defined
SIGSEGV
handler no longer causes an infinite loop when using the Fast
VM.
Problems
Fixed in SDK v 1.3.1-5
SDK v 1.3.1-5 was based on Sun’s J2SDK 1.3.1_04 Solaris Reference
Release.
- SDK v 1.3.1-3 and v 1.3.1-4 for Tru64 UNIX introduced a regression
in command-line option switch processing. When using the Fast
VM, defining the
CLASSPATH environment variable would
incorrectly override the -classpath option on the
command line. This has been corrected so that if the -classpath
option is specified on the command line, it will override the
definition of the CLASSPATH environment variable.
- When using the Fast VM, a memory leak involving AWT calls has
been corrected.
- Previously, using the middle mouse button to paste text into
a
JTextField would result in a NullPointerException
or a ClassCastException. This problem has been corrected.
Problems
Fixed in SDK v 1.3.1-4
SDK v 1.3.1-4 was based on Sun’s J2SDK 1.3.1_04 Solaris Reference
Release.
- Previously, if
libnspr4.so was installed on your
system, the Plug-in for Netscape 4.x browsers would fail to initialize
and cause Netscape Communicator to exit with the following error:
INTERNAL ERROR on Browser End: Could not load libjavaplugin_oji.so:
linking
error=dlopen: cannot load directory/.netscape/java/lib/libjavaplugin_oji.so
System error?:: No such file or directory
where directory is the user's default directory. This
problem has been fixed.
- Previously, the Plug-in for Netscape 4.x browsers would fail
to load if the
NPX_PLUGIN_PATH environment variable
included a trailing slash.
The following error was displayed:
Plugin: couldn't read directory /usr/opt/java131/jre/plugin/lib/
Exec of /usr/opt/java131/jre/plugin/bin/alpha/native_threads/java_vm
failed: 2
Plugin: Plugin is not enabled or Java VM process has died.
The restriction that the NPX_PLUGIN_PATH environment
variable could not end in a trailing slash has been removed.
Problems Fixed in SDK v 1.3.1-3
SDK v 1.3.1-3 was based on Sun’s J2SDK 1.3.1_03 Solaris Reference
Release.
- Previously, the Fast VM erroneously blocked the SIGTERM signal
for threads it created; hence,
java.lang.Process.destroy(),
or other application functionality that relied on receiving SIGTERM
signals, might not work as expected. This has been corrected in
this release.
- A correction was made to the Alt key when using the
CDE or Motif window managers, so it now works as expected.
- Previously, the text for some AWT components was not displayed
correctly when using Chinese Big 5 fonts. This problem has been
corrected in this release.
Problems Fixed in SDK v 1.3.1-2
SDK v 1.3.1-2 was based on Sun’s J2SDK 1.3.1_01 Solaris Reference
Release.
- When running in the Fast VM, a thread would hang if it attempted
to close a socket on which another thread had a read operation
pending. This has been fixed in this release.
- If a garbage collection is triggered when exception handling
is in progress, and the heap contains a very deeply nested object
tree (more than about 50 levels), memory corruption may occur.
This occurs only with the default "copying" garbage
collector. It is extremely rare, but can result in a crash or
hang in later execution. This has been corrected in this release.
- This release provides a modified
font.properties.ko
file, which correctly displays Korean characters when the locale
is set to Korean.
- The Fast VM did not correctly recognize the
JNI_CreateJavaVM
options for specifying abort, exit,
or vfprintf hooks. Also, the Fast VM would not accept
the Java 1.1 form of the initialization argument (JDK1_1InitArgs)
to JNI_CreateJavaVM. These problems have both been
fixed in this release.
- On Tru64 UNIX systems with small swap files, when the Fast VM
was started up, the message "Unable to obtain requested swap
space" was sometimes reported, even though the Fast VM would
successfully run. This has been corrected in this release.
- Using the
-taso option with the Fast VM could sometimes
result in an "Assertion failed" message and termination
of the Java image. This has been corrected in this release.
- In v 1.3.1-1, the JTextArea component would hang when using
CTRL C to cut text. This problem has been fixed.
Problems Fixed in SDK v 1.3.1-1
SDK v 1.3.1-1 was based on Sun’s J2SDK 1.3.1_01 Solaris Reference
Release.
- Previously, when you started the Plug-in on Tru64 UNIX using
a Netscape browser, Netscape popped up a "subprocess diagnostics"
window with the text "No more modules." After you pressed
the OK button, everything loaded normally. In SDK v 1.3.1-1, this
"subprocess diagnostics" window no longers appears.
- In SDK v 1.3.0, the Date class would return timezones in a GMT
format. It would also have incorrect daylight saving time results.
This has been corrected in SDK v 1.3.1-1 so that the correct time
and timezone are displayed. If, however, you still receive the
time in a GMT format, set the
TZ environment variable
to one of the values contained in /usr/opt/java131/jre/lib/tzmappings.
- Previously, problems existed with several of the Chinese locales;
this has been corrected, and Chinese characters now display correctly
in AWT and Swing components.
- Japanese characters display correctly in all AWT and Swing components.
- Previously, a syntax error "fi statement is not correct"
occurred when attempting to display some Japanese characters.
This problem was due to French characters in the .java_wrapper
script and has been corrected.
- Occasionally seg faults would occur when using JPDA. This problem
has been corrected.
- When using the eXcursion window manager, window decorations
would sometimes persist, such as when displaying a splash screen.
This has been corrected.
- Certain numeric keypad keys did not work when using the eXcursion
window manager or DIGITAL keyboards. Keys "/", "*",
"-", "+", "Home", and "End"
now work correctly. These keyboard problems did not exist for
PC keyboards when using CDE or Motif.
Compatibility
SDK v 1.3.1 is compatible with previous versions of the SDK. Most
existing programs will run on the SDK v 1.3.1 platform. However,
some important incompatibilities do exist and are thoroughly discussed
in Sun's Java
2 Platform v1.3 Compatibility with Previous Releases document.
For specific J2SDK v 1.3.1 incompatibilities refer to the section,
Incompatibilities
in the Java 2 Platform, Standard Edition, v1.3.
The default VM, the Fast VM, uses more memory than the classic
VM; therefore, in SDK v 1.3.1, you might need to adjust your quotas
or heap size. Refer to Memory Usage for more
information.
The Fast VM does not support the Java Platform Debugger Architecture
(JPDA). If you try to debug an application with any debugger that
uses the JPDA interface such as jdb, you will see a message stating
that the Fast VM does not support JPDA and debugging will continue
using the classic VM.
Installation
The following sections describe how to install the SDK v 1.3.1
kit on your Tru64 UNIX system.
Tru64 UNIX Patches
This kit requires Tru64 UNIX V4.0F, V4.0G, or V5.1A and higher.
Presently, the SDK v 1.3.1 release does not require any operating
system patches; however, the need for patches may be discovered
after this release becomes available. Therefore, we recommend that
you check the product
page on our Web site for the latest information.
Installing the Kit
With SDK v 1.1.7B and previous versions, you could install only
one SDK version on a system. With later versions, you can install
and use multiple versions on one system. In addition, you can change
the default system Java environment version, which is the version
located in /usr/bin.
When you install the SDK v 1.3.1 kit on your system, all files
are installed in directories under /usr/opt/java131.
In most cases, SDK v 1.3.1 is not installed as the default system
Java environment version, and you need to take special actions to
use SDK v 1.3.1 after it is installed. See Using
SDK v 1.3.1. If you want to change the default system Java environment
version, see Making SDK v 1.3.1 the Default
System Java environment version.
|
NOTE
SDK v 1.3.1 is available from our Software Download
page and is also bundled with some versions of the Tru64 UNIX
operating system. However, the Java subset names are
different. Kits downloaded from our Software Download
page begin with the subset name "JAVA." In contrast,
Java subsets included with the Tru64 UNIX operating system
begin with the name "OSF."
For a description of both Java subsets, see Step 4. For additional information about installing the SDK
during the Tru64 UNIX installation, see the Tru64
UNIX Installation Guide. |
To install, perform the following steps as superuser:
- If you want to deinstall prior versions, see Deinstalling
Other Versions.
- Download the following binary kit:
java131-7.tar
- Untar it into a scratch directory,
/tmp/java, for
example:
cd /tmp/java
tar xf /tmp/java/java131-7.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
There are three subsets that you can install:
JAVA131 - The mandatory subset,
which provides support for running Java programs and applets.
JAVADEV131 - The development
environment, which allows you to compile and debug Java code.
JAVADOC131 - The documentation
subset.
HP recommends installing all three subsets if you intend to
use the SDK in a development capacity.
|
Tru64 UNIX Subset Names
The Software
Download page uses the subset names listed in Step
4. However, if SDK v 1.3.1 has been installed as part
of the Tru64 UNIX operating system installation, it will
have the following subset names:
OSFJAVAnnn
- The mandatory subset that provides support for running
Java programs and applets.
OSFJAVADEVnnn
- The development environment, which allows you to compile
and debug Java code.
OSFJAVADOCnnn
- The documentation subset.
where nnn refers
to the base operating system version number.
Note that if you are updating to a later version of
SDK v 1.3.1, you must first deinstall these subsets. See
Deinstalling Other Versions
for instructions. |
- Once you have installed the desired subsets, you can delete
the scratch directory unless you also download the API
reference documentation.
Installing the API Reference Documentation
You can also download and install the API reference documentation
for SDK v 1.3.1. Allow 105 MB of disk space for the installed API
reference files.
To install, perform the following steps as superuser:
- Download the following binary kit:
javaapidoc131-7.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/javaapidoc131-7.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:
JAVAAPIDOC131
- The API documentation
Browse the documentation using the following location:
/usr/opt/java131/docs/api/index.html
- Once you have installed the desired subsets, you can delete
the scratch directory.
Determining Your Installed Version
After you have installed SDK v 1.3.1, the /usr/opt/java131/bin/java
-version command should display the following for this kit:
% /usr/opt/java131/bin/java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition
Fast VM (build 1.3.1-7, native threads, mixed mode, ...)
Deinstalling the SDK v 1.3.1 Kit
If you want to deinstall this kit in the future, perform the following
steps as superuser:
- Use the
setld -i command to determine which SDK
v 1.3.1 subsets are installed. For example:
setld -i | grep JAVA | grep 131 | grep installed
- To delete subsets, enter the
setld -d command.
For example,
setld -d JAVA131 JAVADEV131 JAVADOC131 JAVAAPIDOC131
Deinstalling Other Versions
To deinstall other versions, perform the following steps as superuser:
- 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
JAVA122 installed Java 1.2.2-12 Environment (General Applications)
JAVADEV122 installed Java 1.2.2-12 Development Environment
JAVADOC122 installed Java 1.2.2-12 Online Documentation
% setld -d JAVA122 JAVADEV122 JAVADOC122
Making SDK v 1.3.1 the Default System
Java Environment Version
Note: Use caution when changing the default system
Java environment to SDK v 1.3.1 for the following reasons:
- If you run applications on your system that depend on SDK v
1.1.n being the default system Java environment version, they
may not execute properly.
- Tru64 UNIX V5.0A includes some Java-based tools that depend
on the Java environment version that ships with the operating
system and is installed in
/usr/bin. If you change
the default system Java environment version, some operating system
tools, such as the SysMan Station, the SysMan Station authentication
daemon, and the Logical Storage Manager (LSM) Storage Administrator,
will not work correctly. Starting with Tru64 UNIX V5.1, these
tools are not affected by the user changing the default version.
See Using SDK v 1.3.1 for more information
on using SDK v 1.3.1 when it is not the default system Java environment
version.
When you make SDK v 1.3.1 the default system Java environment
version, system files such as /usr/bin/java are modified
so that SDK v 1.3.1 is used whenever Java commands are entered.
If a default system Java environment version is not found during
installation, SDK v 1.3.1 is installed as the default system Java
environment version. Otherwise, perform the following steps as superuser
to make SDK v 1.3.1 the default system Java environment version:
- Determine what the default system Java environment version
is on your system by using the following command:
/usr/bin/java -version # Note: Use /usr/bin/java to insure that the
# default system Java environment version
# is executed.
- 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.3.1:
/usr/opt/java131/bin/set_java_default.sh
- Verify that SDK v 1.3.1 is now the default version:
% /usr/bin/java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition
Fast VM (build 1.3.1-7, native threads, mixed mode, ...)
To switch the default system Java environment version from SDK
v 1.3.1 back to SDK v 1.1.8, use the following commands:
/usr/opt/java131/bin/unset_java_default.sh
/usr/opt/java118/bin/set_java_default.sh
Troubleshooting Multiple Versions
If you have multiple Java environment versions installed on your
system and have trouble running Java applications, first check what
Java environment version you are using and what the default Java
environment version is on the system:
% java -version # Check version being used
% /usr/bin/java -version # Check default Java on system
Then check your definitions of PATH and CLASSPATH:
printenv PATH
printenv CLASSPATH
If you encounter the error "java: Permission denied",
check to insure that PATH is set properly. See Changing
Your PATH to Use SDK v 1.3.1.
Contents of the SDK
This section provides a general summary of the files and directories
contained in the SDK once it has been installed on your system.
Development Tools
(In the bin subdirectory.) Programs
that will help you develop, execute, debug, and document programs
written in the Java programming language. For further information,
see Sun's Tools
and Utilities page.
Run Time Environment (RTE)
(In the jre subdirectory.) An implementation
of the Run Time Environment (RTE) for use by the SDK. The runtime
environment includes a virtual machine for Java 2, class libraries,
and other files that support the execution of programs written in
the Java programming language.
Additional libraries
(In the lib subdirectory.) Additional
class libraries and support files required by the development tools.
Demo Applets and Applications
(In the demo subdirectory.) Examples,
with source code, of programming for the Java platform. These include
examples that use Swing and other Java Foundation Classes. The demos
are installed in the following directory:
/usr/opt/java131/demo
C header Files
(In the include subdirectory.) Header
files that support native-code programming using the Java
Native Interface and the Java
Virtual Machine Debugger Interface, as described on the Sun
site.
Source Code
(In src.jar archive file.) Java programming language
source files for all classes that make up the Java 2 core API (that
is, source files for the java.*, javax.* and org.omg.* packages,
but not for com.sun.* packages). This source code is provided for
informational purposes only, to help developers learn and use the
Java programming language. These files do not include platform-specific
implementation code and cannot be used to rebuild the class libraries.
To extract these files, use this command:
jar xvf src.jar
Do not modify core API source files. To extend the behavior of
the core API, write subclasses of the core API classes.
For core API documentation, refer to the following sources:
Known Issues
This section provides descriptions of the known issues and limitations
in the SDK; they include the following:
- When using a 16-bit Elsa Gloria graphics card, fonts may not
appear at all on Swing components. Also, colors may not be represented
correctly in Swing components. By turning off DoubleBuffering,
the fonts display correctly. To do this, add the following line
to your program:
RepaintManager.currentManager(frame).setDoubleBufferingEnabled(false);
where "frame" is the JFrame component in your application.
This problem does not occur when using 8-bit or 24-bit graphics.
Another workaround is to set the graphics card back to 8-bit
graphics, which will cause the fonts and colors to display properly.
- The
-hotspot option is silently ignored, and the
-Xincgc option is not supported. This tuning option
is specific to Sun's HotSpot™ virtual machine. For more
information refer to Restrictions.
- Starting with SDK v 1.3.0-1, the SDK contains better graphic
performance than previous SDK v 1.2.2 releases. However, some
graphics operations remain slower in the releases beginning with
SDK v 1.3.0-1 than they do in SDK v 1.1.n releases.
With Java 2, Sun changed the underlying architecture of the graphics
subsystem. In Sun's JDK V1.1.n, more of the graphics operations
were done using native code. For example, the drawLine()
method would result in a call to XDrawLine. With
Java 2, the rendering of graphics has been moved to Java code,
which computes the image and sends the pixels out to the display.
As a result, the performance of graphical operations can be slower
with J2SDK v 1.3.1, particularly when displaying to a remote machine.
Consequently, the slow performance that you see with some graphics
operations is not specific to the SDK, but is inherent in the
architecture of Java 2.
Sun has received a number of bug reports on this performance
problem. For example, see the following list of bug reports in
the Bug Database at Sun's
Java Developer web site: 4204845, 4185726, 4217446, and 4210230.
Once you have logged in (you must register, but it is free), follow
the link to the Bug Database.
Using the SDK on Tru64 UNIX Systems
The following sections provide useful information and tips for
using the SDK on Tru64 UNIX systems.
Using SDK v 1.3.1
In most cases, SDK v 1.3.1 is not installed as the default system
Java environment version (See Installing
the Kit.). As a result, you must do one of the following to
use SDK v 1.3.1:
Changing Your PATH to Use SDK v 1.3.1
If SDK v 1.3.1 is not the default system Java environment version,
you can conveniently use SDK v 1.3.1 by changing the PATH environment
variable as follows:
- Place the directory,
/usr/opt/java131/bin, first
in your PATH so that it is searched before the system directories.
Directory /usr/opt/java131/bin contains the SDK v
1.3.1 executables. For example, using csh(1):
setenv PATH /usr/opt/java131/bin:$PATH
- Verify that you are using SDK version 1.3.1:
% java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition
Fast VM (build 1.3.1-7, native threads, mixed mode, ...)
To stop using SDK v 1.3.1, remove /usr/opt/java131/bin
from your PATH.
Note: If you are using Tru64 UNIX V5.0A, you
must remove /usr/opt/java131/bin from your PATH when
using some Java-based tools that ship with the operating system.
These tools, including the SysMan Station, the SysMan Station authentication
daemon, and the Logical Storage Manager (LSM) Storage Administrator,
depend on the Java environment version that ships with the operating
system and is installed in /usr/bin. These tools will
not work correctly if a different Java environment version is used
due to your PATH definition.
Selecting the VM
As noted in the Introduction, this kit contains
two virtual machines. The following sections describe how to control
which virtual machine your application uses.
VM Options
SDK v 1.3.1 lets you control which virtual machine your application
uses, based on the following options:
|
|
|
-fast, -fast32 |
-fast and -fast32 perform
the same operation. This is the default option and instructs
the java command to use the Fast VM, using 32-bits
to store pointers into objects. |
-fast64 |
Instructs the Fast VM to use 64-bits for pointers. |
-classic |
Directs the java command to use the
classic virtual machine (classic VM, the virtual machine shipped
with prior releases). The classic VM is based on Sun's reference
implementation. |
Using the Classic VM with Java 2 Development
Tools
By default, the Fast VM is used when running the Java 2 development
tools (for example, javac, javadoc,
javap, jar, appletviewer,
and so on). You can also use the classic VM by specifying the
-classic option when you invoke the tool. For example, the
following command uses the classic VM when running the appletviewer:
appletviewer -classic runtest.html
The Classic VM Environment Variable
You can also use the classic VM by defining the environment variable
JAVA_CLASSIC_VM. If this environment variable is defined,
the classic VM is always used when the java command
or the Java tools are invoked even if -classic is not
specified.
The Fast VM 64-bit
Addressing Environment Variable
To use the Fast VM (with 64-bit pointers), you can define the new
environment variable JAVA_FAST64_VM. If you do not
define this environment variable, by default the Fast VM is invoked
in 32-bit mode.
Setting both environment variables, JAVA_CLASSIC_VM
and JAVA_FAST64_VM, invokes the Fast VM in 64-bit mode.
Note that using a 'java'
command line option overrides the setting of a Java virtual
machine environment variable.
If you neither set an environment variable nor specify a command
line option, the Fast VM with 32-bit pointers is invoked by default.
Command Line Options
Standard Options
The java command supports all standard
options, as described on Sun's site. SDK v 1.3.1 includes the
Fast VM, which is designed for high performance on Tru64 UNIX Alpha
systems rather than Sun's HotSpot virtual machine. The -hotspot
standard option is silently ignored. For more information, refer
to Restrictions.
Non-Standard Options
By default, the java command supports most non-standard
options, as described on Sun's site. The following options are
supported by the classic VM and not by the Fast VM: -Xdebug,
-Xnoclassgc, and -Xrunhprof. If your application
uses one of these options, you must use the classic VM by specifying
the -classic option. -Xprof is not supported;
however, -Xrunhprof is available for classic VM profiling.
Additional Options
In addition to Sun's options, the java command supports
the following options:
|
|
|
-fast, -fast32
|
-fast and -fast32
perform the same operation. This is the default option and instructs
the java command to use the Fast VM, using 32-bits
to store pointers into objects. |
-fast64 |
Instructs the Fast VM to use
64-bits for pointers. |
-taso |
Load the executable in 31-bit
addressable address range. |
-client |
Initializes the Fast VM with
a maximum heap size of 64 MB, a maximum global region size of
128 MB and the compacting collector. Refer to Reducing
Fast VM Memory Requirements for Workstations and Client-side
Applications for more information. |
-Xglobal<size> |
Specifies the global region
maximum allocation size. The global region contains class definitions,
string constants, and other data internal to the VM. -Xglobal
can be used to override the default size of 240 MB or the -client
setting of 128 MB. Refer to Reducing Fast
VM Memory Requirements for Workstations and Client-side Applications
for more information. |
-Xgc:compacting |
Instructs the Fast
VM to use the alternative compacting garbage collector, which
compacts live data in-place, rather than copying it as the default
collector does. This collector is a hybrid mark-sweep/mark-compact
collector, which will avoid moving data when it is not necessary.
(See also Dynamic Heap Management.)
|
-Xgc:copying |
Instructs the Fast VM to use
the default "copying" garbage collector. |
-Xmp |
When used with the compacting
garbage collector, this specifies the minimum percentage
of heap space that the collector should try to free for new
objects. Thus, it dictates when a full compaction must occur,
rather than a sweep or minor compaction. Values from 0 to 100
may be specified in the form -Xmpnn, for example,
-Xmp25. The default value is 25. |
Tuning and Performance
Refer to the following sections (Memory Usage,
Reducing Fast VM Memory Requirements for Workstations
and Client-side Applications, Dynamic
Heap Management, Controlling Stack Size,
Using the Fast VM for Applications
Requiring a Large Virtual Address Space, Applications
Using a Large Number of Threads, and Swap
Space Problems) for specific tuning and performance information.
Memory Usage
The Fast VM has been tuned for large memory systems and, in addition,
a number of tradeoffs have been made that favor speed of execution
over memory usage. As a result, the Fast VM uses more physical and
virtual memory for the same application, often as much as 50% more.
This can lead to excessive paging and degraded performance if the
system is not tuned correctly or if there is insufficient physical
memory on the system. If you notice that your application runs more
slowly with the Fast VM than with the classic JIT, you should do
the following:
- Experiment with explicit
-Xmx and -Xms
values rather than letting the Fast VM pick the defaults. (See
Dynamic Heap Management.)
- Increase process quotas based on the amount of available physical
memory.
- Add physical memory.
Note that a smaller heap that results in more garbage collections
is preferable to allowing your application to page fault too often
due to a large heap size. For more information on system tuning
and resource limits, see the following:
Reducing Fast VM Memory Requirements for
Workstations and Client-side Applications
The Fast VM is optimized for large, long-running programs running
on server systems. Many users would like to use the Fast VM on their
workstations for client-side applications; however, some of these
systems do not have the resources to start up the Fast VM with its
default configuration. A -client switch addresses these
needs.
The client configuration significantly reduces the Fast VM memory
footprint.
The -client switch is a convenience switch, analogous
to setting the following switches on a command line:
java -Xmx64m -Xglobal28m -Xgc:compacting
The individual switch settings that make up the -client
switch can be overridden. For example:
java -client -Xmx256m
will initialize the Fast VM with a maximum heap size of 256 MB,
with a maximum global region size of 128 MB, and with the compacting
collector.
Dynamic Heap Management
Rather than use fixed values for the default settings for the memory
allocation pool (Java heap), the Fast VM determines the defaults
for the initial heap size (-Xms) and the maximum heap
size (-Xmx) dynamically based on the environment in
which it is executing as shown below:
max_memory = min (physical memory on machine, total memory available to the process)
default initial heap size = 10% of max_memory
default maximum heap size = 60% of max_memory
By setting heap size defaults automatically, the Fast VM adjusts
the heap size based on the available amount of memory. This generally
produces better results than specifying fixed -Xmx
and -Xms values, especially for an application that
is executed on different systems with varying amounts of memory.
It is sometimes possible to obtain better results by specifying
-Xmx and -Xms rather than letting the
Fast VM pick the defaults. To determine what values to use you should
use the -verbosegc command line option to monitor your
application's heap activity. If you notice that many garbage collections
are occurring, increase the heap size as much as possible without
causing excessive page faults. See Memory Usage
for additional information.
-Xgc:compacting
The Fast VM supports an alternative compacting garbage collector,
which compacts live data in-place, rather than copying it as the
default collector does. This collector is a hybrid mark-sweep/mark-compact
collector, which will avoid moving data when it is not necessary.
You can use the -Xgc:compacting
switch to enable the compacting garbage collector. This can significantly
improve performance characteristics for applications with long-lived
data. This is also a multi-threaded collector, so it can scale very
well on multiprocessors.
Benefit: This collection scheme can have better performance
characteristics and lower heap size requirements for applications
in which the heap contains a high percentage of long-lived data.
This collector can also perform minor collections, rather than collecting
the entire heap, when the percentage of live data is moderate. It
can also perform sweeps, which free space without moving any data
at all. Thus, it may also provide performance advantages for certain
applications with a moderate amount of long-lived data, but a high
rate of short-lived object turnover.
To use the compacting collector, specify the -Xgc:compacting
option on the command line. The -Xgc:copying
option causes the Fast VM to use the default "copying"
collector.
Controlling Stack Size
By default, the native stack size for Java threads on Tru64 UNIX
systems is approximately 512 KB. You can increase or decrease the
native stack size using the -Xssn command
line switch. Note that decreasing the native thread stack size can
save memory but can also result in stack overflow exceptions if
the native thread stacks are too small.
Example:
java -Xss256k MyApp
Using the Fast VM for Applications
Requiring a Large Virtual Address Space
By default, the Fast VM uses 32-bits to store pointers in objects,
which limits the amount of virtual memory available to Java applications.
With the default, the memory allocation pool (Java heap) is limited
to about 3 GB. The Fast VM provides an option to use 64-bits for
pointers, which significantly increases the amount of memory available
to Java applications. To use the 64-bit option, specify java -fast64 or define the new environment variable JAVA_FAST64_VM.
Applications Using a Large Number of Threads
If you experience a "java.lang.OutOfMemoryError" when
attempting to create a large number of threads, consider increasing
the proc subsystem attribute, max_threads_per_user.
This attribute allows you to increase the maximum number of threads
that can be allocated at any one time to each user, except superuser.
The Tru64
UNIX Best Practice guide recommends the following:
The default value of the max_threads_per_user attribute
is based on the value of the maxusers attribute,
so you can increase the maximum number of threads by increasing
the maxusers attribute. You can also explicitly increase
the maximum number of threads by increasing the max_threads_per_user
attribute.
Use a value that is equal to or greater than the maximum number
of threads that are allocated at one time on the system. For example,
you could increase the value of the max_threads_per_user
attribute to 512. On a busy server with sufficient memory or an
Internet server, increase the value of the max_threads_per_user
attribute to 4096. If the value of the max_threads_per_user
attribute is 0 (zero), there is no limit on threads; this is not
recommended.
You must reboot the system to use the new value of max_threads_per_user.
Swap Space Problems
If you see one of the following messages:
"Unable to obtain requested swap space"
"swap space below 10 percent free"
your machine may be low on swap space and require some system tuning
to correct the problem. Note that the Fast VM, which is the default,
requires more memory than the classic VM, so you might not have
received these messages in the past. You can reduce the Fast VM's
memory requirements by using the -client option (see
Reducing Fast VM Memory Requirements for Workstations
and Client-side Applications), by using the -Xglobal<size>
option to specify a smaller global region size, or by using the
-Xmx<size> option to specify a smaller heap size.
Another option is to use the classic VM by specifying -classic,
which runs slower but requires less memory. Please see the Tru64
UNIX System Configuration and Tuning manual. For Tru64
UNIX V5.1B systems, the following sections may be helpful (similar
sections would apply for other versions):
- 4.4.1.8 Modifying the Swap Allocation Mode
- 12.2 Configuring Swap Space for High Performance
- 12.3.3 Displaying Swap Space Usage by Using the swapon Command
Creating a VM in C/C++ Programs Using
the Invocation API
By default, this release supports the ability to create and invoke
the Fast VM in C/C++ programs using the Invocation API. The Invocation
API is an integral part of the Java Native Interface (JNI) that
allows you to initialize virtual machine arguments, create, and
load a virtual machine into your application, and then unload or
destroy the virtual machine. For additional information about the
Invocation API and how to use it, refer to the Sun
JNI specification on Sun's site.
To take advantage of the Invocation API functionality, your C/C++
program (new and existing programs) must first create the virtual
machine so that the Java code can be executed. Once the virtual
machine is embedded into the program, the program can then load
Java classes and execute Java methods. Assume that you have a C++
program called invokejvm.cxx: This program creates
a virtual machine and then calls a Java method. The following is
an example of a C++ command line that compiles and links a C++ program
that invokes the Fast VM:
cxx -pthread \
-I/usr/opt/java131/include \
-I/usr/opt/java131/include/alpha \
invokejvm.cxx \
/usr/opt/java131/jre/lib/alpha/fast64/libjvm.so \
-o invokejvm
Note that all C/C++ code compiled for use with JNI must be built
(compiled and linked) with the C/C++ -pthread
flag. Otherwise, your application will encounter severe multithreading
problems, even if your Java and C/C++ code does not explicitly use
threads. For more information about the -pthread
flag, please see the C/C++ manpages.
Before running the resulting invokejvm, you must define
LD_LIBRARY_PATH so that the following shared library directories
are searched when loading the executable:
/usr/opt/java131/jre/lib/alpha/
/usr/opt/java131/jre/lib/alpha/fast64
/usr/opt/java131/jre/lib/alpha/native_threads
For example, you can do this using the following csh
commands:
setenv JLIB /usr/opt/java131/jre/lib/alpha
setenv LD_LIBRARY_PATH ${JLIB}:${JLIB}/fast64:${JLIB}/native_threads
If your C or C++ main program is built with the -xtaso
or -xtaso_short option to use 32-bit pointers, you
should substitute fast32 for fast64 in
the above cxx command line and LD_LIBRARY_PATH
definition.
Using the Plug-in
Plug-in v 1.3.1 enables users to run Java applets and JavaBeans
components on web pages using the RTE as an alternative to using
the default Virtual Machine for Java 2 that comes with the web browser.
It is based on the Java Plug-in 1.3.1 provided by Sun Microsystems
and contains similar functionality.
For additional information on topics such as Java Plug-in security,
using Signed Applets, JNI and the Java Plug-in, using the Java Plug-in
in Intranet Environments, and how Proxy Configuration works in the
Java Plug-in, please see the Sun
Microsystems Java Plug-in 1.3 Documentation web site; the documentation
is the same for Java Plug-in 1.3.1.
Note: You must be running Netscape Communicator 4.51 or
higher, or Mozilla 0.7 or higher.
Installing the Plug-in
For Netscape 4.x browsers:
Set the NPX_PLUGIN_PATH environment variable to the
location of the Plug-in (the directory in which the javaplugin.so
file is located):
NPX_PLUGIN_PATH=/usr/opt/java131/jre/plugin/alpha/ns4
For Mozilla and Netscape 6.x browsers:
Create a symbolic link in the browser's plugins directory
to the path of the libjavaplugin_oji.so file. This
file is located at /usr/opt/java131/jre/plugin/alpha/ns600/libjavaplugin_oji.so.
For example:
cd ${MOZILLA}/plugins
ln -s /usr/opt/java131/jre/plugin/alpha/ns600/libjavaplugin_oji.so
Start your browser, or restart it if it is already running.
Restart your browser a second time. (This is a workaround to a
browser bug.)
Converting Your HTML Pages
The Plug-in does not replace Navigator's underlying Virtual Machine
for Java 2. Rather, it enables you to specify the use of the RTE
instead of the default Navigator Virtual Machine for Java 2.
To use the Plug-in (instead of the browser's default Java environment
version) when Netscape Navigator® browses a web page, you need
to modify your web page source file(s). You can do this manually,
using the OBJECT tag and the EMBED tag in your HTML specification.
Alternatively, you can use the HTML Converter to automate modifications
of your web page source files. For more information on HTML web
page changes required by the Plug-in, see Sun's
Java Plug-in HTML Specification.
The Plug-in HTML Converter
The HTML Converter easily and automatically modifies HTML pages
to specify the use of the Plug-in
rather than the browser's default Java runtime. The SDK v 1.3.1
kit provides the Plug-in HTML Converter so that a separate download
is not required.
To run the GUI version of the HTML Converter, invoke the following
command:
/usr/opt/java131/bin/HtmlConverter -gui
To run the command line version of the HTML converter, invoke the
HTML Converter and specify the file to convert. For example:
/usr/opt/java131/bin/HtmlConverter file.html
For more information about the HTML Converter, see Sun's
Java Plug-in HTML Converter Features and Sun's
Plug-in HTML Converter Installation and Use web pages.
The Plug-in Control Panel
A Plug-in Control Panel lets you change Plug-in options such as
proxies and enabling of the console window. It also allows you to
switch the RTE version you want to run with your Plug-in. To run
the Control Panel, enter the following command:
/usr/opt/java131/jre/bin/ControlPanel
Or you can use the Netscape Navigator browser to visit the Control
Panel applet page that was installed as /usr/opt/java131/jre/bin/ControlPanel.
For example:
netscape /usr/opt/java131/jre/ControlPanel.html
Some of the Control Panel features are discussed below. Please
refer to Sun's
Java Plug-In Control Panel web page for information about additional
features and uses of the Java Plug-in Control Panel.
Selecting the
VM to Use in the Plug-in
By default, the Fast VM is used when running the Plug-in. You can
have the Plug-in use the classic VM by defining the environment
variable JAVA_PLUGIN_CLASSIC_VM prior to running your
web browser.
To use the Fast VM (with 64-bit pointers), you can define the
environment variable JAVA_PLUGIN_FAST64_VM. If you
do not define this environment variable, by default the Fast VM
is invoked in 32-bit mode.
Setting both environment variables, JAVA_PLUGIN_CLASSIC_VM
and JAVA_PLUGIN_FAST64_VM, invokes the Fast VM in 64-bit
mode.
If you don't set an environment variable, the Fast VM with 32-bit
pointers is invoked by default.
Viewing Tracing Information
You can view a moderate amount of Plug-in tracing information
in Netscape Alert Panels by setting the JAVA_PLUGIN_TRACE
environment variable. If you set JAVA_PLUGIN_TRACE
and want the output to go to the standard output/error (usually
your terminal window), edit the following lines in your .Xdefaults
or .Xresources file in your home directory.
Change "True" to "False":
*useStderrDialog: False
*useStdoutDIalog: False
Then reload resources by typing the following command:
xrdb -merge .Xdefaults
Displaying Java Error Messages
To see Java error messages:
- 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.
Font Support
The SDK includes the following font support.
Role of the font.properties
File
Starting with SDK v 1.2.1, Java applications require a font property
file to properly display the application's AWT windowing and Java2D
components. This file contains mappings of Java logical font names
to physical fonts on the X server. With SDK v 1.3.1, a font.properties
file is installed by this kit in jre/lib/font.properties,
which identifies fonts that should be available on your X server.
If you prefer to use fonts other than those that have been predefined
by the property file for your use, copy the file installed by this
kit from jre/lib/font.properties to your $HOME directory
and modify it. When a Java application is run, it will use your
local font property file instead of the one installed by this kit.
Multiple font.properties
Files Provided
It is difficult to supply a font.properties file that
is ideal for use in all environments. As a result, this kit contains
two font.properties files:
font.properties
This is the default font.properties file and generally
should work fine for displaying your application.
font.properties.rotation
This alternate font.properties file has been modified
for your use if your application uses Java2D features such as
displaying rotated text. This file uses TrueType fonts supplied
by Sun that ship with the Java 2 SDK. Not all of the fonts in
this property file support the display of rotated text. Only
the "SansSerif" and "Monospaced" font families were changed
to use Sun's fonts.
If your application displays text as rotated, you will need
to follow a few simple steps in order to successfully use this
Java2D feature. In your program, for all of the occurrences
of text that you wish to display as rotated, you will need to
call the setFont() method to change the font name
for the text to "SansSerif" or to "Monospaced". Additionally,
you will need to use this font property file on a user local
or system-wide basis.
Both of the font property files shipped with SDK v 1.3.1 kit reside
in /usr/opt/java131/jre/lib/. The one actually named
font.properties is the one that will be used. This
file is a system-wide file and is used for the display of all Java
programs that are run on that system. The SDK supports local customizations
of the font property file which can take affect on a user or system-wide
basis. When the Java runtime needs to find a font.properties
file, it starts its search in $HOME. A local version
of the font.properties file takes precedence over a
system-wide version. Therefore, you can make either of these two
files your user local font.properties by copying the
font.properties file of your choice to a file named
font.properties in $HOME.
Alternatively, if you want to use the font.properties.rotation
file as a system-wide file for use by all users on the system (thus
overriding the default font.properties file), perform
the following steps:
% cp /usr/opt/java131/jre/lib/font.properties \
/usr/opt/java131/jre/lib/font.properties.orig
% cp /usr/opt/java131/jre/lib/font.properties.rotation \
/usr/opt/java131/jre/lib/font.properties
If later you wish to revert to the original file that shipped
with SDK v 1.3.1, you would copy font.properties.orig
to font.properties.
If you prefer to use fonts other than those that have been predefined
by the font properties file for your use, copy the file installed
by this kit from /usr/opt/java131/jre/lib/font.properties
to your $HOME directory and modify it. When a Java
application is run, it will use your local font properties file
instead of the one installed by this kit.
Retired Fonts
Starting with Tru64 UNIX V4.0F, all Adobe fonts under /usr/lib/X11/fonts/Type1Adobe
are retired and no longer ship with the operating system.
If your Java application used the retired Type1Adobe outline fonts,
it might be affected. For example, when characters are displayed
on the screen, they might not scale as expected. If you customized
your font.properties file to use these outline fonts, you might
need to modify it to use alternative fonts that are available on
your operating system. No replacements are being provided by the
operating system. However, a smaller set of outline fonts is still
available in /usr/lib/X11/fonts/Type1 and /usr/lib/X11/fonts/Speedo
for your use.
Troubleshooting Font Problems
If you encounter one of the following warnings, you are probably
referencing a font in your font.properties file that
is not available on your system. Check your font path by issuing
the UNIX command xset -q. If your display is not what
you expect, you might need to change the search order. Also, make
sure that the font property file does reference fonts that are installed
on your system; you may be attempting to use a font that is not
available.
"Font specified in font.properties not found [-*-helvetica-bold-r-normal...]"
If you are having problems with fonts when you display remotely
to a PC using eXcursion™, you might need to upgrade to a newer
version of the eXcursion software and install additional fonts.
Also, make sure that the font property file references fonts that
are installed on your PC.
Screen Resolution Display
Problems
Font display problems can occur when running Java applications
and displaying to systems that use certain graphics cards. Specifically,
the fonts will appear jagged due to improper scaling. This problem
is typically seen on graphics cards that default to a screen resolution
of 1024x768. For example, the PowerStorm 4D10T (also known as the
ELSA Gloria Synergy) card has the problem. These cards typically
support higher screen resolutions but default to a lower resolution
to support smaller monitors.
There are two workarounds to this font scaling problem. Both involve
editing the X Server configuration file /usr/var/X11/Xserver.conf,
which contains startup information for the X Server. Note that on
a Tru64 UNIX V5.x system, this file is a context-dependent symbolic
link (CDSL). In a cluster environment, there exists one version
of this file per cluster member. Be sure to make the edits on the
appropriate cluster member or using an explicit path such as:
/usr/var/cluster/members/memberN/X11/Xserver.conf
where N is the appropropriate member number.
The two workarounds are:
- 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
- Tell the X Server to use either 100 dpi or 75 dpi fonts explicitly.
For example, by default, a 1024x768 monitor is configured to use
75 dpi fonts. Tell the X Server to operate at 75 explicitly:
- Edit the file
/usr/var/X11/Xserver.conf and
search for the following lines, which are typically at the bottom
of the file:
! you specify command line arguments here
args <
-pn
>
- Add
-dpi 75 after the -pn option.
For example:
-pn
-dpi 75
Typically, 75 dpi is a good choice for monitors with a resolution
of 1024x768. If you would like the fonts to be uniformly larger,
use 100 dpi fonts by specifying -dpi 100.
For more detailed information on changing X Server screen settings,
refer to section "Adjusting Your Screen Settings" of the
Tru64
UNIX Best Practice guide.
Window Managers Supported by the
SDK
The CDE desktop window manager (dtwm), and the Motif window manager
(mwm), are fully supported. You may also use the DIGITAL eXcursion™
window manager when running your Java application on a Tru64 UNIX
system and redirecting the display back to a PC.
Non-standard window managers such as fvwm and
twm are not supported. Therefore, you may experience
some unusual behavior when using them.
Restrictions
- The SDK v 1.3.1 kit does not include support for Sun's HotSpot™
virtual machine.
- Native methods used with the Fast VM must conform to the Java
Native Interface (JNI) specification, as described on Sun's
site. The Fast VM does not support native method conventions older
than the JNI specification.
Documentation and Other Information
Documentation
If the optional documentation subset (JAVADOC131) is installed,
then the SDK documentation tree begins at the following location
on the system where the SDK is installed:
/usr/opt/java131/docs/index.html
The installed documentation is in HTML format and includes this
release notes file (which describes SDK information specific to
Tru64 UNIX systems).
Note: The documentation in JAVADOC131 does
not include the API reference documentation. If you want to
use the API reference documentation locally, download and install
the separate javaapidoc131-7.tar file as described
in the Installation section. Browse the
API documentation using the following location:
/usr/opt/java131/docs/api/index.html
Also, you can browse the Software
Documentation page on our Web site.
There is also a java manpage that describes the java
command and points to the installed documentation. The java
manpage ships with the operating system and describes the Java environment
version that was shipped; the manpage is not updated by this kit.
More Information
For more information on this release, refer to the Release
Notes for the J2SDK v 1.3.1 software from Sun Microsystems,
and our Frequently
Asked Questions (FAQ) web page.
If you are new to the Java programming language, you will want
to browse or download the Java
Tutorial on Sun's site.
Problem Reporting
To report problems, refer to our Software
Support web page.
|
