|
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™, JavaBeans™, 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. For standard tools and options documentation, refer to http://onesearch.sun.com/search/developers/?qt=1.2+docs&Search.x=13&Search.y=5
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 128KB. 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.
-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 |
-Xmx<size>
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 thread accommodateated 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 accommodate potentially faster object allocation rate. The default increment is 16Kb.
| 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.
-Xnoclassgc
Disables class garbage collection.
-X
Prints out a brief usage message describing the non-standard options.
Additional HP option information
Additional HP specific documentation can be found at http://www.unixsolutions.hp.com/products/java/document.html. 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.
ie=yes|no
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.
inlining=disable|enable
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.
-verbosegc or -verbose:gc
Prints out the result of a garbage collection to the stdout stream. At every garbage collection, the following 5 fields are printed:
[%T %B->%A(%C), %D]
%T is "GC:" when the garbage collection is a scavenge, and "Full GC:" when its a full garbage collection. A scavenge collects live objects from the New Generation only, whereas a full garbage collection collects objects from all spaces in the Java™ heap.
%B is the size of Java™ heap used before garbage collection, in KB.
%A is the size after garbage collection, in KB.
%C is the current capacity of the entire Java™ heap, in KB.
%D is the duration of the collection in milliseconds.
-Xverbosegc<options> (1.2.2.05 or later)
This option prints out detailed information about the spaces within the Java™ Heap before and after garbage collection.
The syntax of the option is:
-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]
:help prints this message.
0|1 controls the printing of heap information:
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
%2: Program time at the beginning of a collection, in seconds.
%3: Garbage collection invocation. Counts of Scavenge and Full GCs are maintained separately.
%4: Size of the object allocation request that forced the GC, in bytes.
%5: Tenuring threshold - determines how long the new born object remains in the New Generation.
The report includes the size of each space:
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 Java2 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 a C++ 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. Specifically, 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: "Adding Fonts to the Java™ Runtime" propitiatory http://java.sun.com/products/jdk/1.2/docs/guide/internat/fontprop.html and "Font Overview" at 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 propitiatory 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 |
Japanese localization
Use this procedure to display Japanese text.
- HP has tested font the typefaces from Ricoh called TrueTypeWorld ValueFont D2. Ricoh is a purchased product. For product information, go to http://www.ricoh.co.jp/swd/font/.
Install the purchased Ricoh product using the procedure described in HP-UX manual "Japanese Environment User's Guide" (part number: B3782-90873). See Chapter 4, Configuration of Japanese Fonts, Installation and Configuration for TrueType optional fonts.
Run /usr/sbin/ttinstall provided by the JSE on the WABUN/W31NT31 fonts. This will install the fonts to /usr/lib/X11/fonts/ttfjpn.s
-
Add the Ricoh installation location to the JAVA_FONTS variable. The default is:
JAVA_FONTS=/usr/lib/X11/fonts/ttfjpn.st/typefaces
-
Install the Ricoh font property file to $JAVA_HOME/jre/lib. Beginning with SDK 1.3.1 and later, the Ricoh property file is shipped. With proper (root) privileges, copy it to font.properties.ja as follows:
su
cd $JAVA_HOME/jre/lib/
cp font.properties.ja.Ricoh font.properties.ja
-
Set LANG to the Japanese locale ja_JP.SJIS in your runtime environment, or simply use CDE locale login.
Starting the X font server in X Windows Unix
In X Windows Unix environments, you can use X Font Server as an alternative to storing fonts in directories. For an X Server machine to access the X Font Server, the daemon xfs must be running and xfs must be added to the X fontpath via xset.
If you set RUN_X_FONT_SERVER in /etc/rc.config.d/xfs, xfs is started upon reboot and xfs is added to the font path.
Alternatively you can use these two commands:
# add xfs to the font path
/usr/bin/X11/xfs -config /etc/X11/fs/config -port 7000 -daemon
xset +fp tcp/localhost:7000
Using JPDA
JPDA is the debugging support architecture needed to build debugger applications for the Java™ 2 Platform. The JPDA includes the Java™ Debug Interface (JDI), the Java™ Debug Wire Protocol (JDWP),
Java™ Virtual Machine Debug Interface (JVMDI), and the jpda-jdb and jpda-javadt sample debuggers. The jpda-jdb sample debugger is similar to jdb. The jpda-javadt sample debugger is a graphical debugger. Please note that the java source code for the sample debuggers is located in examples.jar in /opt/java1.2/demo/jpda and is unsupported.
The JPDA architecture and components are documented at http://java.sun.com/products/jpda/. The jpda-jdb for HP-UX is similar to the Solaris implementation of the JPDA jdb. JPDA supports only the classic VM technology. For usage information, see "Sun VM Invocation Options" at http://java.sun.com/products/jpda/doc/conninv.html. The following information on "Manually Launching the Application VM" is excerpted from http://java.sun.com/products/jpda/readme.html.
Manually launching the application VM
If you are running the version of jdb provided in this release, the application VM is launched for you with the debugger back end loaded. However, in the following cases, you will be launching your own application VM, either by hand or in your implementation.
- Remote debugging with the -attach or -listen jdb option.
- You are implementing a debugger which uses the JDWP directly.
- You are implementing a debugger back end which uses JVMDI.
Currently, the first two cases require a command line like the following:
java -classic -Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=y
-classpath class-path class-name
The -Xdebug option enables debugging. The -Xnoagent disables the default sun.tools.debug debug Agent. The -Djava.compiler=NONE disables the JIT compiler.
For the third case, you must use the same command line options as described above, but you are free to use your own mechanism for loading the JVMDI client into the application VM. You do not need to use -Xrunjdwp.
The Connection and Invocation Details document at http://java.sun.com/products/jpda/doc/conninv.html contains more information on necessary VM invocation options and sub-options of -Xrunjdwp.
Closing a socket when accept or read is pending on same socket
If you have one thread performing an accept or read on a socket, and try to close the socket to clean up resources, the default behavior is for the close() to block until the accept or read call completes. If you want to change this behavior, you should use the following Java™ command line option:
-XdoCloseWithReadPending
This option allows one thread to close a socket when there is an outstanding accept or read pending on the same socket from another thread.
With the -XdoCloseWithReadPending option, the socket close() call closes the socket and, in the context of the thread with the pending read or accept, a SocketException with the message "Socket closed" is thrown.
Miscellaneous
For detailed information on Java™ 2 SDK features and tools, go to http://java.sun.com/products/jdk/1.2/docs/index.html.
The Java™ 2 Platform API Specification is available at http://java.sun.com/products/jdk/1.2/docs/api/index.html.
The Java™ Class Libraries, Second Edition, by Patrick Chan and Rosanna Lee provides additional details on the class libraries.
Other documentation on the Core APIs can be found at:
Java™ Foundation Classes: http://java.sun.com/products/jfc/docs.html.
Java™ Security: http://java.sun.com/security/index.html.
Java™ IDL: http://java.sun.com/products/jdk/1.2/docs/guide/idl/index.html.
JDBC: http://java.sun.com/products/jdbc/index.html.
JavaBeans: http://java.sun.com/beans/docs/index.html.
RMI: http://java.sun.com/products/jdk/rmi/index.html.
Java™ 2D: http://java.sun.com/products/java-media/2D/index.html.
The Collections Framework: http://java.sun.com/products/jdk/1.2/docs/guide/collections/index.html.
Java™ Language Specification is provided at http://java.sun.com/docs/books/jls/html/index.html.
The Java™ tutorial is at http://java.sun.com/docs/books/tutorial/index.html.
The Swing Connection newsletter can be found at http://java.sun.com/products/jfc/tsc/index.html.
|
