IBM® AIX® Developer Kit, Java(TM) 2 Technology Edition, Version 1.3.1, 64-bit version for POWER
- README -


Note: Before using this information and the product it supports, be sure to read the general information under Notices.

This edition of the README applies to IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1, 64-bit version for POWER and to all subsequent releases and modifications until otherwise indicated in new editions.

(c) Copyright Sun Microsystems, Inc. 1997, 2001, 901 San Antonio Rd., Palo Alto, CA 94303-4909 USA. All rights reserved.

(c) Copyright International Business Machines Corporation, 2002. All rights reserved.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.


Use this README file if you want to use the Developer Kit to write Sun Microsystems Java (TM) applications and applets.

The software contained in this release can be used only on AIX® 5.1 or later, running on 64-bit hardware. It is not supported, and will not work, on earlier versions of the AIX operating system nor on 32-bit hardware. See AIX fixes for further details of requirements on the AIX operating system for this release.

This README file is part of a release and is applicable only to that particular release. Make sure that you have the README file appropriate to the release you are using.

The Program Code is not designed or intended for use in real-time applications such as (but not limited to) the online control of aircraft, air traffic, aircraft navigation, or aircraft communications; or in the design, construction, operation, or maintenance of any nuclear facility.

Useful Web sites include:


Contents


Overview

The Developer Kit is a development environment for writing applets and applications that conform to the Java 1.3 Application Program Interface (API). 

Version compatibility

An applet or application that ran with version 1.1.8 or version 1.2.2 of the Developer Kit should run with this version, except for the incompatibilities listed in:

AIX features

The IBM® AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 has the following features:

Other highlights of the Developer Kit include:


Installation

The IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 complete release comprises several installp image files (packages). Each installp image file or package contains one or more related filesets. The packages can be installed using the installp command or more easily using the smit or smitty system management tools.

The full set of packages (installp image files) for this release is as follows:

The filesets in the above packages are: where $LANG is any of the following locales. (These filesets do not ship any files but pull in required Unicode TrueType fonts for these locales.)
 
Ja_JP  Zh_CN  Zh_TW  ja_JP  ko_KR  zh_CN  zh_TW 

The Developer Kit is installed in the directory:

Note: This 1.3.1 Developer Kit refreshes (replaces) the earlier 64-bit 1.3.0 version. If you had installed the earlier version, installing this new version will overwrite, as it should, the earlier version in the same directory.

Set up your PATH environment variable to refer to the new installation:

Note: These elements of PATH changed, at Version 1.3.0, from the previous Developer Kit releases. Like Version 1.3.0, the Developer Kit does not use a java wrapper as in Version 1.1.x and 1.2.2. (jre/sh and sh are now links created by installp packaging for backward compatibility with Version 1.2.2.)

Upgrading the SDK

If you are upgrading the SDK from a previous release, back up all the configuration files and security policy files before you go ahead with the upgrade.

After the upgrade, you might have to restore or reconfigure these files because they might have been overwritten during the upgrade process. Check the syntax of the new files before restoring the original files because the format or options for the files might have changed.

Installation restriction

If you intend to use the BEA Weblogic server, when you install the Developer Kit packages you must unselect the JAAS optional installation. The BEA Weblogic server contains its own implementation of JAAS.


AIX environment

The 64-bit IBM AIX Developer Kit, Java Technology Edition, Version 1.3.1, runs on AIX 5.1, AIX 5.2 and AIX 5.3.

For AIX 5.1, Java 1.3.1 requires the AIX 5100-03 Recommended Maintenance Level.

For AIX 5.2, Java 1.3.1 requires the AIX 5200-01 Recommended Maintenance Level.

For AIX 5.3, Java 1.3.1 requires Version 5.3.0.1 (APAR IY58143) or later.

If you are using one of the supported non-UTF8 CKJ locales one of the following filesets (available from AIX 5.1 base CDs) is required:

For Japanese users, if you are using Japanese Input Method, you may apply the following PTFs to avoid some Input Method related problems:


Verification

To help ensure that the verification process behaves consistently, first:

*JAVA_HOME is used in 1.1.x releases.  It is not required to set JAVA_HOME in this release.

If you issue the command: you should see: When verification is complete, log on again and review any values you might have assigned to these variables for possible conflicts with the new installation. Unless .hotjava already existed, executing the applet viewer will create a directory called .hotjava in your home directory. Issuing the command: should confirm this. 

Known problems and limitations

Audio

When using the AIX 5L 64-bit kernel, audio support for this release is limited to simple audio file formats such as .AU, .AIFF, and .WAV files. Audio does not work with a remote client. When using the AIX 5L 32-bit kernel, audio is not supported with this release.

Note: All the following commands must be run by user root.

To determine the kernel type running, use the following command:

    bootinfo -K
This will return 32 or 64 according to the kernel in use. To change to the 64-bit kernel (which requires a reboot), do the following:
    rm /unix
    rm /usr/lib/boot/unix
    ln -fs /usr/lib/boot/unix_64 /unix
    ln -fs /usr/lib/boot/unix_64 /usr/lib/boot/unix
    bosboot  -ad  /dev/ipldevice
    shutdown -r now

To return or change to the 32-bit kernel, do the following.

For multiprocessor:

    rm /unix
    rm /usr/lib/boot/unix
    ln -fs /usr/lib/boot/unix_mp /unix
    ln -fs /usr/lib/boot/unix_mp /usr/lib/boot/unix
    bosboot  -ad  /dev/ipldevice
    shutdown -r now

For uniprocessor:

    rm /unix
    rm /usr/lib/boot/unix
    ln -fs /usr/lib/boot/unix_up /unix
    ln -fs /usr/lib/boot/unix_up /usr/lib/boot/unix
    bosboot  -ad  /dev/ipldevice
    shutdown -r now
Your machine will now shut down and install the 32-bit kernel on restart.

Note: The rm commands are optional if the "-f" option of the ln command is used, as shown, but are included for clarity.

Color

In many Java applications, if the foreground color is not specified and the background is set to white, the display is invisible.

There are two ways to correct this problem:

  1. Modify the source code to include specifications for foreground colors
  2. If the source code is not available, set environment variable JAVA_FIXCOLORS to a value of 1 to emulate the color behavior of Java 1.1.x implementations:
    export JAVA_FIXCOLORS=1
    Note: Use of this variable is discouraged, and it might be removed at a later date.

Printing

If you have difficulty with print operations, try increasing the size of the default file system used for print spooling to be larger than the printed postscript file size.

Font quality in AWT

Text rendering for Java AWT TextField and TextArea components is performed by the AIX rasterizer for X/Motif text widgets. Currently, you might experience text dropouts at small font sizes for some fonts. This will be addressed in a future AIX release. To avoid the problem, use a font size greater than 12 points for AWT TextField and TextArea components.

Window activate and deactivate events

We have observed that with some Window Managers Java will generate window deactivate and activate events on a system menu select and deselect operation respectively. The system menu referred here is the window menu which is part of the Window Manager decorations for an application window.

Japanese Input Method

Japanese Input Method does not work correctly with LANG=JA_JP.UTF-8 and XMODIFIERS="@im=alt". This will be addressed in a future AIX release. Three workarounds are possible:

Graphics performance

The recommended model for a Java graphical user interface application is the servlet/applet model; that is, a Java servlet running on the server passing data to a graphics application/applet running on the client.

Java 2's graphics performance is optimized for those environments where Java 2 can directly manipulate the video buffer. With Java 2, the rendering engine operates at the pixel level, resulting in images being sent to the display instead of higher-level constructs. This allows Java to have complete control of the screen and be independent of the services provided by the platform or video subsystem. However, its performance can suffer when compared with Java 1.1.x, which used native X facilities to render graphics (particularly when displaying on a remote machine).

Sun has received a number of bug reports on this performance problem. See bug IDs 4204845 and 4268962 at http://developer.java.sun.com/developer. Once you have logged on, follow the link to the Bug Database. 

JDBC-ODBC Bridge

The JDBC-ODBC bridge is not supported by the 64-bit version of the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1.

JIT

Java applications that throw exceptions on multiple threads might exhibit abnormal behavior or a segmentation fault when running on some SMP systems. You can avoid this problem by setting the JITC_COMPILEOPT environment variable to NSCC_CACHE; for example:

    export JITC_COMPILEOPT=NSCC_CACHE
If you encounter this problem, report the failure through your IBM service channel.

Ikeyman demo

When running the ikeyman demo (part of the Java13_64.ext.security.jsse-us package fileset), creating a new key database file of type PKCS11KS is not supported on AIX. The other database types are supported.

Ulimit settings

In order for the JVM to run properly its data segment usage should not be limited by the ulimit. Users not running with data segment limits set to unlimited, may encounter Out of Memory Errors. The JVM will throw the following warning message during the JVM startup, if the data segment is not unlimited.
*************************WARNING**************************
You are currently running with data limits not set to unlimited.
You may experience out of memory(OOM) conditions.
In the event of an OOM error, please increase the data limit value.
You may use "ulimit -d unlimited" to set data limit as unlimited.
**********************************************************
To ensure that the data segment usage is set to unlimited for the user that will be running the JVM, use:
ulimit -d unlimited

Plugin

There is no plugin support for 64 bit JDK on AIX.


Contents of the Developer Kit

The following list shows the contents of the Developer Kit.
 
Runtime: Core Classes (rt.jar)

Tools: The tools provided include: Developer Kit README: This file, README.HTML, which is in the directory where you installed the Developer Kit.

Copyright: Copyright notice for the Developer Kit software, which is in the directory where you installed the Developer Kit.

fixes.html: A file that describes any defects fixed after the initial release of this version. This file is in the directory where you installed the Developer Kit but will not be found in the first release.

Java examples and demos: Java13_64.samples is an optional package with the following subdirectories installed in the /usr/java13_64/demo directory:

The Java13_64.ext.security package is an optional package that installs the following subdirectories in /usr/java13_64/demo directory:

Note:

See the documentation directory (/usr/java13_64/docs) for additional information about this Developer Kit. You might also be interested in downloading Sun's documentation package from this Web site:

http://java.sun.com/products/jdk/1.3/

The documentation package is designed to be extracted into the Developer Kit software installation directory. If you download the ZIP file archive version, be sure to preserve the path names when you extract the files from the archive.

The Just-In-Time (JIT) compiler

The IBM JIT compiler (libjitc.a) dynamically generates machine code for frequently used bytecode sequences in a Java application or applet during execution. The JIT v4.0 compiler delivers dynamic compiler technology, including:

All Developer Kit tools use the JIT by default. After installation, you can specify whether or not the JIT will be used. You can disable the JIT to help in the isolation of a problem with a Java application, an applet, or the compiler itself. 

Disabling the JIT
There are two ways to disable the JIT:
Enabling the JIT
To enable the JIT, set the JAVA_COMPILER environment variable to "jitc" or switch the JIT compiler on through the command line:
Determining whether the JIT is enabled
To determine if the JIT is enabled, type the following at a command prompt: If the JIT is not in use, a message is displayed that includes the following: If the JIT is in use, a message is displayed that includes the following:

Note:

If JAVA_COMPILER="" or -Djava.compiler="", the JIT compiler is disabled. If JAVA_COMPILER is unset, as in:

the default JIT compiler is enabled. The default JIT compiler is always the latest version.


Using the Developer Kit

The following sections provide information about using the Developer Kit. 

Setting the path

The main Developer Kit tools are programs that are run from a command prompt. After installing the Developer Kit software, you run a tool by typing its name at a command prompt with a filename as an argument.

You can specify the path to a tool by typing the path in front of the tool each time. For example, if the javac compiler is in /usr/java13_64/bin, you can compile a file named myfile.java by typing the following at a command prompt:

   /usr/java13_64/bin/javac myfile.java
Alternatively, you can add the string /usr/java13_64/bin to your PATH statement. Then you can compile the myfile.java file by typing the following at a command prompt:
   javac myfile.java
The PATH environment variable enables AIX to find the executable files (such as javac, java, and javadoc) from any directory. To find the current value of your PATH, at a command prompt type:
   echo $PATH

Note:

Like the 1.3.0 version, the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 ships the java tools as binary executables as opposed to shipping shell scripts in previous versions up to Version 1.2.2. The PATH environment variable must point to the bin directories instead of sh directories as follows:
export PATH=/usr/java13_64/bin:/usr/java13_64/jre/bin:$PATH
Although jre/sh and sh are now links created by installp packaging for backward compatibility, you are strongly advised to use jre/bin and bin directories as these links may not be guaranteed in future releases. 

Tools options

To get the command options of java, type:

Note: The output from the -verbosegc option is not guaranteed to remain the same in future releases, and should be used only as a guide to the functioning of garbage collection.

To get the nonstandard options of java, type the following at a command prompt:

To get help on profiling options of java, type the following: Similarly, javac command options can be obtained with the following command: The command options allowed for the java command can be passed to the runtime system when you are using tools like javac or javadoc as follows: For example, to disable the JIT when compiling classes, the command is:

Some standard command options in Java 1.1.x have been changed to nonstandard options, and some of the 1.1.x command options are not formally supported. However, command options in 1.1.x format are still supported in this release for backward compatibility but it is not guaranteed that they will be supported in future releases.


Improving the startup time of Java applications

-Xquickstart is a JVM option used for improving the startup time of some Java applications. -Xquickstart causes the JIT to run with a subset of optimizations - a quick compile. This quick compile allows for improved startup time.

-Xquickstart is appropriate for shorter-running applications, especially those for which execution time is not concentrated in a small number of methods. -Xquickstart might degrade performance if used on longer-running applications containing hot methods.

The implementation of -Xquickstart is subject to change in future releases.


IBM Java options

You can specify Java options and system properties by creating an environment variable, IBM_JAVA_OPTIONS, and setting it to the values you require. Any Java options or system properties specified must be preceded by a space, except for the first option. For example, you could set up the options as follows:
   export IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait"
If you specify the same options or properties from the command line (or from a JNI program), these options take precedence over the options and properties specified by the environment variable. The only exception to this rule is when specifying -Xt, -Xtm, or -Xdebug, which all imply that no JIT should be used.

To provide compatibility when running with Java 1.1 programs, IBM_JAVA_OPTIONS has no effect when running with JNI_VERSION_1_1. For more information, see:

Also, Java options should be specified in their current format, for example, -verbose:gc rather than -verbosegc.


Defaults

If no command options are used when calling java, the following defaults are used:

You can specify numbers in kilobytes or megabytes for command options; for example, -Xms1024K or -Xmx128M.

 

Setting the CLASSPATH

The CLASSPATH tells the JVM and other Java applications where to find the class libraries. The class libraries, such as the rt.jar file, are located in the /usr/java13_64/jre/lib directory. This path is already set up by the JVM. If you keep the bin and lib directories under the same parent directory level, the executable files will find the classes.

You need to set the CLASSPATH only if you move the classes provided by the JVM, or if you want to use other classes (such as classes you develop).

Note: If you want to develop applications in several versions of the Developer Kit (for example, 1.1.8 and 1.3), you must set the CLASSPATH and PATH separately for the different versions. For details, refer to the respective Developer Kit READMEs.

To see if the CLASSPATH is set, type the following at a command prompt:

To set the CLASSPATH to include a particular class of an application, follow this model:
    export CLASSPATH=/java/apps/classes:$CLASSPATH
where [/java/apps/classes] is the path to the application and its classes.

To reset the CLASSPATH to null and remove unwanted classes, type the following at a command prompt:

    export CLASSPATH=
To make changes to the CLASSPATH permanently, edit your .profile file. 

Required AIX environment variables for JNI

You must set the following environment variables before running Java if you are using JNI: For more information on these environment variables, see the JNI Compatibility section of this information on this environment variable, see the JNI Compatibility section of this README. 

Setting the LIBPATH and the use of LD_LIBRARY_PATH

The LIBPATH environment variable tells AIX applications, such as the JVM where to find shared libraries. This is equivalent to the use of LD_LIBRARY_PATH in other Unix-based systems.

The shared libraries for JVM are located in jre/bin and jre/bin/classic subdirectories of your Java Installation - if Java was installed as an AIX fileset this will be /usr/java13_64, but packages which "bundle" Java may use different directories. This path is already set up by the Java "launcher" programs such as "java", "javac", "jar", etc.

You need to set the LIBPATH

The LD_LIBRARY_PATH environment variable is not used by Java at all. If your application needs specific directories to be searched when finding shared libraries, the only variable to set is LIBPATH.

Obtaining the IBM Build and Version Number

The IBM build and version number can be obtained by typing the following at a command prompt:
    java -version

Running applets with the Applet Viewer

The Applet Viewer allows you to run one or more applets that are called by reference in a Web page (HTML file) using the APPLET tag. The Applet Viewer finds the APPLET tags in the HTML file and runs the applets, in separate windows, as specified by the tags.

Because the Applet Viewer is for viewing applets, it cannot display an entire Web page that contains numerous HTML tags. It parses only the APPLET tag and no other HTML on the Web page.

To run an applet with the Applet Viewer, type the following at a command prompt:

    appletviewer filename
where filename is the file name of the applet or URL of the Web page.

To invoke the Applet Viewer on a file-based Web page, go to the directory where you installed the Developer Kit package and at the command prompt type:

    bin/appletviewer demo/applets/GraphLayout/example1.html

where bin is replaced
by the absolute path to the Developer Kit's bin directory.

To invoke the Applet Viewer on a URL-based Web page, at the command prompt type:

    bin/appletviewer http://java.sun.com/applets/NervousText/example1.html

where bin is replaced
by the full path to the Developer Kit's bin directory.

Debugging applets with the Applet Viewer

You can debug applets using the -debug option of the Applet Viewer. When debugging applets, you are advised to invoke the Applet Viewer from the directory that contains the applet's HTML file. For example:
    cd demo/applets/TicTacToe
    ../../bin/appletviewer -debug example1.html
Documentation for the debugger and its API is at this Sun Web site:

Change in behavior of StringTokenizer class

Consider the following string of tokens: In Version 1.2.2, you set the delimiter to ":", and through the nextToken() method of StringTokenizer obtain the token's "opcode" and "attributeName". Then the delimiter is changed to "\t" and token "attributeValue" is returned with StringTokenizer.nextToken().

From Version 1.3.0, if the delimiter is changed mid-way through tokenizing, the next token starts with the old delimiter. The token returned is ":attributeValue". Your application must check to see if the next token is prepended with the previous delimiter once the delimiter has been changed and remove it if it is. 


Specifying garbage collection policy

The IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 introduces the -Xgcpolicy JVM runtime option for specifying garbage collection policy.

-Xgcpolicy takes two values, optthruput (the default) and optavgpause. The option controls garbage collector behavior, making tradeoffs between throughput of the application and overall system and the pause times caused by garbage collection.

The format of the option and its values is:

-Xgcpolicy:optthruput
and
-Xgcpolicy:optavgpause

Pause time

When an application's attempt to create an object cannot be satisfied immediately from the available space in the heap, the garbage collector is responsible for identifying unreferenced objects (garbage), deleting them, and returning the heap to a state in which the immediate and subsequent allocation requests can be satisfied quickly. Such garbage collection cycles introduce occasional unexpected pauses in the execution of application code. As applications grow in size and complexity, and heaps become correspondingly larger, this garbage collection pause time tends to grow in size and significance. The default garbage collection value, optthruput, delivers very high throughput to applications, but at the cost of these occasional pauses, which can vary from a few milliseconds to many seconds, depending on the size of the heap and the quantity of garbage.

Pause time reduction

The optavgpause value substantially reduces the time spent in these garbage collection pauses, as well as limiting the effect of increasing heap size on the length of the garbage collection pause. This is particularly relevant to configurations with large heaps. (Consider a heap as large when it is at least 1 GB.) The pause times are reduced by overlapping garbage collection activities with normal program execution. This overlapping results in a small reduction to application throughput.

Environments with very full heaps

If the Java heap becomes nearly full, and there is very little garbage to be reclaimed, requests for new objects might not be satisfied quickly because there is no space immediately available. If the heap is operated at near-full capacity, application performance might suffer regardless of which of the above options is used; and, if requests for more heap space continue to be made, the application receives an Out of Memory exception, which results in JVM termination if the exception is not caught and handled. In these situations, you are recommended either to increase the heap size using the -Xmx option or to reduce the number of application objects in use.

Further information about garbage collection

For information on heap size tuning and the implications of garbage collection for application performance, see:


AIX native threads

The IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 uses the AIX POSIX threads (pthreads) package for its threading. This means that Java threads can be scheduled on multiple processors on multiprocessor systems. Although Java thread priorities can be controlled using the standard Java interfaces, the underlying native thread priorities are controlled by the AIX scheduler using the default AIX scheduling policy (SCHED_OTHER).

For more details on AIX thread scheduling, see:


Scaling support

For maximum threads (with JIT) try setting the command line parameter with -ss<size> by specifying the maximum native stack size to be smaller than the default value which is 256K. A smaller setting allows for a larger number of threads. For example:

For maximum file descriptors, use the command line statement ulimit; for example: or chuser; for example: to increase the limit. (ulimit -a shows the current limit.) 


JNI compatibility

The Developer Kit does not support runtime linking (using the -brtl loader option). Any applications built for use with the Developer Kit should not rely on runtime linking functionality.

When executing a JNI program (for example, a non-java application executable that creates and initializes a JVM and then runs .class files on that JVM), make sure that the CLASSPATH is set up correctly to enable the JVM to find your class files. If you modify the Java 2 boot class path, include the Developer Kit files necessary to run your applications.

This product has made use of AIX extensions to enable faster and more efficient execution without impacting non-Java applications. The launchers, and other programs in this release, use these extensions automatically, but, for use by another program, that program must be linked with an additional AIX binder option ("-bM:UR"). If you develop a JNI program that creates and attaches to the JVM in this and future releases, then this binder option is required. The -bM:UR option is only for application programs with a main executable; it has no meaning for shared modules/libraries and can introduce errors if it is used to build a shared library.

A side-effect of this requirement is that such JNI executable programs, including third-party software packages and those built for previous Java software releases on AIX, that were built without this binder option, are NOT compatible with the JVM in this release.

Verify the compatibility of an executable program by:

The stdout output will show the modtype to be UR.

If the modtype is not UR, you can use the LDR_CNTRL environment variable to make programs behave as though they were compiled with the -bM:UR binder option.  For example:

export LDR_CNTRL=USERREGS
If you need to specify multiple options with LDR_CNTRL, separate those options with the @ symbol. 
 
The Developer Kit uses an advanced IBM technology called Mixed Mode Interpreter (MMI), which significantly reduces the startup time of the JVM. The MMI and JIT compiler make use of internal calling conventions and SIGTRAP signals that might make debugging of JNI programs using dbx more difficult.

The Developer Kit handles various AIX signals. If you install your signal handler after launching the JVM, you must chain your signal through to the JVM's handler. If signal handlers are installed by JNI invocation API applications before launching the JVM, the JVM attempts to chain to the existing handlers when receiving unexpected signals.

Java threads created by the Developer Kit use the POSIX pthreads model supported on AIX. Currently this is on a 1-to-1 mapping with the kernel threads. When developing a JNI program, you must run with a 1-to-1 thread model and system contention scope if creating pthreads in your own program, controlled by the following environment setting:

Another option is to preset the thread's scope attribute to PTHREAD_SCOPE_SYSTEM using the AIX pthread_attr_setscope() function when the thread is created. For more details on thread model and system contention scope, see:

AIX sets the default value of the AIXTHREAD_MUTEX_DEBUG, AIXTHREAD_RWLOCK_DEBUG and AIX_THREAD_COND_DEBUG environment variables to ON. A JNI program that creates and attaches to a JVM must set these environment variables OFF. See:

http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365a81.htm#HDRI34490

Note: The old-style native interface is no longer supported.

There is a README file and example programs in the /usr/java13_64/demo/jni directory. The demos can be optionally installed with the Java13_64.samples package. 


Fonts and locales

Java 1.3.1 uses the WorldType fonts shipped with AIX. These fonts are available on the AIX 5.1 distribution media as the package X11.fnt.ucs.ttf (AIXwindows Unicode TrueType Fonts). There are alternative versions of this font for Chinese and Korean. If you decide not to install the WorldType fonts, an undefined glyph symbol (normally an open rectangle) is displayed if that font is not available.

Euro symbol support

Support for the European Union currency, the Euro, is included in this release of the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1. Platform-level support is required to make use of this, as follows.

On AIX, the Euro is supported by the ISO8859-15 and UTF8 locales. They are the primary mechanisms for Euro support on the AIX operating system. Applications can then make use of the Euro symbol, which looks like a 'C' with '=' superimposed on it and can be created using Unicode character '\u20AC'. Euro variants of Java software locales, which provide the appropriate currency formatting, can also be used by Java applications. The environment variable LC_MONETARY is currently not used by this Java implementation.

For more information on IBM's position on the Euro currency, see http://www.ibm.com/euro.

Unicode font

To obtain multi-lingual text, you must install the WorldType fonts that are available on the AIX distribution media as the package X11.fnt.ucs.ttf (AIXwindows Unicode TrueType Fonts). There are alternative versions of this font for Chinese and Korean. If you decide not to install the WorldType fonts, an undefined glyph symbol (normally an open rectangle) will be displayed if that font is not available. These fonts are installed automatically if you install the UTF8 locales.

Also, Java Version 1.3.1 no longer ships Devanagari fonts (Devamt.ttf and Devamtb.ttf) in the jre/lib/fonts directory. Instead, Java uses the Monotype Unicode fonts shipped with AIX (Times New Roman WorldType and Sans Monospace WorldType) to support Devanagari (Hindi) fonts.

Supported locales

The IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 supports all the locales supported by the AIX platform, with the exception of the UTF8 locales for Korean and Chinese. The user interface is provided in these languages:

Translation from English is partial, in particular in the programming and error handling areas, where you will see some English.


Enhanced CORBA support

IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1, 64-bit version for POWER adds support for these CORBA specifications:

Support for GIOP 1.2

This Developer Kit supports all versions of GIOP, as defined by chapters 13 and 15 of the CORBA 2.3.1 specification, OMG document formal/99-10-07, which you can obtain from:

http://cgi.omg.org/cgi-bin/doc?formal/99-10-07

Bi-directional GIOP is not supported.

Support for Portable Interceptors

This Developer Kit supports Portable Interceptors, as defined by the OMG in the document formal/01-09-58, which you can obtain from:

http://cgi.omg.org/cgi-bin/doc?formal/01-09-58

Portable Interceptors are hooks into the ORB through which ORB services can intercept the normal flow of execution of the ORB.

Several new classes are introduced in the API to support Portable Interceptors. These are:

These classes are not part of the Sun Java 1.3 Core API, and could change in future versions of the IBM Developer Kit.

Support for Interoperable Naming Service

This Developer Kit has added support for the Interoperable Naming Service, as defined by the OMG in the document ptc/00-08-07, which you can obtain from:

http://cgi.omg.org/cgi-bin/doc?ptc/00-08-07

The default port used by the Transient Name Server (the tnameserv command), when no ORBInitialPort parameter is given, has changed from 900 to 2809, which is the port number registered with the IANA (Internet Assigned Number Authority) for a CORBA Naming Service. Programs that depend on this default might have to be updated to work with this version.

Several new classes are introduced in the API to support the Interoperable Naming Service:

These classes are not part of the Sun Java 1.3 Core API, and could change in future versions of the IBM Developer Kit.

The initial context returned from the Transient Name Server is now an org.omg.CosNaming.NamingContextExt. Existing programs that narrow the reference to an org.omg.CosNaming.NamingContext will still work, and do not need to be recompiled.

The ORB supports the -ORBInitRef and -ORBDefaultInitRef parameters defined by the Interoperable Naming Service specification, and the ORB::string_to_object operation now supports the ObjectURL string formats (corbaloc: and corbaname:) defined by the Interoperable Naming Service specification.

The OMG specifies a method ORB::register_initial_reference to register a service with the Interoperable Naming Service. However this method is not available in the Sun Java Core API at version 1.3.1. Programs that need to register a service in the current version must invoke this method on the IBM internal ORB implementation class. For example, to register a service "MyService":

((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference ("MyService", serviceRef);

where orb is an instance of org.omg.CORBA.ORB, returned from ORB.init(), and serviceRef is a CORBA Object, connected to the ORB. This mechanism is an interim one, and is not compatible with future versions or portable to non-IBM ORBs.

System properties for tracing the ORB

A new runtime debug feature provides improved serviceability. You might find it useful for problem diagnosis or it might be requested by IBM service personnel. Tracing is controlled by three system properties. Set com.ibm.CORBA.Debug=true to turn on tracing. To format and add to the trace GIOP messages sent and received, set com.ibm.CORBA.CommTrace=true. By default, ORB tracing goes to the standard error stream, java.lang.System.err. To direct it to a file, set com.ibm.CORBA.Debug.Output. For example, to trace events and formatted GIOP messages to a file:

java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.Debug.Output= -Dcom.ibm.CORBA.CommTrace=true myapp

The trace will be sent to the files orbtrc.DDMMYYYY.HHmm.SS.txt and orbmsg.DDMMYYYY.HHmm.SS.txt.

Do not turn on tracing for normal operation, because it might cause performance degradation.

The content and format of the trace output could vary from version to version.

System properties for tuning the ORB

The following properties help you to tune the ORB:

System properties for vendor ORB Compatibilty

The following properties may be necessary to enable non-standard behaviour for some vendor ORBs:

Java 2 security permissions for the ORB

When running with a Java 2 SecurityManager, invocation of some methods in the CORBA API classes might cause permission checks to be made, which could result in a SecurityException. Affected methods include the following:

Class/Interface

Method

Required permission

org.omg.CORBA.ORB

init

java.net.SocketPermission resolve

org.omg.CORBA.ORB

connect

java.net.SocketPermission listen

org.omg.CORBA.ORB

resolve_initial_references

java.net.SocketPermission connect

org.omg.CORBA.portable.ObjectImpl

_is_a

java.net.SocketPermission connect

org.omg.CORBA.portable.ObjectImpl

_non_existent

java.net.SocketPermission connect

org.omg.CORBA.portable.ObjectImpl

OutputStream _request (String, boolean)

java.net.SocketPermission connect

org.omg.CORBA.portable.ObjectImpl

_get_interface_def

java.net.SocketPermission connect

org.omg.CORBA.Request

invoke

java.net.SocketPermission connect

org.omg.CORBA.Request

send_deferred

java.net.SocketPermission connect

org.omg.CORBA.Request

send_oneway

java.net.SocketPermission connect

javax.rmi.PortableRemoteObject

narrow

java.net.SocketPermission connect

If your program uses any of these methods, ensure that it is granted the necessary permissions.

ORB implementation classes

The ORB implementation classes in this release are:

These are the default values, and you are advised not to set these properties or refer to the implementation classes directly. For portability, make references only to the CORBA API classes, and not to the implementation. Theses values might be changed in future releases.


Implementing the Connection Handler Pool for RMI

Thread pooling for RMI Connection Handlers is not enabled by default. To enable the connection pooling implemented at the RMI TCPTransport level, set the option

-Dsun.rmi.transport.tcp.connectionPool=true (or any non-null value) This version of the Runtime Environment does not have any setting that you can use to limit the number of threads in the connection pool.


RMI over IIOP

Java Remote Method Invocation (RMI) provides a straightforward mechanism to do distributed Java programming. RMI over IIOP (RMI-IIOP) extends the base Java RMI to perform communication using the CORBA standard Internet Inter-ORB Protocol (IIOP protocol). This allows direct interaction with any other CORBA Object Request Brokers (ORBs), whether they were implemented in Java or another programming language.

For information about IBM and RMI-IIOP, see the following IBM Web site:

http://www.ibm.com/developerworks/java/rmi-iiop

The following documentation is available:


Enhanced BigDecimal

The Runtime Environment includes an enhanced BigDecimal class (com.ibm.math.BigDecimal) for Java programming as an alternative to the java.math.BigDecimal class. The BigDecimal class (with its supporting class MathContext) is fully implemented and exploits the java.lang.Comparable interface, which is used for sorting in the Java 2 language.

If you are using the java.math.BigDecimal class in a Java program and you want to access the Enhanced BigDecimal class, you must change the import statement in your source code as shown.

Change:

import java.math.*;

to:

import com.ibm.math.*;

You do not need to change any other code.

More information about enhanced BigDecimal can be found at http://www2.hursley.ibm.com/decimalj/.


JNDI

The IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 provides a unified interface, the Java Naming and Directory Interface (JNDI), to the following naming and directory services:

JAAS

Also packaged with this release is the Java Authentication and Authorization Service (JAAS), version 1.0, which provides Principal-based authorization on authenticated identities.

For further details of this extension, see /usr/java13_64/docs/jaas/readme.jaas.ibm.html, after installing the Java13_64.ext.jaas fileset. 


HPROF Performance Profiler and JVMPI

IBM extensions

The Java Virtual Machine Profiling Interface (JVMPI) has been extended to include profiling in the IBM JIT. These additional definitions are defined in jvmpi.h.

GetCurrentThreadCpuTime

The JVMPI interface function GetCurrentThreadCpuTime is supported on AIX 5.1 or higher. Resource collection must be enabled with the AIX environment variable AIXTHREAD_ENRUSG set to ON, as follows:

You will get the following message output when performance profiling is switched on:

Make sure that the resource collection is disabled after your profiling session because the overhead for tracking cpu time for individual threads affects performance. Resource collection should never be enabled in a production environment. To disable the resource collection, do one of the following:

The default for the Java environment is AIXTHREAD_ENRUSG=OFF.

When the resource collection is enabled, the HPROF profiling agent, invoked with:

provides meaningful data in the HPROF output.

Known restrictions

JVMPI_EVENT_INSTRUCTION_START

This event is not currently supported in the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1. It might be added in a future release.


Debugging environment

Traditionally, libraries intended for use with java_g must be named with _g; for example, libmyapp_g.a. In the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1, if the JDK cannot locate a library named with _g, it will try to locate a library named without _g. This makes it possible to use the same library with both the regular and debug versions of the JDK. It means that a JNI application need not provide two versions of its libraries but can still work with java_g. This enhanced process for loading libraries has made it easier to use the debug version of the JDK (java_g) with JNI applications.

If the library named without _g is loaded, a warning message is printed to stderr. Only if this library cannot be found is UnsatisfiedLinkError thrown.

In the event of a core dump in your application when using the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1, you get a javacore text file in addition to the core file. The javacore file has a filename of the format of javacore<process id>.<time>.txt. The <time> is the return value from the time subroutine at the time of the core dump, so each javacore file is not overwritten as for core file.

You can determine the location of the javacore file as follows:

The location of the javacore file is written to standard error as a full pathname and is also appended, with a date/time stamp to the file "/tmp/javacore_locations". Basic file locking is used to avoid buried updates of this file.

If the javacore cannot be opened for some reason, the information is written to standard error.

The javacore file provides information of the java program at the time of the core dump. To study JNI native code, you will still need to use the core file.

To debug java programs, you can use JPDA or JDB. For native JNI binary programs, you can still use dbx for debugging.

JPDA

The Java Platform Debugger Architecture (JPDA) is supported in this release. The JPDA classes are shipped in tools.jar, which must be included when developing any java programs that intend to use JPDA. The JPDA can be used only with the JIT disabled. Only socket communication is supported on AIX.

For more information with respect to JPDA and its usage please refer to the following site: http://java.sun.com/j2se/1.3/docs/guide/jpda/

JDB

In the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1, as in Version 1.3.0, the JDB debugger starts up com.sun.tools.example.debug.tty.TTY. This version fully supports the Java Virtual Machine Debugging Interface (JVMDI). The jdb tool shipped in Version 1.2.2 is now shipped as oldjdb.

The new JDB uses the JPDA and allows the jdb example tool to attach to a listening Virtual Machine (VM) or to start a new debug session. It is invoked by the jdb command and can be used in the same way as oldjdb. Invoking jdb_g with the intention of creating a new debug session as follows:

attempts to launch a new VM using the java executable rather than the java_g executable. If the java executable is not found, jdb_g will fail.

The JDB can debug remote java applications, including java applications running on remote machines over a TCP/IP link. To debug a remote java program, the java program should start as follows:

Specify the port number by the "address" sub-option.

The port on which the JPDA is listening is displayed. At the remote debugging machine, enter:

When launching a debug session using the dt_socket transport, make sure that the specified ports are free to use.

For more information with respect to JDB and its usage please refer to the following site: http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/jdb.html

Note: Sun's documentation for using JDB assumes that the JVM to be debugged is a HotSpot JVM. However, IBM implementations of the JVM always run as a Classic JVM. So, when using IBM's JDB, always assume that the -classic option has been implicitly specified and follow the guidance for debugging a Classic JVM. This requires that the -Xnoagent option is specified unless the agent class is required, in which case specify the -Xbootclasspath option to locate it explicitly.

DBX

In addition, you can also use dbx to debug your native JNI code by specifying the full path to the java program: When you are in dbx environment:

Java Communications API

This release includes the Java Communications API 2.0 standard extension, which allows Java applications to access RS232 serial ports and IEEE 1284 parallel ports.

The API is shipped in the Java13_64.ext.commapi fileset. With the fileset at 1.3.1.1 (or higher) fix level the API supports unlimited number of tty's, with ttyn mapped to COM(n+1) where n is 0 or a positive decimal integer:

    /dev/tty0 -> COM1
    /dev/tty1 -> COM2
    ...
    /dev/tty9 -> COM10
    /dev/tty10 -> COM11
    ...
If a tty is not available then the corresponding COM port will not be available. For example, if tty0 and tty2 are available but tty1 is not, then COM1 and COM3 can be available but COM2 will not be.

For API details, see http://www.javasoft.com/products/javacomm/.


Java security tools

This release includes Java security tools shipped in these filesets: Java13_64.ext.security.cmp-us, Java13_64.ext.security.jce-us, Java13_64.ext.security.jsse-us, and Java13_64.ext.security.pkcs-us. After these filesets are installed, you can find documentation in /usr/java13_64/docs and sample code in /usr/java13_64/demo.
  • Java Cryptography Extension (JCE), version 1.2.1

    JCE provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers. The software also supports secure streams and sealed objects. For a general overview of JCE, visit http://java.sun.com/products/jce. IBM's JCE implementation provides more cryptographic algorithms than Sun's.

  • Note: After installing JCE, you must move the file ibmjcaprovider.jar from the /usr/java13_64/jre/lib/ext directory.  Otherwise, java will not work correctly.  Save the ibmjcaprovider.jar file in a safe place.  If you uninstall JCE, you must move this file back into the /usr/java13_64/jre/lib/ext directory.
  • Certificate Management Protocol (CMP)
  • CMP provides support to online interactions between Public Key Infrastructure (PKI) components. For example, a management protocol might be used between a Certificate Authority (CA) and a client system with which a key pair is associated, or between two CAs that issue cross-certificates for each other. For a full description of CMP, refer to RFC 2510 and 2511 for CRMF. These RFCs are available at http://www.ietf.org/rfc.html.
  • Public Key Cryptography Standards (PKCS)
  • As public-key cryptography begins to see wide application and acceptance, one thing is increasingly clear. If it is going to be as effective as the underlying technology allows it to be, there must be interoperability standards. Even though vendors might agree on the basic public-key techniques, compatibility between implementations is by no means guaranteed. Interoperability requires strict adherence to an agreed-upon standard format for transferred data. The IBM PKCS implementation supports the following RSA standards: PKCS #1, #3, #5, #6, #7, #8, #9, #10 and #12. Visit http://www.rsasecurity.com/rsalabs/pkcs for more information.
  • Secure Multi-Purpose Internet Mail Extensions (S/MIME)
  • S/MIME provides the Java classes needed to encode and decode S/MIME messages. This implementation provides a limited S/MIME parser geared to understanding and extracting PKCS #7 ContentInfo and PKCS #10 CertificationRequest objects from S/MIME messages. For more information on S/MIME, refer to RFC 2311 (S/MIME Version 2 Message Specification) at http://www.ietf.org/rfc.html
  • Java Secure Sockets Extension (JSSE), version 1.0.2
  • JSSE enables secure Internet communications. It implements a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication. For more information, see http://java.sun.com/products/jsse.

    To use the security providers mentioned, edit /usr/java13_64/jre/lib/security/java.security. An example of some of the providers that can be used in this file is as follows:

    security.provider.1=sun.security.provider.sun

    security.provider.2=com.ibm.crypto.provider.IBMJCE

    security.provider.3=com.ibm.jsse.JSSEProvider


    XML parser for Java

    This release also includes XML parser for Java, version 4.0.3. The fileset, Java13_64.ext.xml4j, is optionally installable. For more information, see the files in /usr/java13_64/xml4j (after installing  the fileset).  For more information on XML, see http://www.ibm.com/developerworks/xml/.


    Shipping Java applications

    A Java application, unlike a Java applet, cannot rely on a Web browser for installation and runtime services. When you ship a Java application, your software package might include the following parts:

    If you want to ship the Java Runtime Environment with your applications, go to this website and accept the JRE license agreement. If you agree with the terms and conditions, you will be able to download the JRE from:


    Accessibility

    The READMEs supplied with this Developer Kit and the Runtime Environment have been tested using screen readers. You can use a screen reader such as the Home Page Reader or the JAWS screen reader with these READMEs.

    To change the font sizes in the READMEs, use the function supplied with your browser, usually found under the View menu option.

    Java console accessibility

    The Java console does not respond to the tab key for navigation. Use the control-tab key pair to navigate the console.

    Policy Tool and accessibility

    Policy Tool does not meet accessibility requirements. Policy Tool is used to edit a JVM's security policy files. Because these files are in regular text format, you may edit them with any standard text editor (Notepad on Windows or vi on Unix systems, for example). Information on the policy file location and contents, including required format, can be found at: http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html.

    Information about the permissions granted in a policy file can be found at: http://java.sun.com/j2se/1.3/docs/guide/security/permissions.html


    Notices

    This information was developed for products and services offered in the U.S.A.

    IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the users responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

    IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

    For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:

    INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

    This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the information. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this information at any time without notice.

    Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

    IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

    Licensees of this program who wish to have information about it for the purpose of enabling (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

    Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

    The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

    Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.

    Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. 


    Trademarks

    IBM and AIX are trademarks of International Business Machines Corporation in the U.S., or other countries, or both.

    Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. The Java technology is owned and exclusively licensed by Sun Microsystems, Inc.

    Other company, product, and service names may be trademarks or service marks of others.

    This product is also based in part on the work of the FreeType Project. For more information about FreeType see http://www.freetype.org.