| United States-English |
|
|
|
![]() |
Release Notes
Software Development Kit (SDK) v 1.4.2-7 |
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 Nonstandard 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;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 -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 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:
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.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.
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-7.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-2007 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Printed in the US |
|
|||||||||||||||