HP-UX Java™ SDK Version 1.4.1.00 Release Notes

Add the directory /opt/java1.4/bin to your PATH.

Note: To install the software into an alternate location, see
"Installing into an alternate location".

For information on setting important system parameters required for correct execution of Java programs refer to the Programmer's Guide which can be found at Programmer's Guide for Java™ 2.

Installing into an alternate location

To install the software into an alternate location, add @/<alternatedirectory> to the end of the swinstall line, and add the alternate directory to your PATH.

For example:

If you want your Java home directory in <alternatedirectory> without the /opt/java1.4 directories, you need to install into a temporary directory, and then move the directories to where you want them.

For example:

swinstall -s <download> \* @/<temporarydirectory>
mv <temporarydirectory>/opt/java*/* <finalalternatedirectory>

Or you can install and link to the directories.

For example:

swinstall -s <download> \* @/<actualdirectory>
ln -s <finalalternatedirectory> /<actualdirectory>/opt/java*

You will notice that the two files, <alternatedirectory>/etc and <alternatedirectory>/var are created. These may be purged, because they do not apply to a product installed in an alternate location.

Note that we are testing another method of installing into an alternate location using <tag>. When we are confident that this method works with software depot install, we will post instructions here.

  java1.4
     |
  ___|_____________________________________________________
   |        |        |         |           |          |    
  bin      lib     *jre      src.zip      demo     include 
   |        |        |
  java    tools.jar  |
  javac   dt.jar     |
  javadoc ir.idl     |
  javah   orb.idl    |
  javap              | 
  jdb                |
                  ___|_______________
                     |               |
                    bin             lib
                     |               |
____________________ |____________   | 
java PA_RISC PA_RISC2 PA_RISC2.0W    |  
                                     |
                                     |
                       _____|____________________________________
                       |      |    |       |        |           | 
                     rt.jar  zi security PA_RISC  PA_RISC2.0  PA_RISC2.0W
                  charsets.jar             |________|____________|  
                    jce.jar                |        |            |        
                    jsse.jar            server    server      server   

[%T %B->%A(%C), %D]

-Xverbosegc usage: -Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]

    :help prints this message.

    0|1 controls the printing of heap information:
        0   Print after every Old Generation GC or Full GC
        1   (default) Print after every Scavenge and Old Generation GC 
            or 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 20 fields are printed:
<GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 %19 %20>

1. Native application creates a JVM
   The application can either link in libjsig.sl and ensure that libjsig.sl gets loaded before libc.2 by linking them in the right order or use the LD_PRELOAD functionality provided by the linker to load libjsig.sl first.

2. Normal JAVA application invoked from the command line LD_PRELOAD must be used in this case. Linking the native libraries with libjsig will not work because the JVM will load libc.2 before the application's shared libraries get loaded.
   For example, to use the LD_PRELOAD environment variable:
   export LD_PRELOAD=<libjvm.sl dir>/libjsig.sl; java_application (ksh)
   setenv LD_PRELOAD=<libjvm.sl dir>/libjsig.sl; java_application (csh)

1. Remote debugging with the -attach or -listen jdb option.
2. You are implementing a debugger which uses the JDWP directly.
3. You are implementing a debugger back end which uses JVMDI.