| Release notes are provided with the software and as
a standalone file on the http://hp.com/go/java web site. The file on
the web site will be the most up-to-date file.
The HP-UX SDK, for the Java™ 2 Platform Version 1.2 release provides the tools for developing and deploying Java™ applications on PA-8600-based workstations, HP server
series rp5400, rp7400, and rp8400, and Superdome, with HP-UX 11.0 PA-RISC and 11i PA-RISC.
Table of Contents
Features
Features of This Release
The HP-UX SDK, for the Java™ 2 Platform, HotSpot Edition provides
the solutions necessary to develop or deploy Java™ applications
on HP 9000 Enterprise Servers, HP 9000 Workstations, and HP Visualize
Workstations.
The 1.2.2.11 version of the HP-UX SDK, for the Java™ 2 Platform,
HotSpot 1.01 Edition contains bug fixes and enhancements, which
are described in the "Problem Fixes and Known Issues" section at
the end of this document.
Previous 1.2.2 Releases
The 1.2.2 releases all contain the high performance HotSpot technology,
which includes an adaptive compiler and improved garbage collection.
The 1.2.2 releases also contain the enhancements for Swing, AWT,
Java™ 2D(tm), and tools described at
http://java.sun.com/products/jdk/1.2/changes.html.
The 1.2.2 releases also continue to support a Year 2000 compliant
and 100% Java™ compatible environment.
The 1.2.2.03 through 1.2.2.10 releases were maintenance releases which
contained defect fixes and performance enhancements. Version 1.2.2.05
also contained the -Xverbosegc and -Xnocatch options, and a new
profiling option, -Xeprof, to generate profile data for HPjmeter.
The 1.2.2.02 release was a maintenance release which contained
numerous API, classic, and HotSpot VM bug fixes, significant improvement
in the performance of the drawImage API, and the new Java™
Debugger Architecture (JPDA) for Java™ 2 for classic VM technology.
HP's Product Versioning
HP's product versioning scheme is similar to the JavaSoft
versioning scheme. An HP maintenance release,
for example 1.2.2.00, would contain the JavaSoft 1.2.2 maintenance
fixes and may include additional HP defect fixes. A subsequent HP
minor maintenance release, for example 1.2.2.01 or 1.2.2.02, would
contain all additional defect fixes for HP releases after 1.2.2.00.
HP's minor maintenance releases are not directly comparable to
JavaSoft patch releases such as 1.2.2.-001.
Installation
Patches
Operating system patches should be installed before you install the software.
To determine which patches have been installed on your machine,
login as root and check your machine with: /usr/sbin/swlist -l product
For ongoing updates of the list of required and recommended patches,
and instructions on how to download them, go to the Download Software pages on Java™ Technology Software on HP-UX.
Minimum System Requirements
Users will get the best performance with HP server series rp5400, rp7400, rp8400,
and Superdome, and PA-8600-based workstations. The recommended minimum system for running Java™ applications is a PA-RISC 2.0 system.
If you download the software from Java™ Technology Software on HP-UX, you need
approximately 100 MB of disk space on your system to install the software.
If you install the software from the application CD, you need
approximately 50 MB of disk space on your system to install the software.
Installation Instructions
The HP-UX SDK, for the Java™ 2 Platform installs under /opt/java1.2.
If you had a previous installation in /opt/java1.2, please uninstall it
using swremove and move any personal files from your existing
/opt/java1.2 directory before you begin the new installation.
(WebQoS users please note that once the SDK or RTE is uninstalled,
WebQoS will no longer work. After the SDK or RTE is re-installed,
WebQoS users must re-run the WebQoS setup script when the updated
version of the SDK or RTE gets installed in a different top-level
directory than it was previously installed.)
(Note: Websphere Application Server may be installed only after
the SDK is installed.)
If you do not uninstall a previous installation, you may see messages
such as "Error: You have specified more than one fileset selection."
As root user, use the SD-UX swinstall command to install the software:
/usr/sbin/swinstall
It will lead you through the installation. We recommend you select
the "Reinstall filesets" and unselect the "Mount filesystems"
option from the options menu.
WARNING: Do not unarchive rt.jar, il8n.jar, jpda.jar, and tools.jar.
These files are needed by the SDK tools and the runtime environment.
Add the directory /opt/java1.2/bin to your PATH.
See the Information Library link on the product pages of
Java™ Technology Software on HP-UX for information on setting important
system parameters required for correct execution of
Java™ programs.
Product Structure
The diagram below displays an abbreviated form of the file structure:
The tools install under opt/java1.2/bin and the libraries install under
opt/java1.2/lib. The tools.jar file contains the classes for supporting
the tools and utilities. The file dt.jar contains the DesignTime
archive of BeanInfo files. The file jpda.jar contains the classes for
supporting JPDA.
The jre directory includes the runtime environment. The file rt.jar contains
the runtime classes for the core API. The file il8n.jar contains the
internationalization and localization classes and files. The file
iiimp.jar contains the classes that implement the Internet-Intranet
Input Method Protocol. The security directory contains security
management files. The PA_RISC directories contain the shared libraries
used by the HP-UX platform.
The file src.jar contains an archive of source files for the core API
for informational purposes. To view the files, enter the command:
$ jar xvf src.jar.
The include directory contains the header files for supporting JNI and
JVMDI.
Usage Documentation
The HP-UX SDK, for the Java™ 2 Platform, HotSpot Edition continues to
include all of the standard Java™ 2 SDK Tools. The tools supported
include appletviewer (with a graphical user interface), extcheck, jar,
java, javac, javadoc, javah, javap, the original jdb (only supported in
-classic mode), rmic, rmid, rmiregistry, serialver, keytool, jarsigner,
policytool, native2ascii, and tnameserv.
The HP-UX SDK, for the Java™ 2 Platform, HotSpot Edition supports the
APIs core to the Java™ 2 platform: Java™ Foundation Classes (JFC),
Security, Java™ IDL, JDBC(tm), JavaBeans(tm), Remote Method Invocation
(RMI), Java™ 2D, and the Collections Framework. HP also includes the
implementation of a non-blocking I/O Poll API for Java™ in the
com.hp.io package.
com.hp.io.Poll supports a general mechanism for reporting I/O
conditions associated with a set of FileDescriptors and for waiting
until one or more conditions becomes true. Specified conditions include
the ability to read or write data without blocking, and error conditions.
Use of com.hp.io.Poll dramatically reduces the number of threads
required to support large numbers of clients in large server-side
Java™ applications.
The packages included in the APIs core to the Java™ 2 platform are
described at:
http://java.sun.com/products/jdk/1.2/docs/api/overview-summary.html
The HP-UX SDK, for the Java™ 2 Platform, HotSpot Edition also
contains the HP-UX Runtime Environment, for the Java™ 2 Platform,
HotSpot Edition which allows Java™ applications developed for the
Java™ 2 Platform to be deployed on HP 9000 systems.
The version 1.2.1 default ORB (Object Request Broker) for the
HP-UX Runtime Environment, for the Java™ 2 Platform is also included.
For the most up-to-date software and additional documentation, see
Java™ Technology Software on HP-UX. The HP-UX Programmer's Guide for Java™,
available via the Documentation link, provides detailed information
on product options and usage.
Below you will find additional information on the following topics:
supported tools and options
additional HotSpot option information
additional hp option information
threads
using JNI
C and C++ libraries
CLASSPATH
migrating from 1.1 to 1.2
JAR files
ORB support
support for locales
starting the X font server
Supported Tools and Options
To run a tool on HP-UX, either use the full path name or add the path
to the startup file. For example, for javac, on the command line you
could enter: /opt/java1.2/bin/javac yourfile.java. You could alternatively
add /opt/java1.2/bin to your PATH statement and on the command line
enter: javac yourfile.java
The HotSpot technology accepts all of the standard tools and options,
except jdb. The standard tools and the standard documentation
references are noted below.
The appletviewer tool is documented at:
http://www.java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/appletviewer.html
CLASSPATH is documented at:
http://www.java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/classpath.html
The jar tool is documented at:
http://www.java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/jar.html
The java tool is documented at:
http://www.java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/java.html
The javac tool is documented at:
http://www.java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/javac.html
The javadoc tool is documented at:
http://www.java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/javadoc.html
The javah tool is documented at:
http://www.java.sun.com/products/jdk/1.1/docs/tooldocs/solaris/javah.html
The javap tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/javap.html
The jdb (jdb for classic technology only) tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/jdb.html
The extcheck tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/extcheck.html
The rmic tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/rmic.html
The rmiregistry tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/rmiregistry.html
The rmid tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/rmid.html
The serialver tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/serialver.html
The native2ascii tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/native2ascii.html
The keytool tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/keytool.html
The jarsigner tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/jarsigner.html
The policytool tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/policytool.html
The tnameserv tool is documented at:
http://java.sun.com/products/jdk/1.2/docs/guide/idl/jidlNaming.html
Additional HotSpot Option Information
The HotSpot technology accepts all of the standard options. The
HotSpot technology supports the following non-standard options:
-Xint
Operate in interpreted-only mode. Compilation to native code is
disabled, and all bytecodes are executed by the interpreter.
The performance benefits offered by the Java™ HotSpot adaptive compiler
will not be present in this mode.
-Xbatch
Disables background compilation. If compilation of a large method
is taking a long time, the performance engine will revert to
interpreting the method. It will compile the method as a background
task, running the method in interpreter mode until the background
compilation is finished. The -Xbatch flag disables background
compilation so that compilation of all methods proceeds as a
foreground task until completed, regardless of how long the
compilation takes. This flag is provided for users who desire
more deterministic behavior of method compilation for purposes such
as benchmarking.
-Xincgc
Enable the incremental garbage collector. The incremental garbage
collector, which is off by default, will eliminate occasional
garbage-collection pauses during program execution. However,
it can lead to a roughly 10% decrease in overall performance.
-Xss<size>
Specify the size of stack for each new Java™ thread. The
default Java™ thread stack size is 128 KB. This flag is appropriate for programs
that have small thread stack size requirements and/or create several
thousand threads, potentially running out of virtual memory. Program
threads that overflow the allocated stack will receive
java.lang.StackOverFlowException. Example: -Xss128k
-Xms<size>
Specify the initial size, in bytes, of the memory allocation pool.
This value must be a multiple of 1024 greater than 1MB. Append the
letter k or K to indicate kilobytes, or m or M to indicate megabytes.
The default value is 5248KB. Examples:
-Xms4194304
-Xms4096k
-Xms4m
Specify the maximum size, in bytes, of the memory allocation pool.
This value must a multiple of 1024 greater than 2MB. Append the
letter k or K to indicate kilobytes, or m or M to indicate megabytes.
The default value is 64MB. Examples:
-Xmx83886080
-Xmx81920k
-Xmx80m
-XX:NewSize=<size>
Specify the initial size, in bytes, of the young object space where new
objects are allocated. The default initial young space size is 2MB.
NewSize must be a multiple of 1024. Append the letter k or K to
indicate kilobytes, or m or M to indicate megabytes. Example:
-XX:NewSize=4096k
sets the initial size of the young space to 4MB. Note that a large young
space size may result in increased garbage collection pause times.
-XX:MaxNewSize=<size>
Specify the maximum size, in bytes, of the young object space where
new objects are allocated. The initial young space size is 2MB.
MaxNewSize must be a multiple of 1024, and greater than 2MB.
Append the letter k or K to indicate kilobytes, or m or M to indicate
megabytes. The default value for MaxNewSize is 64MB. Example:
-XX:MaxNewSize=4096k
-XX:NewSizeThreadIncrease=<sizeinkb>
As more threads are created in a server application, the object
allocation rate may increase with the number of active threads.
The number of active threads is considered when adjusting the size
of the young space, after a garbage collection. This flag specifies,
in Kilobytes, the increment in young object space size, per
active thread, to accomodate potentially faster object allocation rate.
The default increment is 16Kb. For example:
-XX:NewSizeThreadIncrease=32
would increase the young space size by 32kb for every active thread.
The young space growth is subject to the explicitly supplied or
internally computed limits on the maximum size of young space.
The virtual machine also periodically adjusts the heap organization
based on real program behavior.
-Xbootclasspath:<bootclasspath>
Specify a semicolon-separated list of directories, JAR archives,
and ZIP archives to search for boot class files. The specified boot
class libraries will be used instead of the boot class files in the
jre/lib/rt.jar archive normally used by the Java™ 2 software.
-Xprof
Send cpu profiling data to standard output. Disables class garbage collection.
-X
Prints out a brief usage message describing the non-standard options.
Additional HP Option Information
Noteworthy HP specific commands for Java™ 2 include -classic,
-pa11, -Xeprof, -verbosegc, and -Xverbosegc:
-classic Option
If you prefer to run your application without the HotSpot technology,
use the -classic command line option as the first option in the
command you use to invoke the java compiler or runtime environment.
-pa11 Option
HP's PA-RISC 2.0 architecture offers performance features not compatible
with previous architectures. PA1.1 binaries can be run on a PA1.1
as well as PA2.0 based systems; however, a PA2.0 binary can only run
on a PA2.0 based system. Starting with the 1.2.2 release of the SDK,
HP includes two versions of the shared libraries comprising APIs and VMs.
The PA2.0 shared libraries will be default if the user is running on a
PA2.0 system. The user can override the use of the PA2.0 version of the
shared libraries on a PA2.0 by specifying the -pa11 flag. For example:
On a PA2.0 based system, invoking Java™ by typing
java -version
results in something similar to:
java version "1.2.2"
HotSpot VM (..., mixed mode, PA2.0 build 1.2.2.00-99/09/30-PA_RISC 2.0)
The generated version string indicates that the PA2.0 version of the
VM will be used.
A user can override the use of the PA2.0 version of the VMs and APIs
on a PA2.0 system by adding the -pa11 flag as follows:
java -pa11 -version
This results in something similar to:
java version "1.2.2"
HotSpot VM (..., mixed mode, PA1.1 build 1.2.2.00-99/09/29-PA_RISC 1.1)
The version string indicates that the PA1.1 version of the VM in spite
of the fact that we are running on a PA2.0 system.
Note: If you run HotSpot with the -pa11 flag or run on a PA 1.1 system,
your heap address space will be restricted to 1G.
-Xeprof Option (HotSpot 1.2.2.05 and later)
The -Xeprof option generates profile data for HPjmeter. The -Xeprof option
enables profiling of Java™ applications running on HotSpot version 1.2.2.05
or greater and collects method clock and CPU times, method call count, and
call graph. (For more information on HPjmeter, see
HPjmeter Downloads and Documentation.)
To profile your application use the following command:
java -Xeprof:<options> ApplicationClassName
To profile your applet, use:
appletviewer -J-Xeprof:<options> URL
where <options> is a list of <key>[=<value>] arguments
separated by commas.
After the profiled applet or application normally terminates execution,
the Java™ Virtual Machine writes the profile data to a file in the
current directory.
We have found the following options useful in most cases:
For CPU time metrics with minimal intrusion:
-Xeprof or
-Xeprof:ie=no
Exact call count information and object creation profiling:
-Xint -Xeprof:ie=no
To see the complete list of available options, use
java -Xeprof:help
Here are the supported -Xeprof options:
file=<filename>
The profile data will be written to the named file. The default
is java.eprof.
times=quick|thorough
Collect call graph with inclusive method clock and CPU times
and method call count.
This option uses tracing with reduction
and collects the data separately for each thread,
throughout the whole execution time of the program.
The quick value instructs the profiler to use
the hardware Interval Timer register for time measurement.
This value results in faster profiling runs, but in very rare
circumstances can produce inaccurate data.
This is the default for PA-RISC 2.0 based machines.
If you ever suspect that the profile data generated using the
quick value is incorrect then redo the run to see
whether the results can be replicated.
The thorough value is the opposite of quick, disabling the use of
the Interval Timer. The profiling runs will be longer, but will
provide timing data with the same quality as the system calls used to
measure the time. However, the profiling intrusion and overhead also
increase. This is the default for PA-RISC 1.1 based machines. Enable/disable the profiling intrusion estimation.
ie=yes, the default value, specifies that the profiler
estimate the profiling intrusion
and write the estimated values to the profile data file.
A future version of HPjmeter will be able to present the timing data
as: raw, meaning the data as collected, or compensated, meaning with
the estimated intrusion subtracted.
Disabling intrusion estimation reduces the size of the data files,
but will also disable the intrusion compensation feature. Disable/enable inlining in the HotSpot VM.
The compiler in the HotSpot VM optimizes Java™ applications by inlining
frequently called methods. Execution of inlined methods does not count
as "calls" from the profiler's viewpoint. Instead, the time spent in
an inlined method is attributed to its caller.
The count of created objects cannot be reliably estimated in the
presence of inlining, because the calls to the constructors may have
been inlined.
To obtain an accurate method call count and to enable the created
objects metric, run the VM with inlining=disable. 0 Only after each full GC
1 (default) After every Scavenge and Full GC
:file=[stdout|stderr|<filename>] specifies output file
stderr (default) directs output to standard error stream
stdout directs output to standard output stream
<filename> file to which the output will be written
At every garbage collection, the following 18 fields are printed:
<GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 >
%1: Indicates the cause of the garbage collection.
-1: indicates a Scavenge (GC of New Generation only)
0-6: indicates a Full GC (collection of all spaces in the
Java™ Heap)
Reason:
0: Call to System.gc
1: Old Generation full
2: Permanent Generation full
3: Train Generation full
4: Old generation expanded on last scavenge
5: Old generation too full to scavenge
6: FullGCAlot
Occupied before garbage collection (Before)
Occupied after garbage collection (After)
Current capacity (Capacity)
All are in bytes.
Eden sub-space (within the New Generation)
%6: Before
%7: After
%8: Capacity
Survivor sub-space (within the New Generation)
%9: Before
%10: After
%11: Capacity
Old Generation
%12: Before
%13: After
%14: Capacity
Permanent Generation (Storage of Reflective Objects)
%15: Before
%16: After
%17: Capacity
%18: Duration of the garbage collection in seconds.
Threads
Green threads is not included in the HP-UX SDK, for the Java™
2 Platform for HP-UX 11.0.
Using JNI
Dereferencing NULL Pointers
In Java™ 2, JNI code that incorrectly dereferences NULL will result in a
SIGSEGV, which may be different behavior than that experienced with Java™ 1.1 releases. For example, in Java™ 1.1, JNI methods that dereference
NULL pointers like this:
int *p = NULL;
return *p;
will return the value 0.
With the Java™ 2 HotSpot VM, such dereferences result in a SIGSEGV,
and java NULL checks can be performed without having to emit explicit
code to do so.
With Java™ 2 HotSpot, the signal is caught, and a null pointer exception
is thrown if the offending instruction was within the VM (compiled code,
or in the interpreter). This method may uncover hidden programming errors.
Also, if you are including the HP-UX Runtime Environment for the Java™ 2
Platform in an application and bypassing our standard driver, for
example by making calls to JNI_CreatJavaVM from inside the application,
link the application with the "-z" option. The -z option will indicate
that dereferencing NULL pointers in the application should generate
a SIGSEGV instead of the traditional behavior of returning zero.
If you do not, you will not be able to take advantage of implicit
null pointer checks; null pointer checks will have to be explicit,
potentially degrading performance. Linking with -z may also expose
existing but quiet bugs in an application. This is because the
SIGSEGVs were not being generated before.
C and C++ Libraries
HotSpot requires use of the HP aC++ compiler for any application C or C++
libraries loaded dynamically at runtime. Libraries compiled with the
cfront HP C++ compiler will not work with HotSpot.
CLASSPATH
CLASSPATH will be automatically set during installation. If you get the
error "Unable to initialize threads: cannot find class java1.2/lang/Thread",
your CLASSPATH environment variable may be incorrect.
Migrating from 1.1 to 1.2
Information to assist you in migrating from 1.1.to 1.2 is provided at
http://java.sun.com/products/jdk/1.2/docs/tooldocs/tools.html.
Note: All non-standard options are now prefaced with -X. For a list of
non-standard options supported by HP, use the command: java -X. For a list
of standard options, use the command: java -help.
Compatibility information is provided at:
http://java.sun.com/products/jdk/1.2/compatibility.html.
The SDK 2 java launcher tool replaced the JDK 1.1 jre tool.
JAR Files
If you run an applet from a JAR file, the classes files should only be
available in the JAR file, and the JAR file should not be in the class path.
ORB Support
The classes in the CORBA package provide runtime support for Java™ application classes that access core ORB functionality.
Java™ application class files derived from a fully CORBA-compliant
Interface Definition Language (IDL) compiler, should compile and
run properly. (HP does not provide an IDL compiler in this release.)
HP has validated that you can "plug-in" another ORB implementation
by using the override command line option to the java command.
pecifically, we have validated Visibroker 3.4 using the
-Xbootclasspath option to specify use of the Visibroker 3.4
implementation classes rather than the default Java™ 2 org.omg.CORBA
classes.
Using font property files
Java™ font property files map Java™ virtual (or "logical") fonts to
platform-specific fonts. These are delivered in $JAVA_HOME/jre/lib
and are platform-specific. As with any Java™ property file, font
property files are sensitive to your locale setting.
For information on adding Asian fonts, see other
topics in these Release Notes. In addition, you will find good background
information on these web sites:
http://java.sun.com/products/jdk/1.2/docs/guide/internat/fontprop.html
and
http://java.sun.com/j2se/1.3/docs/guide/intl/addingfonts.html
Support for Locales
The HP-UX proprietory encodings used by the following HP-UX
propietory locales are not recognized by the runtime environment.
| ar_DZ.arabic8 | fr_FR.roman8 |
| ar_SA.arabic8 | is_IS.roman8 |
| da_DK.roman8 | it_IT.roman8 |
| de_DE.roman8 | iw_IL.hebrew8 |
| el_GR.greek8 | ja_JP.kana8 |
| en_GB.roman8 | nl_NL.roman8 |
| en_US.roman8 | no_NO.roman8 |
| es_ES.roman8 | pt_PT.roman8 |
| fi_FI.roman8 | sv_SE.roman8 |
| fr_CA.roman8 | tr_TR.turkish8 |
The following locales are supported:
| C.iso88591 | hu_HU.iso88592 |
| C.iso885915 | is_IS.iso88591 |
| bg_BG.iso88595 | is_IS.iso885915@euro |
| cs_CZ.iso88592 | it_IT.iso88591 |
| da_DK.iso88591 | it_IT.iso885915@euro |
| da_DK.iso885915@euro | ja_JP.SJIS |
| de_DE.iso88591 | ko_KR.eucKR |
| de_DE.iso885915@euro | nl_NL.iso88591 |
| el_GR.iso88597 | nl_NL.iso885915@euro |
| en_GB.iso88591 | no_NO.iso88591 |
| en_GB.iso885915@euro | no_NO.iso885915@euro |
| en_US.iso88591 | pl_PL.iso88592 |
| es_ES.iso88591 | pt_PT.iso88591 |
| es_ES.iso885915@euro | pt_PT.iso885915@euro |
| fi_FI.iso88591 | ro_RO.iso88592 |
| fi_FI.iso885915@euro | ru_RU.iso88595 |
| fr_CA.iso88591 | sk_SK.iso88592 |
| fr_CA.iso885915 | sl_SI.iso88592 |
| fr_FR.iso88591 | sv_SE.iso88591 |
| fr_FR.iso885915@euro | tr_TR.iso88599 |
| hr_HR.iso88592 | zh_CN.hp15CN |
| | zh_TW.big5 |
|
