|
|
|
|
|||||||||||
|
|||||||||||
|
|
|||
|
 |
|
Release NotesSoftware Development Kit (SDK) v 1.4.1-2for the Tru64™ UNIX® Operating System for the Java™ Platform |
|
Using the Classic VM with Java 2 Development ToolsBy default, the Fast VM is used when running the Java 2 development
tools (for example, appletviewer -classic runtest.html The Classic VM Environment VariableYou can also use the classic VM by defining the environment
variable The Fast VM 64-bit Addressing Environment VariableTo use the Fast VM with 64-bit pointers, define the environment
variable Setting both environment variables, 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 OptionsStandard OptionsThe Non-Standard OptionsBy default, the Additional OptionsIn addition to Sun's options, the
|
| 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_postThese 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:allocThis option tells the Fast VM to keep track of allocation points and to compile a list of how many objects/bytes of what type are allocated at each call site. An object allocation profile, sorted in descending order by bytes allocated, is printed after each garbage collection report. The object allocation profile is cumulative up until each garbage collection, and starts over again after each garbage collection. By default, the output goes to the terminal. The output tends to wrap because of fully specified method names in the method call information for every call site, so a wide terminal window is optimal for viewing these stack traces.
For example, the output of the second garbage collection
report and object allocation profile when running the SPEC
JVM98 benchmarks with the -Xverbosegc:alloc option
and an initial/maximum heap size of 4 MB begins with:
<GC: Garbage Collection #2 with 4.00 MB Heap>
<GC: Time since last collection : 4.06 seconds>
<GC: Time spent collecting : 0.03 seconds>
<GC: Data live before collection : 1.96 MB>
<GC: Data live after collection : 0.77 MB>
<GC: Data pinned during collection : 0.23 MB>
Object Allocation Profile #2:
objects bytes alloc% class
---------------------------------
1 160016 8.8% [I
46: spec/benchmarks/_205_raytrace/Canvas.<init>(II)
61: spec/benchmarks/_205_raytrace/RayTracer.run([Ljava/lang/String;)
2: spec/benchmarks/_205_raytrace/RayTracer.inst_main([Ljava/lang/String;)
65: spec/benchmarks/_227_mtrt/Main.runBenchmark([Ljava/lang/String;)
1: spec/benchmarks/_227_mtrt/Main.harnessMain([Ljava/lang/String;)
84: spec/harness/ProgramRunner.runOnce(Ljava/lang/Object;IJILjava/util
/Properties;)
481: spec/harness/ProgramRunner.runBenchmark2()
43: spec/harness/ProgramRunner.runBenchmark()
8: spec/harness/ProgramRunner.run()
221: spec/harness/RunProgram.run(Ljava/lang/String;ZLjava/util/Properties
;Lspec/harness/BenchmarkDone;)
16: SpecApplication.runBenchmark(Ljava/lang/String;Z)
609: SpecApplication.main([Ljava/lang/String;)
1695 138064 7.6% [C
56: java/lang/String.<init>([CII)
7: java/lang/String.copyValueOf([CII)
202: java/io/DataInputStream.readLine()
304: spec/benchmarks/_205_raytrace/Scene.ReadPoly(Ljava/io/DataInputStream;I)
186: spec/benchmarks/_205_raytrace/Scene.LoadSceneOrig(Ljava/lang/String;)
8: spec/benchmarks/_205_raytrace/Scene.LoadScene(Ljava/lang/String;)
6: spec/benchmarks/_205_raytrace/Scene.<init>(Ljava/lang/String;)
11: spec/benchmarks/_205_raytrace/Runner.run()
1719 137904 7.6% [C
56: java/lang/String.<init>([CII)
7: java/lang/String.copyValueOf([CII)
202: java/io/DataInputStream.readLine()
202: spec/benchmarks/_205_raytrace/Scene.ReadPoly(Ljava/io/DataInputStream;I)
186: spec/benchmarks/_205_raytrace/Scene.LoadSceneOrig(Ljava/lang/String;)
8: spec/benchmarks/_205_raytrace/Scene.LoadScene(Ljava/lang/String;)
6: spec/benchmarks/_205_raytrace/Scene.<init>(Ljava/lang/String;)
11: spec/benchmarks/_205_raytrace/Runner.run()
3438 137520 7.5% java/lang/FloatingDecimal
...
In the second entry of the above object allocation profile,
1695 objects totaling 138064 bytes and of type [C
(array of char) were allocated with the call chain shown,
and account for 7.6% of the total bytes allocated from the
first up until the second garbage collection.
For primitive types, the type names are defined as follows:
V - void
B - byte
Z - boolean
C - char
S - short
I - int
F - float
J - long
D - double
For array types, the names shown are prefixed with [.
For object types, the names shown are prefixed with L.
Note: The overhead of allocation profiling will dramatically decrease your application performance.
By default, the native stack size for Java threads on Tru64
UNIX systems is approximately 512 KB. You can increase or
decrease the native stack size using the -Xssn
command line switch. Note that decreasing the native thread
stack size can save memory but can also result in stack overflow
exceptions if the native thread stacks are too small.
Example:
java -Xss512k MyApp
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_userattribute is based on the value of themaxusersattribute, so you can increase the maximum number of threads by increasing themaxusersattribute. You can also explicitly increase the maximum number of threads by increasing themax_threads_per_userattribute.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_userattribute to 512. On a busy server with sufficient memory or an Internet server, increase the value of themax_threads_per_userattribute to 4096. If the value of themax_threads_per_userattribute is 0 (zero), there is no limit on threads; this is not recommended.You must reboot the system to use the new value of
max_threads_per_user.
If you see one of the following messages:
"
Unable to obtain requested swap space"
"swap space below 10 percent free"
your machine may be low on swap space and require some system
tuning to correct the problem. Note that the Fast VM, which
is now the default, requires more memory than the classic
VM, so you might not have received these messages in the past.
You can reduce the Fast VM's memory requirements by using
the -client option (see Reducing
Fast VM Memory Requirements for Workstations and Client-side
Applications), by using the -Xglobal<size>
option to specify a smaller global region size, or by using
the -Xmx<size> option to specify a smaller
heap size. Another option is to use the classic VM by specifying
-classic, which runs slower but requires less
memory. Please see the Tru64
UNIX System Configuration and Tuning Manual. For
Tru64 UNIX V5.1 systems, the following sections may be helpful
(similar sections would apply for other versions):
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/java141/include \
-I/usr/opt/java141/include/alpha \
invokejvm.cxx \
/usr/opt/java141/jre/lib/alpha/fast64/libjvm.so \
-o invokejvm
Note that all C/C++ code compiled for use with JNI must
be built (compiled and linked) with the C/C++ -pthread
flag. Otherwise, your application will encounter severe multithreading
problems, even if your Java and C/C++ code does not explicitly
use threads. For more information about the -pthread
flag, please see the C/C++ manpages.
Before running the resulting invokejvm, you
must define LD_LIBRARY_PATH so that the following
shared library directories are searched when loading the executable:
/usr/opt/java141/jre/lib/alpha/ /usr/opt/java141/jre/lib/alpha/fast64 /usr/opt/java141/jre/lib/alpha/native_threads
For example, you can do this using the following csh
commands:
setenv JLIB /usr/opt/java141/jre/lib/alpha
setenv LD_LIBRARY_PATH ${JLIB}:${JLIB}/fast64:${JLIB}/native_threads
If your C or C++ main program is built with the -xtaso
or -xtaso_short option to use 32-bit pointers,
you should substitute fast32 for fast64
in the above cxx command line and LD_LIBRARY_PATH
definition.
If your Java application invoked JNI C/C++ code that was
linked using the ld -taso options, then use the
java-taso command to run your Java application.
The Java -taso option has been replaced by the
java-taso command.
Plug-in v 1.4.1 enables users to run Java applets and JavaBeans™ components on web pages using the RTE as an alternative to using the default virtual machine for Java 2 that comes with the web browser. It is based on the Java Plug-in 1.4.1 provided by Sun Microsystems and contains similar functionality.
For additional information on topics such as Java Plug-in security, using Signed Applets, JNI and the Java Plug-in, using the Java Plug-in in Intranet Environments, and how Proxy Configuration works in the Java Plug-in, please see Sun's Java Plug-in Product web site.
Note: You must be running Netscape® Communicator 4.51 or higher, or Mozilla 0.7 or higher.
For Netscape 4.x browsers:
Set the NPX_PLUGIN_PATH environment variable
to the location of the Plug-in (the directory in which the
javaplugin.so file is located):
NPX_PLUGIN_PATH=/usr/opt/java141/jre/plugin/alpha/ns4
For Mozilla and Netscape 6.x browsers:
Create a symbolic link in the browser's plugins
directory to the path of the libjavaplugin_oji.so
file. This file is located at /usr/opt/java141/jre/plugin/alpha/ns600/libjavaplugin_oji.so.
For example:
cd ${MOZILLA}/plugins
ln -s /usr/opt/java141/jre/plugin/alpha/ns600/libjavaplugin_oji.so
Start your browser, or restart it if it is already running.
Restart your browser a second time. (This is a workaround to a browser bug.)
For Netscape 4.x browsers: The Plug-in does not replace the underlying Virtual Machine for Java 2 for Netscape Navigator®; rather, it enables you to specify the use of the RTE instead of the default Navigator Virtual Machine for Java 2.
To use the Plug-in (instead of the browser's default Java
environment version) when Netscape Navigator browses a web
page, you need to modify your web page source file(s). You
can do this manually, using the OBJECT tag and
the EMBED tag in your HTML specification. Alternatively,
you can use the HTML Converter to automate modifications of
your web page source files. For more information on HTML web
page changes required by the Plug-in, see Using
OBJECT, EMBED and APPLET
Tags in Java Plug-in on Sun's site.
The HTML Converter easily and automatically modifies HTML pages to specify the use of the Plug-in rather than the browser's default Java runtime. The SDK v 1.4.1 kit provides the Plug-in HTML Converter so that a separate download is not required.
To run the GUI version of the HTML Converter, invoke the following command:
/usr/opt/java141/bin/HtmlConverter -gui
To run the command line version of the HTML converter, invoke the HTML Converter and specify the file to convert. For example:
/usr/opt/java141/bin/HtmlConverter file.html
For more information about the HTML Converter, see Using the HTML Converter to Convert Applet Tags for Java Plug-in on Sun's site.
A Plug-in Control Panel lets you change Plug-in options such as proxies and enabling of the console window. It also allows you to switch the RTE version you want to run with your Plug-in. To run the Control Panel, enter the following command:
/usr/opt/java141/jre/bin/ControlPanel
Or you can use the Netscape Navigator browser to visit the Control Panel applet page that was installed as /usr/opt/java141/jre/bin/ControlPanel. For example:
netscape /usr/opt/java141/jre/ControlPanel.html
Some of the Control Panel features are discussed in the following sections. Refer to Using the Java Plug-in Control Panel to Set Plug-in Behavior/Options on Sun's site for information about additional features and uses of the Java Plug-in Control Panel.
By default, the Fast VM is used when running the Plug-in.
You can have the Plug-in use the classic VM by defining the
environment variable JAVA_PLUGIN_CLASSIC_VM prior
to running your web browser.
To use the Fast VM (with 64-bit pointers), you can define
the environment variable JAVA_PLUGIN_FAST64_VM.
If you do not define this environment variable, by default
the Fast VM is invoked in 32-bit mode.
Setting both environment variables, JAVA_PLUGIN_CLASSIC_VM
and JAVA_PLUGIN_FAST64_VM, invokes the Fast VM
in 64-bit mode.
If you don't set an environment variable, the Fast VM with 32-bit pointers is invoked by default.
You can view a moderate amount of Plug-in tracing information
in Netscape Alert Panels by setting the JAVA_PLUGIN_TRACE
environment variable. If you set JAVA_PLUGIN_TRACE
and want the output to go to the standard output/error (usually
your terminal window), edit the following lines in your .Xdefaults
or .Xresources file in your home directory.
Change True to False:
*useStderrDialog: False *useStdoutDIalog: False
Then reload resources by typing the following command:
xrdb -merge .Xdefaults
To see Java error messages:
With the console window enabled, when you next visit a Plug-in enabled page, a separate window will come up to display error messages.
The SDK includes the following font support.
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.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.
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.
If your application displays text as rotated, you will
need to follow a few simple steps in order to successfully
use this Java2D feature. In your program, for all of the
occurrences of text that you wish to display as rotated,
you will need to call the setFont() method
to change the font name for the text to "SansSerif" or
to "Monospaced". Additionally, you will need to use this
font property file on a user local or system-wide basis.
Both of the font property files shipped with the SDK v 1.4.1
kit reside in /usr/opt/java141/jre/lib/. The
one actually named font.properties is the one
that will be used. This file is a system-wide file and is
used for the display of all Java programs that are run on
that system. The SDK supports local customizations of the
font property file which can take affect on a user or system-wide
basis. When the RTE needs to find a font.properties
file, it starts its search in $HOME. A local
version of the font.properties file takes precedence
over a system-wide version. Therefore, you can make either
of these two files your user local font.properties
by copying the font.properties file of your choice
to a file named font.properties in $HOME.
Alternatively, if you want to use the font.properties.rotation
file as a system-wide file for use by all users on the system
(thus overriding the default font.properties
file), perform the following steps:
% cp /usr/opt/java141/jre/lib/font.properties \ /usr/opt/java141/jre/lib/font.properties.orig % cp /usr/opt/java141/jre/lib/font.properties.rotation \ /usr/opt/java141/jre/lib/font.properties
If later you wish to revert to the original file that shipped
with SDK v 1.4.1, you would copy font.properties.orig
to font.properties.
If you prefer to use fonts other than those that have been
predefined by the font properties file for your use, copy
the file installed by this kit from /usr/opt/java141/jre/lib/font.properties
to your $HOME directory and modify it. When a
Java application is run, it will use your local font properties
file instead of the one installed by this kit.
Starting with Tru64 UNIX Version 4.0F, all Adobe fonts under
/usr/lib/X11/fonts/Type1Adobe are retired and
no longer ship with the operating system.
If your Java application used the retired Type1Adobe outline
fonts, it might be affected. For example, when characters
are displayed on the screen, they might not scale as expected.
If you customized your font.properties file to use these outline
fonts, you might need to modify it to use alternative fonts
that are available on your operating system. No replacements
are being provided by the operating system. However, a smaller
set of outline fonts is still available in /usr/lib/X11/fonts/Type1
and /usr/lib/X11/fonts/Speedo for your use.
If you encounter one of the following warnings, you are probably
referencing a font in your font.properties file
that is not available on your system. Check your font path
by issuing the UNIX command xset -q. If your
display is not what you expect, you might need to change the
search order. Also, make sure that the font property file
does reference fonts that are installed on your system; you
may be attempting to use a font that is not available.
"Font specified in font.properties not found [-*-helvetica-bold-r-normal...]"
If you are having problems with fonts when you display remotely to a PC using eXcursion™, you might need to upgrade to a newer version of the eXcursion software and install additional fonts. Also, make sure that the font property file references fonts that are installed on your PC.
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.confand 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 1280x1024after the-pnoption. For example:
-pn -screen 1280x1024Note that the
-screenoption can be specified as-screenNfor 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.confand search for the following lines, which are typically at the bottom of the file:
! you specify command line arguments here
args <
-pn
>- Add
-dpi 75after the-pnoption. For example:
-pn -dpi 75
Typically, 75 dpi is a good choice for monitors with a resolution of 1024x768. If you would like the fonts to be uniformly larger, use 100 dpi fonts by specifying
-dpi 100.
For more detailed information on changing X Server screen
settings, refer to section "Adjusting Your Screen Settings"
of the Tru64
UNIX Best Practice guide.
The CDE desktop window manager (dtwm), and the Motif window manager (mwm), are fully supported. You may also use the DIGITAL eXcursion™ window manager when running your Java application on a Tru64 UNIX system and redirecting the display back to a PC.
Non-standard window managers such as fvwm and twm are not supported. Therefore, you may experience some unusual behavior when using them.
If the optional documentation subset (JAVADOC141)
is installed, then the SDK documentation tree begins at the
following location on the system where the SDK is installed:
/usr/opt/java141/docs/index.html
The installed documentation is in HTML format and includes
this release notes file (which describes SDK information specific
to Tru64 UNIX systems) and the index.html
file (which contains a brief summary of important instructions
you should perform before you install this kit).
Note: The documentation in JAVADOC141
does not include the API reference documentation.
If you want to use the API reference documentation locally,
download and install the separate javaapidoc141-2.tar
file as described in Installing the API
Reference Documentation. Browse the API documentation
using the following location:
/usr/opt/java141/docs/api/index.html
Also, you can browse the Software Documentation page on our web site.
There is also a java manpage that describes
the java command and points to the installed
documentation. The java manpage ships with the
operating system and describes the Java environment version
that was shipped; the manpage is not updated by this kit.
For more information on this release, refer to the Release Notes for the J2SDK v 1.4.1 software from Sun Microsystems, and our Frequently Asked Questions (FAQ) web page.
If you are new to the Java programming language, you will want to browse or download Sun's Java Tutorial.
To report problems, refer to our Support Web page.
|
||
|
||
| privacy statement | using this site means you accept its terms | |
|
||
|
||
| © 1994-2003 Hewlett-Packard Company | ||
|
||