![]() |
![]() |
United States-English | ![]() |
|
|
![]() |
![]() |
![]() Release NotesSoftware Development Kit (SDK) v 1.4.2-4 |
![]() |
Installing the API Reference DocumentationYou can also download and install the API reference documentation
for SDK v 1.4.2. 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.2 API Specification on Sun's
site.
Determining Your Installed VersionAfter you have installed SDK v 1.4.2, the % /usr/opt/java142/bin/java -version java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition Fast VM (build 1.4.2-4, native threads, mixed mode, ...) Deinstalling the SDK v 1.4.2 KitIf you want to deinstall this kit in the future, perform the following
steps as
Deinstalling Other VersionsTo deinstall other versions, perform the following steps as
For example: % setld -i | grep JAVA | grep installed JAVA131 installed Java 1.3.1-7 Environment (General Applications) JAVADEV131 installed Java 1.3.1-7 Development Environment JAVADOC131 installed Java 1.3.1-7 Online Documentation % setld -d JAVA131 JAVADEV131 JAVADOC131 Making SDK v 1.4.2 the Default System Java Environment VersionNote: Use caution when changing the default system Java environment version to SDK v 1.4.2 for the following reason:
See Using SDK v 1.4.2 for more information on using SDK v 1.4.2 when it is not the default system Java environment version. When you make SDK v 1.4.2 the default system Java environment
version, system files such as
To switch the default system Java environment version from SDK v 1.4.2 back to SDK v 1.1.8, use the following commands:
Troubleshooting Multiple VersionsIf 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 printenv PATH printenv CLASSPATH If you encounter the error Contents of the SDKThis 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 Run Time Environment (RTE) (In the Additional Libraries(In the Demo Applets and Applications(In the
C Header Files(In the Source Code (In 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:
This section provides descriptions of the known issues and limitations in the SDK; they include the following:
The following sections provide useful information and tips for using the SDK on Tru64 UNIX systems. Using SDK v 1.4.2In most cases, SDK v 1.4.2 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.2:
Changing Your
|
Option | Function |
-fast, -fast32 | -fast and -fast32 perform
the same operation. This is the default option and instructs
the java command to use the Fast VM, using 32-bits
to store pointers into objects. |
-fast64 | Instructs the Fast VM to use 64-bits for pointers. |
-classic | Directs the java
command to use the classic virtual machine (classic VM, the
virtual machine shipped with prior releases). The classic VM
is based on Sun's reference implementation. |
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.2 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 nonstandard
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.
Option | Function |
-fast, -fast32 |
|
-fast64 |
Instructs the Fast VM to use 64-bits for pointers. |
-classic |
Directs the |
-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> | The option, -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 256M, or up
to 1024M when using -fast64 . The default value
is -Xcode32M . |
-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. Note:
The -Xdynclassgc option is supported on Tru64 UNIX
version 5.1A and above only. 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. |
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.) |
|
Instructs the Fast VM to use the "copying" garbage collector. (See also Fast VM Garbage Collection Options.) |
|
Instructs the
Fast VM to perform a full garbage collection when an explicit
garbage collector call is made ( |
|
Instructs the Fast VM to ignore explicit garbage collector calls. |
|
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 |
|
-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.) |
The following functionalities either work differently on other UNIX platforms than they do on Tru64 UNIX, or Tru64 UNIX does not support them.
This kit provides /usr/opt/java142/jre/lib/font.properties.zh_GB18030
and /usr/opt/java142/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.
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
option is silently ignored, and the
-Xincgc
option is not supported. This tuning option
is specific to Sun's HotSpot™ virtual machine.Java Sound is not supported. The following error is reported if you attempt to use Java Sound:
Java Sound support not currently available.
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, Address Space Problems, and Fast VM Lock Initialization Options.
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:
-Xmx
and -Xms
values rather than letting the Fast VM pick the defaults. (See
Dynamic Heap Management.) 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:
limit
and unlimit
,
specifically addressspace setrlimit(2)
and getrlimit(2)
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. Note: The
-Xdynclassgc
option is supported on Tru64 UNIX version
5.1A and above only.
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.
This section describes the Fast VM Garbage Collection (GC) profiling options, which allow you to get heap dumps and allocation profiles at each garbage collection.
Option | Function |
Print an object allocation profile after each garbage collection |
|
Print output of all |
|
Print pre- and post-garbage collection heap profiles |
|
Print pre-garbage collection heap profile |
|
Print post-garbage collection heap profile |
-
Xverbosegc:file:<filename>
This option allows a file to be specified to which the output of
all of the -Xverbosegc
options given on the command
line will be printed, instead of to the terminal.
-Xverbosegc:heap,-Xverbosegc:heap_pre,-Xverbosegc:heap_post
These options print heap profiles, sorted in descending order by
bytes allocated of each object type in each size range, at each
garbage collection. -Xverbosegc:heap
prints a profile
both before and after the collection, while heap_pre
and heap_post
allow you to specify only one or the
other. For example, the output at the third garbage collection when
running the SPECjbb2000 benchmark with the -verbose
and -Xverbosegc:heap
options and an initial/maximum
heap size of 4 MB looks like:
--- Pre-GC Profile --- Bytes Objects Sizeof Space% Cum% Type 537760 5729 64-512 28.25% 28.25% [C 312160 5877 8-64 16.40% 44.65% [C 279000 11625 24 14.66% 59.31% java/lang/String 119624 13 4K-32K 6.28% 65.60% [B 85152 2661 32 4.47% 70.07% spec/jbb/Item 85088 2659 32 4.47% 74.54% spec/jbb/infra/Collections/nodeKeyRef 65600 4 4K-32K 3.45% 77.99% [C 60816 759 64-512 3.20% 81.18% [Ljava/lang/Object; 55120 381 64-512 2.90% 84.08% [J 49672 60 512-4096 2.61% 86.69% [B 32784 1 32K-256K 1.72% 88.41% [Ljava/lang/Object; 30408 153 64-512 1.60% 90.01% [I 29216 332 88 1.53% 91.54% java/util/SimpleTimeZone 26352 1098 24 1.38% 92.93% java/util/Hashtable$Entry 12128 379 32 0.64% 93.56% spec/jbb/infra/Collections/longBTreeNode 8080 1 4K-32K 0.42% 93.99% [S 7384 219 8-64 0.39% 94.38% [I 6912 144 48 0.36% 94.74% java/util/HashMap 6328 2 512-4096 0.33% 95.07% [Ljava/util/Hashtable$Entry; 6144 256 24 0.32% 95.40% java/util/HashMap$Entry 5600 174 8-64 0.29% 95.69% [B 4368 138 8-64 0.23% 95.92% [Ljava/util/HashMap$Entry; 4016 1 512-4096 0.21% 96.13% [[B 3952 82 8-64 0.21% 96.34% [Ljava/lang/Object; 3800 95 40 0.20% 96.54% java/math/BigInteger 3640 4 512-4096 0.19% 96.73% [Ljava/lang/Object; 3232 12 64-512 0.17% 96.90% [B 2608 14 64-512 0.14% 97.04% [Ljava/util/Hashtable$Entry;
...
<GC: Garbage Collection #3 with 4.00 MB Heap> <GC: Time since last collection : 0.63 seconds> <GC: Time spent collecting : 0.05 seconds> <GC: Data live before collection : 1.96 MB> <GC: Data live after collection : 1.22 MB> <GC: Data pinned during collection : 0.27 MB> --- Post-GC Profile --- Bytes Objects Sizeof Space% Cum% Type 274120 2929 64-512 25.49% 25.49% [C 154536 2908 8-64 14.37% 39.86% [C 141144 5881 24 13.13% 52.99% java/lang/String 85152 2661 32 7.92% 60.91% spec/jbb/Item 65600 4 4K-32K 6.10% 67.01% [C 60640 758 64-512 5.64% 72.65% [Ljava/lang/Object; 55120 381 64-512 5.13% 77.78% [J 32832 4 4K-32K 3.05% 80.83% [B 32784 1 32K-256K 3.05% 83.88% [Ljava/lang/Object; 29216 332 88 2.72% 86.59% java/util/SimpleTimeZone 25872 1078 24 2.41% 89.00% java/util/Hashtable$Entry 13136 16 512-4096 1.22% 90.22% [B 12128 379 32 1.13% 91.35% spec/jbb/infra/Collections/longBTreeNode 8080 1 4K-32K 0.75% 92.10% [S 7296 216 8-64 0.68% 92.78% [I 6328 2 512-4096 0.59% 93.37% [Ljava/util/Hashtable$Entry; 5952 124 48 0.55% 93.92% java/util/HashMap 5664 236 24 0.53% 94.45% java/util/HashMap$Entry 3800 95 40 0.35% 94.80% java/math/BigInteger 3744 33 64-512 0.35% 95.15% [I 3640 4 512-4096 0.34% 95.49% [Ljava/lang/Object; 3248 118 8-64 0.30% 95.79% [Ljava/util/HashMap$Entry; 3232 12 64-512 0.30% 96.09% [B 2544 1 512-4096 0.24% 96.33% [I 2504 13 64-512 0.23% 96.56% [Ljava/util/Hashtable$Entry; 2080 130 16 0.19% 96.75% java/util/jar/Attributes$Name
...
-Xverbosegc:alloc
This option tells the Fast VM to keep track of allocation points and to compile a list of how many objects/bytes of what type are allocated at each call site. An object allocation profile, sorted in descending order by bytes allocated, is printed after each garbage collection report. The object allocation profile is cumulative up until each garbage collection, and starts over again after each garbage collection. By default, the output goes to the terminal. The output tends to wrap because of fully specified method names in the method call information for every call site, so a wide terminal window is optimal for viewing these stack traces.
For example, the output of the second garbage collection report
and object allocation profile when running the SPEC JVM98 benchmarks
with the -Xverbosegc:alloc
option and an initial/maximum
heap size of 4 MB begins with:
<GC: Garbage Collection #2 with 4.00 MB Heap> <GC: Time since last collection : 4.06 seconds> <GC: Time spent collecting : 0.03 seconds> <GC: Data live before collection : 1.96 MB> <GC: Data live after collection : 0.77 MB> <GC: Data pinned during collection : 0.23 MB> Object Allocation Profile #2: objects bytes alloc% class --------------------------------- 1 160016 8.8% [I 46: spec/benchmarks/_205_raytrace
/Canvas.<init>(II) 61: spec/benchmarks/_205_raytrace
/RayTracer.run([Ljava/lang/String;) 2: spec/benchmarks/_205_raytrace
/RayTracer.inst_main([Ljava/lang/String;) 65: spec/benchmarks/_227_mtrt
/Main.runBenchmark([Ljava/lang/String;) 1: spec/benchmarks/_227_mtrt
/Main.harnessMain([Ljava/lang/String;) 84: spec/harness/ProgramRunner.runOnce(Ljava
/lang/Object;IJILjava/util/Properties;) 481: spec/harness/ProgramRunner.runBenchmark2() 43: spec/harness/ProgramRunner.runBenchmark() 8: spec/harness/ProgramRunner.run() 221: spec/harness/RunProgram.run(Ljava/lang/
String;ZLjava/util/Properties;Lspc/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 themaxusers
attribute, so you can increase the maximum number of threads by increasing themaxusers
attribute. You can also explicitly increase the maximum number of threads by increasing themax_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 themax_threads_per_user
attribute to 4096. If the value of themax_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 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):
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:
ulimit
command, or by changing the default process stack size with the
sysconfig
utility.ulimit
-a
, and try increasing it.For further information, refer to Tru64 UNIX System Configuration and Tuning.
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/java142/include \ -I/usr/opt/java142/include/alpha \ invokejvm.cxx \ /usr/opt/java142/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/java142/jre/lib/alpha/ /usr/opt/java142/jre/lib/alpha/fast64 /usr/opt/java142/jre/lib/alpha/native_threads
For example, you can do this using the following csh
commands:
setenv JLIB /usr/opt/java142/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.
The SDK provides support for JNI applications that require the Tru64 UNIX Motif Version 2.1 Advanced Developer's Kit. To enable this support you need to set the environment variable _JAVA_AWT_USE_MOTIF_2_1 to any non-null value before running your application.
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.2 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.2 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 1.1 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 lib
javaplugin.so
file is located):
NPX_PLUGIN_PATH=/usr/opt/java142/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/java142/jre/plugin/alpha/ns610/libjavaplugin_oji.so
.
For example:
cd ${MOZILLA}/plugins
ln -s /usr/opt/java142/jre/plugin/alpha/ns610/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.2 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/java142/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/java142/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.
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/java142/jre/bin/ControlPanel
Or you can use the Netscape Navigator browser to visit the Control Panel applet page that was installed as /usr/opt/java142/jre/bin/ControlPanel. For example:
netscape /usr/opt/java142/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:
With the console window enabled, when you next visit a Plug-in enabled page, a separate window will come up to display error messages.
With Java Web Start, an application-deployment technology bundled with SDK v 1.4.2, 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.
Beginning with SDK v 1.4.2, Java Web Start is installed as part of the SDK; you no longer need to install it separately.
You launch Java Web Start by running the following:
/usr/opt/java142/jre/javaws/javaws
The SDK includes the following font support.
font.properties
FileStarting 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.2, 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.
font.properties
Files ProvidedIt 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.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.2 kit
reside in /usr/opt/java142/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/java142/jre/lib/font.properties \ /usr/opt/java142/jre/lib/font.properties.orig % cp /usr/opt/java142/jre/lib/font.properties.rotation \ /usr/opt/java142/jre/lib/font.properties
If later you wish to revert to the original file that shipped
with SDK v 1.4.2, 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/java142/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 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.
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.
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:
- 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
- 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.
Nonstandard 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 (JAVADOC142
)
is installed, then the SDK documentation tree begins at the following
location on the system where the SDK is installed:
/usr/opt/java142/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 JAVADOC142
does not include the API reference documentation. If you
want to use the API reference documentation locally, download and
install the separate javaapidoc142-4.tar
file as described
in Installing the API Reference Documentation.
Browse the API documentation using the following location:
/usr/opt/java142/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.
For more information on this release, refer to the Release Notes for the J2SDK v 1.4.2 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.
© 2003, 2005 Hewlett-Packard Development Company, L.P. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Hewlett-Packard shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is subject to change without notice. INFORMATION PROVIDED HEREWITH IS PROVIDED “AS IS” “WHERE IS” WITHOUT ANY WARRANTY WHATSOEVER. THE ENTIRE RISK ASSOCIATED WITH THE USE OF MATERIALS RESIDES WITH LICENSEE. ALL OTHER WARRANTIES, EITHER EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, ACCURACY, CONDITION, OWNERSHIP, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS. |
![]() |
|||||||||||||||
|