HP-UX Java™ SDK Version 1.3.0.02 Release Notes

The HP-UX SDK, for the Java™ 2 Platform Version 1.3 release provides the tools for developing and deploying Java™ applications on HP 9000 Enterprise Servers, HP 9000 Workstations, and HP Visualize Workstations with HP-UX 11.0 and HP-UX 11i (previously called 11.11).

The 1.3.0.02 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.

HP-UX SDK Version 1.3 includes significant performance and functionality enhancements. The new features of the standard version 1.3 of the Java™ 2 platform and the performance, tool support, and tool enhancements are documented at http://java.sun.com/products/jdk/1.3/docs/relnotes/features.html. The complete list of features of the standard version 1.3 is documented at http://java.sun.com/reference/docs/index.html#guide.

The HP-UX SDK, for the Java™ 2 Platform, HotSpot Edition continues to include all of the standard Java™ 2 SDK Tools. The tools include appletviewer (with a graphical user interface), extcheck, jar, java, javac, javadoc, javah, javap, jdb and oldjdb (only for -classic mode), rmic, rmid, rmiregistry, serialver, keytool, jarsigner, policytool, native2ascii, tnameserv, and idlj. This release also continues to support a 100% Java™ compatible environment.

The 1.3 releases contains the HotSpot 1.0.1 VM.

This 1.3 release also contains the -Xnocatch option which disables the Java™ "catch-all" signal handler. Use this option to generate clean stack traces from native code.

The 1.3 release also contains the FastSwing feature that is exclusive to HP-UX. This feature provides significant performance improvement for Swing Applications on a Remote X-Server. Remote X-Servers include X-Terminals, PC-XServers like Exceed and Reflection X and remote unix workstations. This feature is documented in "Usage Documentation" below.

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), and Java™ Virtual Machine Debug Interface (JVMDI). A sample debugger based on JPDA is provided in /opt/java1.3/bin/jdb and works with the Classic VM only. The original jdb product has been moved to /opt/java1.3/bin/oldjdb and also works with the Classic VM only. Please note that the java source code for the sample debuggers is located in examples.jar in /opt/java1.3/demo/jpda and is unsupported.

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.3/docs/api

The JavaSoft idlj compiler is available in this release. This allows developers to define their application interfaces in a program neutral interface language. The idl interface files are compiled into Java™ files via this compiler. It also generates portable client stubs and server skeletons that work with any CORBA-compliant Object Request Broker. It produces CORBA 2.3 compliant code. Refer to http://java.sun.com/reference/docs/index.html for more information.

The Java™ Naming and Directory Interface is available in this release. This makes it possible to have a federated naming service as part of your application. Currently LDAPv2, CosNaming, and RMI Registry Server Provider Interfaces are available on our JDK platform. Refer to http://java.sun.com/reference/docs/index.html for more information.

The JavaSoft ORB has been updated to CORBA 2.3.2 compliancy. One of the new features specified in this update is "objects passed by value." Refer to the OMG documents at http://www.omg.org/ for more information on this CORBA version.

New RMI run-time classes are included that allow RMI applications to run over the IIOP protocol.

Also, a new rmic compiler is provided that understands the "-iiop" option that produces stub and skeleton files that communicate via the IIOP protocol. This makes it possible for RMI clients and servers to communicate with their CORBA counterparts. Refer to http://java.sun.com/docs/index.html for more information.

Version 1.3.0.01 was a maintenance releases which contained defect fixes and performance enhancements.

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.

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, go to the Patches page which can be found at http://www.hp.com/go/JAVA, by selecting this product and then selecting downloads or information library.

To download patches, go to the Patch Database at the Electronic Support Center website for either the Americas and Asia Pacific (http://us-support.external.hp.com) or Europe (http://europe-support.external.hp.com). Select the link "Individual Patches" and "Retrieve a Specific Patch". (This process will redirect you to a new patch if a patch has been superceded.) Read the information about the patch to ascertain any dependencies.

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 the website, you need approximately 100 MB of disk space on your system to install the software.

The HP-UX SDK, for the Java™ 2 Platform installs under /opt/java1.3. 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.3/bin to your PATH.

The diagram below displays an abbreviated form of the file structure:

The tools install under opt/java1.3/bin and the libraries install under opt/java1.3/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 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.

The Java™ 2 Platform, Standard Edition, v 1.3 API Specification is provided at http://java.sun.com/j2se/1.3/docs/api/index.html. Note: Only the java.x packages are supported.

The Java™ Class Libraries: Second Edition, Volume 1 by Patrick Chan, Rosanna Lee, and Douglas Kramer provides additional detail and examples. For more information see http://java.sun.com/docs/books/chanlee/supplement.

Below are some additional documentation notes about tools, threads, JNI, CLASSPATH, migrating from Java™ 1.1 to Java™ 2, JAR files, support for locales, JPDA, and miscellaneous items.

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.3/bin/javac yourfile.java. You could alternatively add /opt/java1.3/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.3/docs/tooldocs/solaris/appletviewer.html

CLASSPATH is documented at http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/classpath.html

The jar tool is documented at http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/jar.html

The java tool is documented at http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/java.html

The javac tool is documented at http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/javac.html

The javadoc tool is documented at: http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/javadoc.html

The javah tool is documented at: http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/javah.html

The javap tool is documented at: http://java.sun.com/reference/docs/index.html

The jdb (JPDA jdb for classic technology only) tool is documented at: http://java.sun.com/docs/index.html

The old jdb (old jdb for classic technology only) tool is documented at: http://java.sun.com/j2se/1.3/docs/tooldocs/win32/oldjdb.html

The extcheck tool is documented at: http://java.sun.com/reference/docs/index.html

The rmic tool is documented at: http://java.sun.com/reference/docs/index.html

The rmiregistry tool is documented at: http://java.sun.com/reference/docs/index.html

The rmid tool is documented at: http://java.sun.com/reference/docs/index.html

The serialver tool is documented at: http://java.sun.com/reference/docs/index.html

The native2ascii tool is documented at: http://java.sun.com/reference/docs/index.html

The keytool tool is documented at: http://java.sun.com/reference/docs/index.html

The jarsigner tool is documented at: http://java.sun.com/reference/docs/index.html

The policytool tool is documented at: http://java.sun.com/reference/docs/index.html

The tnameserv tool is documented at: http://java.sun.com/reference/docs/index.html

The idlj tool is documented at: http://java.sun.com/reference/docs/index.html

The HotSpot technology accepts all of the standard options. The HotSpot technology supports the following non-standard -X options (-X options excerpt below from http://java.sun.com/products/hotspot/1.0/README-Sparc.html#use):

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.

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.

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.

Specify the size of stack for each new Java™ thread. The default Java™ thread stack size is 1MB. 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

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 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.

Send cpu profiling data to standard output.

Disables class garbage collection.

Prints out a brief usage message describing the non-standard options.

Additional HP specific documentation is provided in the HP-UX Programmer's Guide. Noteworthy HP specific options and features for Java™ 2 version 1.3 include -pa11, -Xeprof, -Xnocatch, -verbosegc, and -Xverbosegc options and the FastSwing feature:

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.3.0"
   HotSpot VM (..., mixed mode, PA2.0 build 1.3.0.00-00/10/23-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.3.0"
HotSpot VM (..., mixed mode, PA1.1 build 1.3.0.00-00/10/23-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.

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: ApplicationClassName

To profile your applet, use:

appletviewer -J-Xeprof: URL>

where is a list of [=] 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=

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.

The -Xnocatch option disables the Java™ "catch-all" signal handler. Use this option to generate clean stack traces from native code.

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 miliseconds.

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|]]

: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 ] specifies output file stderr (default) directs output to standard error stream stdout directs output to standard output stream file to which the output will be written At every garbage collection, the following 18 fields are printed:

%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.

FastSwing is an HP feature which provides significant performance improvement for Swing Applications on a Remote X-Server. Remote X-Servers include X-Terminals, PC-XServers like Exceed and Reflection X and remote unix workstations.

To use this feature invoke java or appletviewer as follows:

/opt/java1.3/bin/java -Dhp.swing.useFastSwing=true MyApp

or

/opt/java1.3/bin/appletviewer -J-Dhp.swing.useFastSwing=true applet.html

Currently we recommend using this feature only for Remote displays as it has the following caveat:

Double-buffered Swing Components cannot perform Graphics2D operations with the FastSwing feature turned on. When doing so you will get the following exception :

java.lang.ClassCastException: sun.awt.motif.X11OffScreenImage
at BezierAnimationPanel.run(BezierAnimationPanel.java:223)
at java.lang.Thread.run(Unknown Source)

Green threads is not included in the HP-UX SDK, for the Java™ 2 Platform.

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 the 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.

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 will be automatically set during installation. If you get the error "Unable to initialize threads: cannot find class java1.3/lang/Thread", your CLASSPATH environment variable may be incorrect.

See also http://java.sun.com/reference/docs/index.html.

Compatibility information is provided at: http://java.sun.com/j2se/1.3/compatibility.html.

Information to assist you in migrating from 1.1 to Java™ 2 is provided at http://java.sun.com/reference/docs/index.html.

The SDK 2 java launcher tool replaced the JDK 1.1 jre tool.

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.

Java™ font property files map Java™ virtual (or "logical") fonts to platform-specific fonts. These font property files are 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. You will find good background information at the following web sites:
http://java.sun.com/products/jdk/1.2/docs/guide/internat/fontprop.html
http://java.sun.com/j2se/1.3/docs/guide/intl/addingfonts.html

The HP-UX proprietory encodings used by the following HP-UX propietory locales are not recognized by the runtime environment.

The following locales are supported:

Use this procedure to display Japanese text.

1. 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.st.
2. Add the Ricoh installation location to the JAVA_FONTS variable. The default is: JAVA_FONTS=/usr/lib/X11/fonts/ttfjpn.st/typefaces
3. 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
4. Set LANG to the Japanese locale ja_JP.SJIS in your runtime environment, or simply use CDE locale login.

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

The PDA architecture and components are documented at http://java.sun.com/products/jpda/ and http://java.sun.com/reference/docs/index.html. The jdb for HP-UX is similar to the Solaris implementation. 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.

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 -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 -Xrun.

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.

If a thread is performing an accept or read on a socket, and you 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.

Information on Euro support and Euro patches (including the C.iso885915 patch) can be found at http://www.software.hp.com/products/EURO/.

For detailed information on Java™ 2 SDK features and tools, go to http://java.sun.com/reference/docs/index.html.

The Java™ 2 Platform API Specification is available at http://java.sun.com/j2se/1.3/docs/api/index.html.

Other documentation 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/reference/docs/index.html
JDBC: http://java.sun.com/products/jdbc/index.html
JavaBeans: http://java.sun.com/beans/docs/index.html
Java™ 2D: http://java.sun.com/products/java-media/2D/index.html
RMI: http://java.sun.com/products/jdk/rmi/index.html
RMI-IIOP: http://java.sun.com/docs/index.html
JVMPI: http://java.sun.com/docs/index.html
The Collections Framework:
http://java.sun.com/reference/docs/index.html

Java™ Language Specification is provided at http://java.sun.com/docs/books/jls/html/index.html.

Standard code conventions are provided at http://java.sun.com/docs/codeconv/index.html.

Online training is provided at http://developer.java.sun.com/developer/onlineTraining.

Known JavaSoft bugs are documented in the Bug Database at http://developer.java.sun.com/. Information on JavaSoft 1.3 fixed bugs is available at http://java.sun.com/docs/index.html.

The 1.3.0.02 release includes fixes for the following defects:

JAGad32304 HP SR 8606162988 Web Logic Server fails to deploy the JAR in the HP 1.3 DEBUG VM.

JAGad34264 HP SR 8606164967 Problem with synchronization of java.lang.reflect.Field.set.

JAGad35565 HP SR 8606166278 Lots of scavenges happen which reclaim almost nothing, usually following a scavenge which reclaims a lot.

JAGad47518 HP SR 8606178291 java1.2 allows writing but not reading of large files.

JAGad48566 HP SR Num: 8606179342 Enhancement: lessen thread contention of java.lang.ThreadLocal

JAGad49711 HP SR 8606180490 Crash in compute_compiled_exc_handler()in Thread.stop() compiled code.

JAGad52096 HP SR 8606182880 In HotSpot 1.0.1, objects referenced by statics within the class get prematurely finalized if a class is dynamically loaded and there are no references to an instance of the class.

JAGad52602 HP SR 606183389 -native option specified in the Web Logic startup script causes java to fail with the following error: java was not found in /opt/java1.3/bin/../bin/PA_RISC2.0/_threads/java.

JAGad53617 HP SR 8606184409 Running a program with many short-lived threads under java_g shows ever-increasing DATA segment size.

JAGad62104 HP SR 8606192892 The value returned by JVM_AvailableThreadStack() needs to take account of the size of stack yellow zone and stack red zone.

JAGad62542 HP SR 8606193330 Java™ awt, LANG=ja_JP.SJIS or eucJP vertical display gets bad Font Metric.

JAGad65504 HP SR 8606196301 Java™ 1.2.2.08 aborts when compiling JSP.

JAGad67500 HP SR 8606198310 JColorChooser strings not translated for localization.

JAGad67508 HP SR 8606198318 Debugging a threaded test case with jdb where a breakpoint is set on a call to Thread.sleep() causes a fatal error "Unable to create thread table entry".

JAGad67511 HP SR 8606198321 out of memory bringing up GUI application.

JAGad70132 HP SR 8606200956 Enhancement: Better usability for full PermSpace.

JAGad71086 HP SR 8606201912 Could not traverse focus with Shift-Tab.

JAGad71648 HP SR 8606202474 No progress garbage collectons and spurious OutOfMemory messages.

JAGad76322 HP SR 8606207147 awt_robot does not run on PA1.1 machine.

JAGad80830 HP SR 8606211642 Fatal error in jdb with breakpoint set on Thread.sleep.

Below is some information on a few problem topics.

The libjvm library for the HotSpot 1.01 JVM uses thread local storage (TLS). Currently the dynamic loader that is used by shl_load does not support dynamically loading a shared library containing TLS when the library was not included in the link line.

You may have a need to load a library dynamically (using shl_load or dlopen) that contains TLS, for example libjvm.sl, without having linked your application against it. For example, this might be the case if your application uses plug-ins.

The current workaround is a new linker feature LD_PRELOAD that is available for HP-UX 11.0 in patch PHSS_22514. For HP-UX 11i the feature will be included in the next update release. For more information on LD_PRELOAD functionality and its limitations, read the man page for dld.sl AFTER you have installed the patch.

The JAVA_FONTS variable is read by the Java™ runtime to find fonts installed to places other that $JAVA_HOME. For example, X Window fonts could be installed to /lib/X11/fonts.

The default value of JAVA_FONTS is /usr/lib/X11/fonts/ms.st/typefaces:/usr/lib/X11/fonts/type1.st/typefaces: \ /usr/lib/X11/fonts/ttf.st/typefaces

Typically you would augment this list, by adding your additional paths to the above path string. However, with JAGad64950, you will need to override it using a single element:

export JAVA_FONTS=/usr/lib/X11/fonts/jpnttf.st/typefaces

If Asian (Chinese, Japanese and Korean) characters are displayed as empty boxes in Swing (and all light-weight components) the causes can be:

The environment variable JAVA_FONTS is incorrectly set.

The Asian TrueType fonts/typefaces have not been installed. The Java™ font property file for the Asian typefaces has not been installed. This file must correspond to your LANG setting and the typefaces.

Asian TrueType fonts are not yet available on the HP-UX platform. HP is working on providing those fonts in a future release. In the meantime, you need to obtain the Asian TrueType fonts from Ricoh or equivalent vendors.

The section on Japanese Localization in the Usage Documentaion section of these release notes has information on how to copy font.properties.ja.Ricoh to font.properties.ja.

In order to use the JPDA sample jdb debugger (/opt/java1.3/bin/jdb) or original jdb debugger (/opt/java1.3/bin/oldjdb), you will need to use the -classic mode.

Copyright (c) Hewlett-Packard Company 2000. All Rights Reserved. Reproduction, adaptation, or translation without prior written permission is prohibited, except as allowed under the copyright laws.

UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited.

WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, HEWLETT-PACKARD MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material. Information in this publication is subject to change without notice.

Java™ and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.