Skip to main content


developerWorks  >   Java™ technology  >   IBM Developer kits  >   AIX  >   IBM® AIX® Developer Kit, Java(TM) 2 Technology Edition, Version 1.3.1, 32-bit version for POWER - README  >  

AIX

 developerWorks


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

IBM® AIX® Developer Kit, Java(TM) 2 Technology Edition, Version 1.3.1, 32-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, 32-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, 2000, 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® Version 4.3.3 or later. It is not supported, and will not work, on earlier versions of the AIX operating system. See AIX Environment 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 Sun Java 1.3 Core 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 the following:

Applets that depend on the Java 1.3 APIs will not work with browsers that do not support these APIs unless you install the Java Plug-in.

AIX features

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

  • Fully compatible with Sun's Java 2 version 1.3 language, enabling "Write Once Run Anywhere".
  • Performance enhancements to make Java programs run faster.
  • The latest version of the IBM optimizing Just In Time (JIT) compiler version 4.0 with Mixed Mode Interpreter (MMI - for selective compilation of frequently executed code).
  • Efficient exploitation of AIX native threads.
  • "Handle-less" object model.
  • Fast, lightweight monitors.
  • Efficient management of large Java heaps through optimized object allocation and efficient garbage collection with JVM runtime parameters for specifying garbage collection policy.
  • Thread-local heap.
  • Support for the new European Union currency, the Euro.
  • Robust networking supporting a large number of concurrent connections.
  • Better scaling support for large numbers of threads and large numbers of file handles.
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 are as follows:

  • Java131.rte (runtime environment)
  • Java131.adt (debugger and include files)
  • Java131.ext (extensions like the Comm API and JAAS)
  • Java131.ext.security (security extensions)
  • Java131.samples (sample code)
  • Java131.msg (for pulling in locale-specific fonts)

The filesets in the above packages are:

  • Java131.rte.bin
  • Java131.rte.lib
  • Java131.adt.debug
  • Java131.adt.includes
  • Java131.ext.commapi
  • Java131.ext.jaas
  • Java131.ext.java3d
  • Java131.ext.plugin
  • Java131.ext.xml4j
  • Java131.ext.security.cmp-us
  • Java131.ext.security.jce-us
  • Java131.ext.security.jsse-us
  • Java131.ext.security.pkcs-us
  • Java131.samples.demos
  • Java131.msg.$LANG*

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:

  • /usr/java131/

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

  • export PATH=/usr/java131/jre/bin:/usr/java131/bin:$PATH

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 32-bit IBM AIX Developer Kit, Java Technology Edition, Version 1.3.1, runs on AIX 4.3.3, AIX 5.1, AIX 5.2 and AIX 5.3.

For AIX 4.3.3, which is out of support, Java 1.3.1 requires the AIX 4330-10 Recommended Maintenance Level.

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 on AIX 4.3.3, AIX 5.1 and AIX 5.2 base CDs) is required:

  • X11.fnt.ucs.ttf (for ja_JP or Ja_JP)
  • X11.fnt.ucs.ttf_CN (for zh_CN or Zh_CN)
  • X11.fnt.ucs.ttf_KR (for ko_KR)
  • X11.fnt.ucs.ttf_TW (for zh_TW or Zh_TW)

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

  • jkit.Wnn6.base 2.2.0.2 (PTF U479697 or APAR IY22917) (Wnn6 user only)
  • X11.motif.lib 5.1.0.15 (PTF U479604 or APAR IY22933) (AIX 5.1 user only)

Verification

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

  • unset LIBPATH
  • unset CLASSPATH
  • unset LD_LIBRARY_PATH
  • unset JAVA_COMPILER
  • unset JAVA_HOME*
  • export PATH=/usr/java131/jre/bin:/usr/java131/bin:$PATH

*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: java -version

you should see: 

	java version "1.3.1"
							
	Java (TM) 2 Runtime Environment, Standard Edition (build 1.3.1)
                            
	Classic VM (build 1.3.1, J2RE 1.3.1 IBM AIX build ca131-20070913)

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: ls -a ~ should confirm this.

Known problems and limitations

Audio

Audio works on the local machine but not on the remote client.

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.

Printing of Java applets when run using the Netscape plug-in is not supported. Use the applet viewer for printing.

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

On AIX 5.1, 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:
  1. Set LANG=JA_JP instead of JA_JP.UTF8  (recommended)
  2. Unset XMODIFIERS 
  3. Modify two symbolic links in /usr/lib/nls/loc as follows:
    • ln -fs /usr/lib/nls/loc/UNIVERSAL.im /usr/lib/nls/loc/JA_JP.UTF-8@alt.im
    • ln -fs /usr/lib/nls/loc/UNIVERSAL.im__64 /usr/lib/nls/loc/JA_JP.UTF-8@alt.im__64
    When the bos.loc.utf.JA_JP fileset is installed, the bos.loc.pc.Ja_JP fileset should also be installed as a corequisite. These filesets are provided on the base AIX 5.1 CDs.

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. 

Java Plug-in abnormal termination

The Java Plug-in for AIX might terminate abnormally when FileDialog is to be displayed under UTF8 locale with Japanese Input Method Wnn6 active. If this occurs, use AIXIM instead of Wnn6 for Japanese Input Method. A future release of libX11.a from AIX will fix this problem.

JIT

Java applications that throw exceptions on multiple threads may 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 Java131.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.

Contents of the Developer Kit

The following list shows the contents of the Developer Kit.

Runtime:
Core Classes (rt.jar)
This file contains all of the compiled .class files for the platform. Do not modify these classes; instead, create subclasses and override where you need to.
Tools: The tools provided include:
Java Compiler (javac):
- Compiles programs written in the Java programming language into bytecodes (compiled Java code).
Java Interpreter (java):
- Executes Java bytecodes. The Java Interpreter runs programs written in the Java programming language.
Java Applet Viewer (appletviewer):
- Use for testing and running applets.
Java Debugger (jdb):
- Helps debug your Java programs.
Class File Disassembler (javap):
- Disassembles compiled files and prints a representation of the bytecodes.
Java Documentation Generator (javadoc):
- Parses the declarations and documentation comments in a set of source files and produces a set of HTML pages describing the public and protected classes, interfaces, constructors, methods, and fields. Also produces a class hierarchy and an index of all members.
C Header and Stub File Generator (javah):
- Attaches native methods to code written in the Java programming language.
Java Archive Tool (jar):
- Generates signatures for Java Archive (JAR) files, and verifies the signatures of signed JAR files.
JAR Signing and Verification Tool (jarsigner):
- Manages entities, including their keys, certificates, and the trust associated with them.
Key and Certificate Management Tool (keytool):
- Manages a keystore (database) of private keys and their associated X.509 certificate chains authenticating the corresponding public keys.
Policy File Creation and Management Tool (policytool):
- Creates and modifies the external policy configuration files that define your installation's Java security policy.
Native-To-ASCII Converter (native2ascii):
- Converts a native encoding file to an ASCII file that includes the \udddd Unicode notation.
Java Remote Method Invocation (RMI) Stub Converter (rmic):
- Generates objects from the names of compiled classes that contain remote object implementations. Includes RMI-IIOP support.
RMI activation system daemon (rmid):
- Starts the activation system daemon so that objects can be registered and activated in a Java virtual machine (JVM).
IDL to Java Compiler (idlj):
- Compiles OMG Interface Definition Language files to Java code.
CORBA Naming Service (tnameserv):
- Starts the CORBA transient naming service.
Java Remote Object Registry (rmiregistry):
- Creates and starts a remote object registry on the specified port of the current host.
Serial Version Command (serialver):
- Returns the serialVersionUID for one or more classes in a form suitable for copying into an evolving class.
Extcheck utility (extcheck):
- Detects version conflicts between a target jar file and currently installed extension jar files.
Various C libraries and include files.

Developer Kit README: This file, README.HTML, which is in the docs subdirectory of 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: Java131.samples is an optional package with the following subdirectories installed in the /usr/java131/demo directory:

  • applets: Demo programs for applets.
  • bigdecimal: Sample programs and README for enhanced BigDecimal class.
  • jdbcodbc: Example programs and README for Jdbc-Odbc Bridge.
  • jfc: Demo programs for Swing and Java2D.
  • jni: Example programs and README for developing JNI programs on AIX.
  • jpda: Example programs for JPDA.
  • rmi-iiop: Example programs for RMI-IIOP.
  • Sound: Demo programs for Sound.
  • xml4j: Demo programs for XML parsing
  • misc: Miscellaneous demo programs

The Java security packages install the following subdirectories in /usr/java131/demo directory:

  • cmp: Demo programs for Certificate Management Protocol.
  • ikeyman: Demo programs for iKeyman (IBM key tool).
  • jce: Demo programs for Java Cryptographic Extension.
  • jsse: Demo programs for Java Secure Sockets Extension.
  • pkcs: Demo programs for Public Key Cryptographic Standards.

Note:

See the documentation directory (/usr/java131/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, make sure you 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: #

  • Improvements to optimizations implemented in previous versions of the JIT
  • Optimizations added to JIT v4.0
  • Stack allocation of objects
  • Improved hardware exploitation
  • Startup time improvements with the -Xquickstart option

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:

  1. Type the following at a command prompt:
    • For the Korn shell:
      • export JAVA_COMPILER=NONE
        • (Korn shell commands are used for the rest of this README)
    • For the Bourne shell:
      • JAVA_COMPILER=NONE
      • export JAVA_COMPILER
    • For the C shell:
      • A_COMPILER NONE
  2. Use the -D option on the java command to set java.compiler to NONE to override the default or the environment variable settings:
    • java -Djava.compiler=NONE <myapp>

Enabling the JIT

To enable the JIT, set the JAVA_COMPILER to "jitc" or switch the JIT compiler on through the command line:

  • java -Djava.compiler=jitc <myapp>

Determining whether the JIT is enabled

To determine if the JIT is enabled, type the following at a command prompt:

  • java -version

If the JIT is not in use, a message is displayed that includes the following:

  • JIT disabled

If the JIT is in use, a message is displayed that includes the following:

  • JIT enabled: jitc

Note:

If JAVA_COMPILER="" or -Djava.compiler="", the JIT compiler is disabled.

If JAVA_COMPILER is unset, as in: unset JAVA_COMPILER 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/java131/bin, you can compile a file named myfile.java by typing the following at a command prompt: 

   /usr/java131/bin/javac myfile.java


Alternatively, you can add the string /usr/java131/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/java131/bin:/usr/java131/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: 
   java

                        

                        
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: 
   java -X

                        

                        
To get help on profiling options of java, type: 
   javaSimilarlyrof:help

                        

                        
Similarly, javac command options can be obtained with the following command: 
   javac

                        

                        
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: 
						
   javac -Jflag *.java

                        

                        
For example, to disable the JIT when compiling classes, the command is: 
   javac -J-Djava.compiler=none *.java

                        

                        
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 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: 
						
   exportIBM_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: 
    
                            
  • JIT is on, but you can disable the JIT. 
    • 
                            
  • Initial Java heap size is 1M. Use -Xms<number> to change size. 
    • 
                            
  • Maximum Java heap size is 64M. Use -Xmx<number> to change size.
    • 
                          

                        

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

                        

                        
Setting the CLASSPATH

                        
The CLASSPATH tells the Java Virtual Machine (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/java131/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.1), 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: 
   echo $CLASSPATH

                        

                        
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: 
						
   export AIXTHREAD_SCOPE=S

                        
   export AIXTHREAD_MUTEX_DEBUG=OFF

                        
   export AIXTHREAD_RWLOCK_DEBUG=OFF

                        
   export AIXTHREAD_COND_DEBUG=OFF

                        

                        
 For more information on these environment variables, 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/java131, 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 
    
                            
  •  If you are using other shared libraries (such as libraries you develop). In this case, you will need to set LIBPATH to include the directory or directories containing your libraries.
    • 
                            
  •  If you use the JNI Invocation API to launch a JVM from one of your own programs. In this case you will need to set LIBPATH to include the directories containing the JVM libraries, plus those containing any libraries of your own.
    • 
                          
 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: 
						
                          

                        

                        
Java Plug-in HTML converter

                        
The Java Plug-in HTML Converter is a utility that allows you to convert any HTML page that contains applets to a format that will use the Java Plug-in. The utility is in the sdk/bin directory with a jar file in sdk/lib. 

                        
For more information about the Java Plug-in HTML Converter, see this Sun Web site: 
						

                          

                        

                        
Change in behavior of StringTokenizer class
Consider the following string of tokens: 
						
    
							
  • opcode:attributeName:attributeValue\t
    • 
						

                        
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: 
						

						

                        
Then select "General Programming Concepts: Writing and Debugging Programs -> Threads Programming Guidelines -> Threads Scheduling". 

                        

                        
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: 
						
   java -ss<size> <other params>

                        

                        
For maximum file descriptors, use the command line statement ulimit, for example: 
						
   ulimit -n 3000
 or chuser, for example: 
   chuser nofiles=3000 <user_id>

                        

                        
to increase the limit. (ulimit -a shows the current limit.) 

                        

                        
Large program model support

                        
The JVM of the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 supports the large program model. For more details on the large program model, see: 
						

                        

                        
Then select "General Programming Concepts: Writing and Debugging Programs -> Large Program Support -> Understanding the Large Address-Space Model". 
Note: AIX's Very Large Address-Space Model is not supported by Java 1.3.1. 

                        
By default, Java runs using the eight segments. (Eight is the maximum value allowed; each segment is 256 MB). You can reduce the number of segments Java uses with the LDR_CNTRL environment variable. For example, if you want Java to use only three segments set LDR_CNTRL to the following value prior to starting Java: 
   export LDR_CNTRL=MAXDATA=0x30000000
 If your native methods use a lot of shared memory (for example, with functions like shmat() and mmap()), you might need to reduce the number of segments used by Java. You might also find that you need to reduce the number of segments used by Java when concurrently running Java with other applications that use shared memory, particularly those that explicitly specify the address where a shared memory segment is attached (rather than letting AIX choose the address).

                        
Specifying LDR_CNTRL=MAXDATA=0 restricts a program to one segment for data. However, if a Java invocation specifies a heap of greater than 1 GB, the JVM switches from allocating the Java heap in the data area to doing an mmap. Therefore, for a Java heap less than or equal to 1 GB, you should not specify LDR_CNTRL=MAXDATA=0 (which uses the normal large data support). With a Java heap of greater than 1 GB, specify LDR_CNTRL=MAXDATA=0 to free up data segments for use by the mmap.

                        
If you are running with very large heap sizes (in general, greater than 2GB), you have limited memory available for non-object allocation. In this situation, you might see Out of Memory exceptions. Also, the JVM might not close down cleanly because further storage allocations are required to shut down the JVM, and these allocations will probably fail.

                        

                        
JNI compatibility

                        
The C/C++ compiler on AIX 4.3 is installed in /usr/ibmcxx and on AIX 5.1 is installed in /usr/vacpp. Because of incompatibility between the IBM AIX Developer Kit, Java 2 Technology Edition, Version 1.3.1 and some system-defined types, compilation of JNI code requires that the compiler uses the flag _AIX43. This flag is defined by default in /etc/ibmcxx.cfg on AIX 4.3 and defined in /etc/vac.cfg and /etc/vacpp.cfg on AIX 5.1. But, if you are using a version of xlc prior to v3.6.4 on AIX 4.3, you must add _AIX43 to /etc/xlC.cfg or use -D_AIX43 as a compilation command-line option. Also, make sure that you are building while in the correct Developer Kit environment. 

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

                        
Compatibility of an executable program can be verified using: 
   dump -ov

                        

                        
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. Where 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. This can be controlled using the following environment setting: 

                        
   export AIXTHREAD_SCOPE=S

                        
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: 
						  

                        

                        
Then select: "Understanding Threads". 

                        
AIX sets default value of the AIXTHREAD_MUTEX_DEBUG, AIXTHREAD_RWLOCK_DEBUG and AIX_THREAD_COND_DEBUG environment variables ON. A JNI program that creates and attaches to a JVM must set these environment variables OFF. See:  http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365a81.htm#34490 (for AIX 4.3.3) and  http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365a81.htm#HDRI34490 (for AIX 5.1). 

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

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

                        

                        
Fonts and locales

                        
Certain performance enhancements have been added to improve text-draw operations in the case of simple text. If you experience problems with text or with fonts, try disabling this performance enhancement by setting the environment variable: 
						
   export JAVA2D_USEAWTFONTS=0

                        

                        
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. 

                        
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. The fonts are installed automatically if you install the UTF8 locales.

                        
 Also, Java 1.3.1 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. The user interface is provided in these languages:

                        
    
                          
  • Brazilian Portuguese
    • 
                          
  • Catalan
    • 
                          
  • Czech
    • 
                          
  • English
    • 
                          
  • French
    • 
                          
  • German
    • 
                          
  • Hungarian
    • 
                          
  • Italian
    • 
                          
  • Japanese
    • 
                          
  • Korean
    • 
                          
  • Polish
    • 
                          
  • Russian
    • 
                          
  • Simplified Chinese
    • 
                          
  • Slovak
    • 
                          
  • Spanish
    • 
                          
  • Traditional Chinese
    • 
                        

                        
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, 32-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:

                        
    
							
  • org.omg.CORBA.LocalObject
    • 
							
  • org.omg.Dynamic.Parameter
    • 
							
  • org.omg.IOP.Codec
    • 
							
  • org.omg.IOP.CodecFactory
    • 
							
  • org.omg.IOP.CodecFactoryHelper
    • 
							
  • org.omg.IOP.CodecFactoryOperations
    • 
							
  • org.omg.IOP.CodecFactoryPackage.UnknownEncoding
    • 
							
  • org.omg.IOP.CodecOperations
    • 
							
  • org.omg.IOP.CodecPackage.FormatMismatch
    • 
							
  • org.omg.IOP.CodecPackage.InvalidTypeForEncoding
    • 
							
  • org.omg.IOP.CodecPackage.TypeMismatch
    • 
							
  • org.omg.IOP.ENCODING_CDR_ENCAPS
    • 
							
  • org.omg.IOP.Encoding
    • 
							
  • org.omg.IOP.ServiceContext
    • 
							
  • org.omg.IOP.TaggedComponent
    • 
							
  • org.omg.IOP.TaggedProfile
    • 
							
  • org.omg.Messaging.SYNC_NONE
    • 
							
  • org.omg.Messaging.SYNC_WITH_SERVER
    • 
							
  • org.omg.Messaging.SYNC_WITH_TARGET
    • 
							
  • org.omg.Messaging.SYNC_WITH_TRANSPORT
    • 
							
  • org.omg.PortableInterceptor.ClientRequestInfo
    • 
							
  • org.omg.PortableInterceptor.ClientRequestInfoOperations
    • 
							
  • org.omg.PortableInterceptor.ClientRequestInterceptor
    • 
							
  • org.omg.PortableInterceptor.ClientRequestInterceptorOperations
    • 
							
  • org.omg.PortableInterceptor.Current
    • 
							
  • org.omg.PortableInterceptor.CurrentHelper
    • 
							
  • org.omg.PortableInterceptor.CurrentOperations
    • 
							
  • org.omg.PortableInterceptor.ForwardRequest
    • 
							
  • org.omg.PortableInterceptor.IORInfo
    • 
							
  • org.omg.PortableInterceptor.IORInfoOperations
    • 
							
  • org.omg.PortableInterceptor.IORInterceptor
    • 
							
  • org.omg.PortableInterceptor.IORInterceptorOperations
    • 
							
  • org.omg.PortableInterceptor.Interceptor
    • 
							
  • org.omg.PortableInterceptor.InterceptorOperations
    • 
							
  • org.omg.PortableInterceptor.InvalidSlot
    • 
							
  • org.omg.PortableInterceptor.LOCATION_FORWARD
    • 
							
  • org.omg.PortableInterceptor.ORBInitInfo
    • 
							
  • org.omg.PortableInterceptor.ORBInitInfoOperations
    • 
							
  • org.omg.PortableInterceptor.ORBInitInfoPackage.DuplicateName
    • 
							
  • org.omg.PortableInterceptor.ORBInitInfoPackage.InvalidName
    • 
							
  • org.omg.PortableInterceptor.ORBInitializer
    • 
							
  • org.omg.PortableInterceptor.ORBInitializerOperations
    • 
							
  • org.omg.PortableInterceptor.PolicyFactory
    • 
							
  • org.omg.PortableInterceptor.PolicyFactoryOperations
    • 
							
  • org.omg.PortableInterceptor.RequestInfo
    • 
							
  • org.omg.PortableInterceptor.RequestInfoOperations
    • 
							
  • org.omg.PortableInterceptor.SUCCESSFUL
    • 
							
  • org.omg.PortableInterceptor.SYSTEM_EXCEPTION
    • 
							
  • org.omg.PortableInterceptor.ServerRequestInfo
    • 
							
  • org.omg.PortableInterceptor.ServerRequestInfoOperations
    • 
							
  • org.omg.PortableInterceptor.ServerRequestInterceptor
    • 
							
  • org.omg.PortableInterceptor.ServerRequestInterceptorOperations
    • 
							
  • org.omg.PortableInterceptor.TRANSPORT_RETRY
    • 
							
  • org.omg.PortableInterceptor.USER_EXCEPTION
    • 
                        

                        
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:

							
    
								
  • omg.CosNaming.NamingContextExt
    • 
								
  • org.omg.CosNaming.NamingContextExtHelper
    • 
								
  • org.omg.CosNaming.NamingContextExtHolder
    • 
								
  • org.omg.CosNaming.NamingContextExtOperations
    • 
								
  • org.omg.CosNaming.NamingContextExtPackage.AddressHelper
    • 
								
  • org.omg.CosNaming.NamingContextExtPackage.InvalidAddress
    • 
								
  • org.omg.CosNaming.NamingContextExtPackage.InvalidAddressHelper
    • 
								
  • org.omg.CosNaming.NamingContextExtPackage.InvalidAddressHolder
    • 
								
  • org.omg.CosNaming.NamingContextExtPackage.StringNameHelper
    • 
								
  • org.omg.CosNaming.NamingContextExtPackage.URLStringHelper
    • 
								
  • org.omg.CosNaming._NamingContextExtImplBase
    • 
								
  • org.omg.CosNaming._NamingContextExtStub
    • 
							

                        
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:

                        
    
                          
  • To control GIOP 1.2 fragmentation, set the system property com.ibm.CORBA.FragmentSize. For example, to set the fragment size to 4096 bytes: 
						  
       java -Dcom.ibm.CORBA.FragmentSize=4096 myapp
    
						  
    The default fragment size is 1024 bytes. You can turn off fragmentation by setting the fragment size to 0. 
    
                          
    • 
                          
  • In a heterogeneous network, the response to a CORBA Request could be delayed or lost. You can set the maximum time to wait using the system property com.ibm.CORBA.RequestTimeout. Also, you can use com.ibm.CORBA.LocateRequestTimeout to control the timeout for LocateRequests. For example, to restrict both delays to 30 seconds: 
						  
       java -Dcom.ibm.CORBA.RequestTimeout=30 -Dcom.ibm.CORBA.LocateRequestTimeout=30 myapp
    
						
    By default, the ORB waits indefinitely for a response. Do not set the timeout too low, or connections might be ended unnecessarily.
    
                          
    • 
                          
  • If your program is providing a service in the network, you might have to set to a well-known value the number of the port from which the ORB reads incoming requests. You can control this using the system property com.ibm.CORBA.ListenerPort. For example, to make the ORB use port 1050: 
						  
       java -Dcom.ibm.CORBA.ListenerPort=1050 myapp
    
						  
    If this property is set, the ORB starts listening as soon as it is initialized. Otherwise, it starts listening only when required. 
    
                          
    • 
                        

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

                        
    
                          
  • To use the POA ImplicitActivation policy with, for example, older Visibroker ORBs, it may be necessary to set the system property com.ibm.CORBA.POACompatibilityMode=true
    This property causes non-standard system exception, CORBA::OBJ_ADAPTER, to be thrown from org.omg.PortableServer.Servant._get_delegate when the delegate is null, in place of the standard exception CORBA::BAD_INV_ORDER. 
    
                            
    When using an ORB whose POA implementation relies upon receiving the CORBA::OBJ_ADAPTER system exception without this property set, the following failure may be observed: org.omg.CORBA.INTERNAL:org.omg.CORBA.BAD_INV_ORDER: The Servant has not been associated with an ORBinstance
    
                          
    • 
                        

						
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:

                        
    
							
  • org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
    • 
							
  • org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton
    • 
							
  • javax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.UtilDelegateImpl
    • 
							
  • javax.rmi.CORBA.StubClass=com.ibm.rmi.javax.rmi.CORBA.StubDelegateImpl
    • 
							
  • javax.rmi.CORBA.PortableRemoteObjectClass=com.ibm.rmi.javax.rmi.PortableRemoteObject 
    • 
						

                        
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: 
						
    
                            
  • The RMI-IIOP Programmer's Guide is an introduction to writing RMI-IIOP programs. The guide is installed when you install the Developer Kit and is on the Web site under "Documents". 
    
                              
    
                            
    • 
                            
  • The IDL-to-Java Compiler User's Guide describes how to use the tool that generates Java code from IDL. The guide is installed when you install the Developer Kit and is on the Web site under "Documents". 
    
                              
    
                            
    • 
                            
  • The samples directory contains: 
							   
      
                                
    • A Hello World example that can switch between the Java Remote Method Protocol (JRMP) and IIOP protocols (demo/rmi-iiop/hello) 
      • 
                                
    • A Hello World example that interacts with a standard IDL program (demo/rmi-iiop/idl)
      • 
                              
    
                              
    
                              
    
                            
    • 
                            
  • The Java Language to IDL Mapping document is a detailed technical specification of RMI-IIOP and can be found at the following FTP site: http://cgi.omg.org/cgi-bin/doc?ptc/00-01-06.pdf
    • 
                          

                          

                        

                        
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 new 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/

                        
JDBC-ODBC Bridge

                        
This Developer Kit includes a JDBC-ODBC bridge which supports JDBC 2.0. You need ODBC Driver Manager of version 3.5.0 or above to work with this release of JDBC-ODBC Bridge. The bridge assumes that your ODBC driver can support concurrency and therefore you are expected to provide locking in your application if necessary. 

                        
To use the JDBC-ODBC Bridge, you set up your own ODBC driver to work with the target database. You set up the JDBC-ODBC bridge only after you have successfully tested your ODBC driver. Check the following websites to obtain information about ODBC drivers for your DB2 Universal database or for other non-IBM databases. The ODBC driver will typically be in libodbc.a in /usr/lib. This library is imported during the time when the JDBC-ODBC Bridge library libJdbcOdbc.a is loaded at runtime. 

                        
The Bridge is expecting member libodbc.o in libodbc.a. Check the member name in your libodbc.a using the following command: 
						
   dump -H libodbc.a

                        

                        
If your libodbc.a has a different member name for libodbc.a, for example, odbc.so, perform the following operations after saving your original libodbc.a in a backup directory. 

                        
To extract and rename the member: 
   ar -p libodbc.a odbc.so > libodbc.o

                        

                        
To add the libodbc.o member to libodbc.a: 
   ar -v -r libodbc.a libodbc.o

                        

                        
Finally, to delete the odbc.so member from libodbc.a:
    ar -v -d libodbc.a odbc.so

                        

                        
There is a README file and some example programs in the /usr/java131/demo/jdbcodbc directory. The examples can be optionally installed with the package Java131.samples. 

                        

                        
JNDI

                        
This Developer Kit provides a unified interface, the Java Naming and Directory Interface (JNDI), to the following naming and directory services: 
						
    
                            
  • Lightweight Directory Access Protocol (LDAP) 
    • 
                            
  • Corba Object Services (COS) Naming Service 
    • 
                            
  • RMI Registry 
    • 
                            
  • filesystem 
    • 
                        

                          

                        

                        
JAAS

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

                        
For further details of this extension, see /usr/java131/docs/jaas/readme.jaas.ibm.html, after installing the Java131.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

                        
    
                          
  • AIX 4.3.3
    The JVMPI interface function GetCurrentThreadCpuTime does not currently return accumulated thread CPU time. CPU times are returned as 0 from GetCurrentThreadCpuTime. This restriction applies to any profiling agent that makes use of thread CPU time, including the supplied HPROF profiling agent when invoked with -Xrunhprof:cpu=times. In this case, CPU time is displayed as NaNQ% in the HPROF output. 
    
                            
    An alternative source of CPU data is to invoke HPROF with -Xrunhprof:cpu=samples, which provides estimates of thread CPU from a sampling technique. The JIT compiler must be disabled to provide data with this option. 
    
                            
    
                            
    
                          
    • 
                          
  • AIX 5.1 and 5.2
    The JVMPI interface function GetCurrentThreadCpuTime is supported on AIX 5.1. Resource collection must be enabled with AIX environment variable AIXTHREAD_ENRUSG set to ON, as follows: 
						  
       export AIXTHREAD_ENRUSG=ON
    
                            
    
                            
    You see the following message output when performance profiling is switched on: 
       Warning: Performance profiling is enabled and can cause performance degradation.
       Warning: You can unset AIXTHREAD_ENRUSG to disable performance profiling.
    
                            
    
                            
    Make sure that the resource collection is disabled after your profiling session because the overhead for tracking cpu time for individual threads will affect performance. Do not enable resource collection in a production environment. To disable the resource collection, do one of the following: 
							
       unset AIXTHREAD_ENRUSG
       export AIXTHREAD_ENRUSG=OFF

                            

                            
The default for the Java environment is AIXTHREAD_ENRUSG=OFF. When resource collection is disabled, all profiling behavior will be as if you are running on AIX Level below 5.1. 

                            
When the resource collection is enabled, HPROF profiling agent invoked with -Xrunhprof:cpu=times 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 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, 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:

									
     
										
  1. If the environment variable IBM_JAVACOREDIR refers to a writable directory, the javacore file is written to that directory.
    2. 
										
  2. Otherwise, if the current working directory is writable, the javacore file is written there.
    3. 
										
  3. Otherwise, if the environment variable TMPDIR refers to a writable directory, the javacore file is written to that directory.
    4. 
										
  4. Otherwise, the javacore file is written to the "/tmp" directory.
    5. 
									

								
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: 
								
   jdb_g -launch <myapp>

                                

                                
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: 
								
   java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y -Djava.compiler=NONE <other args> <myapp> <myapp class args>

                                

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

                                
The port on which the JPDA is listening is displayed. At the remote debugging machine, the following should be done: 
   jdb -attach <machine name or ip address>:<port>

                                

                                
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 the -Xbootclasspath option should be specified 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: 
   dbx /usr/java131/jre/bin/java

                                

                                
When you are in dbx environment: 
   run <MyAppClass>

                                  

                                

                                
Java Plug-in/Appletviewer

                                
If you use the Applet Viewer to run an applet that is in the CLASSPATH, you might get an AccessControlException in Swing. Because the CLASSPATH implicitly contains the current directory ".", this exception might occur if you run the Java Plug-in in the same directory as the applet class itself. 

                                
To work around this problem, make sure that: 
    
                                    
  • There are no CLASSPATH references to the applet you are attempting to run in the Java Plug-in or the appletviewer. 
    • 
                                    
  • You are not running the applet from the same directory as the class. 
    • 
                                  

                                

                                
Java Plug-in for Netscape Communicator V4 for AIX

                                
 The Java Plug-in for Netscape Communicator V4 for AIX should offer the same level of features as the latest Java Plug-in for the Solaris operating system. This plug-in has been specifically designed for this release, and will not work with earlier Java 1.1.x releases for AIX. There is also a known limitation with Japanese text parameters in this release. Specifically, if you define Japanese text parameters in a HTML file for the Java Plug-in to read, that text might be corrupted by Netscape before the Java Plug-in receives the parameters, resulting in garbage text strings passed to the applet. English parameter text appears correctly. 

                                
The AIX install for the Java Plug-in creates the symbolic link javaplugin.a in /usr/netscape/communicator/plugins, under the assumption that Netscape for AIX is installed there. If you have installed Netscape in a different directory, create the link in the appropriate directory where you have installed Netscape. You are no longer required to extend the LIBPATH for the Java Plug-in as in AIX JDK 1.2.2. In addition, to work around issues with Netscape's version of the C runtime (libc.a), any LIBPATH entries that contain "netscape/communicator" are ignored in the LIBPATH passed to the Plug-in's JVM. The Plug-in's JVM should load the system C runtime (/lib/libc.a) only. The side effect of this is that LIBPATH dependent JVM calls (such as System.loadLibrary()) return an UnsatisifiedLinkError exception if you attempt to load a shared library from a "netscape/communicator" path from within the Plug-in. 

                                
Java Plug-in Console

                                
You can alter the properties of the Java Plug-in from the control panel, which can be run as a standalone Java application. To launch this Java application, run the shell script: 
   /usr/java131/jre/bin/JavaPluginControlPanel

                                
The Java Plug-in for AIX was designed to work with Netscape 4.5 or above and will not load with earlier versions of the Netscape browser that shipped with the AIX operating system. In addition, if you are using a version of the Netscape browser other than an IBM version (such as 4.51i, 4.61i, 4.71i), you must patch that version with AIX specific fixes available at: 
								

                                

                                
Notes:
    
                                    
  1. Because Versions 1.3.1, 1.3.0, and 1.2.2 install javaplugin.a in /usr/netscape/communicator/plugins, the version installed last wins. The file, javaplugin.a, is installed in /usr/java131/jre/bin (for Version 1.3.1) and in /usr/java_dev2/jre/bin (for 1.2.2, with Java_dev2.ext.plugin 1.2.2.3 or above). When the 1.3.1 plug-in is loaded, "Help About Plug-ins" in Netscape Communicator will return "J2RE 1.3.1 IBM build", among other information. 
    2. 
                                    
  2. There must be only one plug-in shared library in /usr/netscape/communicator/plug-ins. Netscape attempts to load anything in that directory or subdirectories underneath it as a plug-in, and you do not want two versions of the Java Plug-in loaded. 
    3. 
                                  

                                

                                
Java Plug-in for Mozilla for AIX

                                
The Mozilla for AIX Web browser is available from: 

                                

                                  

                                

                                
Install Mozilla following the instructions on the CD or the Web site. Once Mozilla is installed, create one of the following links to use the Java Plug-in: 

                                

                                  
 ln -sf /usr/java131/jre/bin/libjavaplugin_oji.a /usr/mozilla/base/plugins/libjavaplugin_oji.a

								  or: 
								  
 ln -sf /usr/java131/jre/bin/libjavaplugin_oji.a $HOME/.mozilla/plugins/libjavaplugin_oji.a

                                
To verify that the Java Plug-in is available and enabled, in Mozilla select Help -> About Plug-ins. 

                                

                                

                                
This Java Plug-in supports Mozilla 1.4 and backward-compatible newer versions shipped as an option of the AIX operating system. 

                                

                                

                                
Note that you can have only one Java Plug-in shared library in /usr/mozilla/base/plugins. Mozilla attempts to load anything that is in this directory (or subdirectories underneath it) as a Plug-in, and results are unpredictable if two versions of the Java Plug-in are loaded. Specifically, remove any libjavaplugin_oji.so file in this directory. The libjavaplugin_oji.so file is part of Java 1.4. 

                                

                                

                                
Visual Age C/C++ compiler object model

                                
The Mozilla Java Plug-in is compiled with the Visual Age C/C++ compiler object model, -qobjmodel=compat. Only versions of Mozilla that were compiled with the same compiler object model work with the Mozilla Java Plug-in. 

                                

                                

                                
To find out the compiler object model with which your Mozilla has been compiled, type about:buildconfig in the URL field of Mozilla. If Mozilla was compiled with the ibm object model, the text -qobjmodel=ibm will appear in the "Compiler Flags" section of the build configuration options; if Mozilla was compiled with the compat object model, the "Compiler Flags" section will not display any objmodel information.. 

                                

                                  

                                

                                
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 Java131.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: Java131.ext.security.cmp-us, Java131.ext.security.jce-us, Java131.ext.security.jsse-us, and Java131.ext.security.pkcs-us. After these filesets are installed, you can find documentation in /usr/java131/docs and sample code in /usr/java131/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/java131/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/java131/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/java131/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
    
                          
    
                          
    
                          
    Java 3D for AIX
    
                          
     This release includes Java 3D for AIX, version 1.2.1. The fileset, Java131.ext.java3d, is optionally installable. For more information, read file /usr/java131/java3d/README.txt (after installing the fileset). 
    
                          
    
                          
    XML parser for Java
    
                          
     This release also includes XML parser for Java, version 4.0.3. The fileset, Java131.ext.xml4j, is optionally installable. For more information, see the files in /usr/java131/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: 
							
      
                              
    • Your own class, resource, and data files 
      • 
                              
    • A runtime environment 
      • 
                              
    • An installation procedure or program 
      • 
                            
    
                          
    
                          
    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: 
						  
      
							
    • IBM Director of Licensing
      IBM Corporation 
      North Castle Drive, Armonk
      NY 10504-1758 U.S.A.
      • 
						  
    
                          
    
                          
    For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: 
						  
      
							
    • IBM World Trade Asia Corporation Licensing
      2-31 Roppongi 3-chome, Minato-ku
      Tokyo 106, Japan
      • 
						  
    
                          
    
                          
    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: 
						  
       
							
    • JTCMAIL@uk.ibm.com
      [IBM Java Technology Center (JTC) 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. 
    
                        
                      
    
                        		
                  
    
                
    
                

    

    


    

    



    
    		

Back to top


    

    
    		

    

    

    

    

                
                  		
              
              
              
              
                
    
                  
    
                    Document options
                  
    
                
    
                
    
                  
    
                    
                      
    
                        



    



    Document options requiring JavaScript are not displayed
    		

    

                      
    
                        		
                  
    
                
    
                
                
    
                
    

    Related information
    

    

    

    


    

General SDK FAQs
    

    


    

Newsgroups
    

    


    

Future plans
    

    


    

    


                
                
    
                
                
    Special offers
    Rate and  Review Rational products
    DB2 pureScale Unlimited capacity for your data
    WebSphere Application Server Hypervisor trial
    More offers