Note: Before using this information and the product it supports, be sure to read the general information under Notices.
This edition of the User Guide applies to the IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0, and to all subsequent releases, modifications, and Service Refreshes, until otherwise indicated in new editions.
(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All rights reserved.
(c) Copyright International Business Machines Corporation, 1999, 2007. All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
This User Guide provides general information about the IBM(R) 32-bit SDK and Runtime Environment for Windows(R), Java(TM) 2 Technology Edition, Version 5.0 and specific information about any differences in the IBM implementation compared with the Sun implementation. Read this User Guide in conjunction with the more extensive documentation on the Sun Web site: http://java.sun.com.
The SDK and Runtime Environment are supported on the following products:
Note that IPv6 is not supported on Windows 2000.
|From Version 5.0, Service Refresh |5, these Virtualized Environments are supported: VMWare, Xen, and MS Virtual |Server.
The Diagnostics Guide provides more detailed information about the IBM Virtual Machine for Java.
Technical changes made to this User Guide for Version 5.0, other than minor or obvious ones such as updating "1.4.2" to "5.0", are indicated in red when viewing in HTML or in a color-printed copy and by vertical bars to the left of the changes.
The terms "Runtime Environment" and "Java Virtual Machine" are used interchangeably throughout this User Guide.
The IBM SDK is a development environment for writing and running applets and applications that conform to the Java 5.0 Core Application Program Interface (API).
The SDK includes the Runtime Environment for Windows, which enables you only to run Java applications. If you have installed the SDK, the Runtime Environment is included.
The Runtime Environment contains the Java Virtual Machine and supporting files including class files. The Runtime Environment contains only a subset of the classes that are found in the SDK and allows you to support a Java program at runtime but does not allow you to compile Java programs. The Runtime Environment for Windows does not include any of the development tools, such as appletviewer.exe or the Java compiler (javac.exe), or classes that are only for development systems.
In addition, the Java Communications application programming interface (API) package is provided for use with the Runtime Environment for Windows. You can find information about it in Using the Java Communications API (JavaComm).
In general, any applet or application that ran with a previous version of the SDK should run correctly with the IBM 32-bit SDK for Windows, v5.0. Classes compiled with this release are not guaranteed to work on previous releases.
|The IBM 32-bit SDK for Windows, V5.0, |is built with Microsoft Visual Studio .NET 2003.
To read Sun's documentation on compatibility, see the Sun Web site at http://java.sun.com.
If you are upgrading the SDK from a previous release, back up all the configuration files and security policy files before you start 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.
From Version 5.0, the IBM Runtime Environment for Windows contains new versions of the IBM Virtual Machine for Java and the Just-In-Time (JIT) compiler. If you are migrating from an older IBM Runtime Environment, note that:
The SDK contains several development tools and a Java Runtime Environment (JRE). This section describes the contents of the SDK tools and the Runtime Environment.
Applications written entirely in Java should have no dependencies on the IBM SDK's directory structure (or files in those directories). Any dependency on the SDK's directory structure (or the files in those directories) could result in application portability problems. Java Native Interface (JNI) applications will have some minor dependencies.
Note: The User Guides, Javadoc, and the accompanying license, copyright files, javadoc, and demo directory are the only documentation included in this SDK for Windows. You can view Sun's software documentation by visiting the Sun Web site, or you can download Sun's software documentation package from the Sun Web site: http://java.sun.com.
To install the SDK or the Runtime Environment package, download the relevant installation package. Ensure that you download all packages to the same directory. The packages and their file names are listed in Attended (interactive) installation; do not change the packages' file names.
Before you begin to install, ensure that there is enough space in your C:\WINDOWS\TEMP directory to use during installation. The amount of temporary space required in the TEMP directory during installation is:
If you do not have enough temporary space, the installation program generates an error and terminates the installation. If you do have enough temporary space but still see this message, verify that the packages you are attempting to install were downloaded completely. You can do this by comparing the file sizes of your packages to the file sizes shown on the Web pages from which you downloaded the packages.
The packages you can install are:
Other packages are provided as zip files:
The Runtime Environment is installed by default in the directory C:\Program Files\IBM\Java50\jre.
If you downloaded the SDK installable package, you can choose whether to install:
You can install the components individually or in combination.
In the installation wizard, you are presented with the following options:
When you install the Runtime Environment (either as part of the SDK installable package or from the Runtime Environment installable package), you are asked whether you want to install the Runtime Environment as the system Java Virtual Machine (JVM). If you do install it as the system JVM, the installation program copies the java.exe and javaw.exe files into the Windows system directory. If a version of java.exe or javaw.exe currently exists in the Windows system directory, you are prompted to overwrite the existing version with the current version. Installing these files into the Windows system directory makes this Runtime Environment the default JVM for the system. In addition, the "Current Version" registry key is set to match this installation.
To create an unattended installation, you must first complete an attended installation and create a response file (setup.iss) that records the choices you made during installation. The response file you create must be correct for the computers on which you plan to use it. If necessary, create several response files to use for installing the packages on computers that have different configurations.
To create a response file while running the installation, at a command prompt type:
ibm-java2-sdk-50-win-i386 /r
or
ibm-java2-jre-50-win-i386 /r
Depending on your Windows product, a response file (setup.iss) is created in either the C:\Windows or C:\Winnt directory, where C: is the boot drive.
The following message might occur during an interactive installation:
Another Java Runtime Environment is currently installed as the System JVM. Select Yes to overwrite this version or No to exit this installation.
If this message is displayed, select No and exit from the installation. Go to the Windows system directory and delete the following two files:
After you have deleted the files, restart the interactive installation using the command shown at the beginning of this section.
On the system on which you will run the unattended installation, copy the setup.iss response file to the C:\Windows directory. After you have copied the file, at a command prompt type:
ibm-java2-sdk-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log ibm-java2-jre-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
If the installation is successful, the log file contains the string ResultCode=0.
The IBM Accessibility Bridge is installed but disabled by default. To enable the IBM Accessibility Bridge, delete the number sign from the beginning of the following line in the Accessibility.properties file in the jre/lib directory:
#assistive_technologies=JawBridge
This Web site tells you more about the Accessibility Utilities:
http://java.sun.com/products/jfc/accessibility.html
You can disable Java Accessibility support to improve the JVM loading performance of Java applications that do not provide Java assistive technology support, especially over network links.
To disable Java Accessibility support, set the JAVA_ASSISTIVE environment variable to OFF. An assistive technology, such as JawBridge, is not available if this environment variable is set to OFF, even if the technology is enabled in the Accessibility.properties file.
In Windows, a process has two codepages: the ANSI (or Windows) codepage and the OEM (or DOS) codepage.
The command window normally uses the OEM codepage. Java console output uses the codepage of the command window from which Java is started. However, the javaw command always uses the ANSI codepage. You specify the codepage to use for console output with the -Dconsole.encoding option on the java command. For example, -Dconsole.encoding=Cp1252 causes all console output to be in the Windows ANSI Latin1 codepage (1252).
Note that, if you alter the PATH environment variable as described below, you will override any existing Java executables in your path.
After setting the path, you can run a tool by typing its name at a shell prompt with a filename as an argument.
You can specify the path to a tool by typing the path before the name of the tool each time. For example, if the SDK is installed in C:\Program Files\IBM\Java50\bin, you can compile a file named myfile.java by typing the following at a command prompt:
"C:\Program Files\IBM\Java50\bin\javac" myfile.java
To avoid typing the full path each time:
If you installed the SDK or Runtime Environment in a different directory, replace C:\Program Files\IBM\Java50\ with the directory in which you installed the SDK or Runtime Environment
javac myfile.java
The PATH environment variable enables Windows to find executable files, such as javac, java, and javadoc, from any current directory. To display the current value of your PATH, type the following at a command prompt:
echo %PATH%
The CLASSPATH tells the SDK tools, such as java, javac, and javadoc, where to find the Java class libraries.
You need to set the CLASSPATH explicitly only if one of the following applies:
To display the current value of your CLASSPATH, type the following at a command prompt:
echo %CLASSPATH%
If you develop and run applications that use different runtime environments, including other versions that you have installed separately, you must set the CLASSPATH (and PATH) explicitly for each application. If you run multiple applications simultaneously and use different runtime environments, each application must run in its own command window.
If you run only one version of Java at a time, you can use a batch script to switch between the different runtime environments.
To uninstall the SDK, whether you installed using attended or unattended installation:
This procedure removes all of the packages that are installed with the Installer. It does not remove the Java Communications API package (see Java Communications API) or any additional files that have been extracted from the zip packages.
When you maintain multiple installations between the IBM 32-bit SDK for Windows, v5.0, and versions at V1.3.1 or earlier, if you uninstall the earlier version while a version V5.0 is still installed on the system, the V1.3.1 uninstaller removes the following registry keys, and all the subkeys, that are required by the V5.0 version, thereby corrupting the V5.0 installation:
Therefore, reinstall V5.0 after uninstalling the V1.3.1 version. This uninstaller limitation has been fixed for V1.4.0 and any subsequent release.
The java tool launches a Java application by starting a Java Runtime Environment and loading a specified class.
The JVM searches for the initial class (and other classes that are used) in three sets of locations: the bootstrap classpath, the installed extensions, and the user classpath. The arguments that you specify after the class name or JAR file name are passed to the main function.
The javaw command is identical to java, except that javaw has no associated console window. Use javaw when you do not want a command prompt window to appear. The javaw launcher displays a dialog box with error information if a launch fails.
The java and javaw command have the following syntax:
java [ options ] class [ arguments ... ] java [ options ] -jar file.jar [ arguments ... ] javaw [ options ] class [ arguments ... ] javaw [ options ] -jar file.jar [ arguments ... ]
Items that are within brackets are optional.
If the -jar option is specified, the named JAR file must contain class and resource files for the application, with the startup class indicated by the Main-Class manifest header.
The launcher has a set of standard options that are supported on the current runtime environment and will be supported in future releases. In addition, there is a set of nonstandard options. The default options have been chosen for best general use. Plan carefully before making changes.
You can specify Java options and system properties in these ways. In order of precedence, they are:
set IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"
Rightmost options on the command line have precedence over leftmost options; for example, if you specify the options -Xint -Xjit myClass, -Xjit takes precedence.
The -X options listed below are nonstandard and subject to change without notice.
For options that take <size> parameter, you should suffix the number with "k" or "K" to indicate kilobytes, "m" or "M" to indicate megabytes, or "g" or "G" to indicate gigabytes.
To obtain the IBM build and version number, at a command prompt type:
java -version
The java command and other java launcher commands (such as javaw) allow a class name to be specified as any character that is in the character set of the current locale.
You can also specify any Unicode character in the class name and arguments by using Java escape sequences. To do this, you must specify -Xargencoding. To specify a Unicode character, use escape sequences in the form \u####, where # is a hexadecimal digit (0 through 9, A through F).
Alternatively, to specify that the class name and command arguments are in UTF8 encoding, use -Xargencoding:utf8, or in ISO8859_1 encoding use -Xargencoding:latin.
For instance, to specify a class called "HelloWorld" using Unicode encoding for both capital letters, use this command:
java -Xargencoding '\u0048ello\u0057orld'
The java and javaw commands give translated output messages. These messages differ based on the locale in which Java is running. The detailed error descriptions and other debug information that is returned by java are in English.
To set a java class or jar file to execute automatically from the file, use the Tools->Folder Options->File Type option of Windows Explorer. Alternatively, at a command prompt type:
assoc .class=javaclass ftype javaclass=C:\Program Files\IBM\Java50\jre\bin\java.exe %l %*
Sun provides the Java Access Bridge to give native Windows assistive technologies, such as screen readers, access to the Java Accessibility support in a Java application. These native Windows assistive technologies must support calls to the Java Access Bridge.
The Java Access Bridge available from Sun includes an installer, which places five files in the correct directories: access-bridge.jar, jaccess.jar, accessibility.properties, JavaAccessBridge.dll and WindowsAccessBridge.dll. IBM ship a copy of jaccess.jar in the appropriate directory for use with JawBridge.
If you have already enabled the IBM Accessibility Bridge (JawBridge), which allows the Windows 2000 Magnifier to function with Swing applications, and you want to enable JawBridge at the same time as the Java Access Bridge, edit the line in the accessibility.properties file to read:
assistive_technologies=com.sun.java.accessibility.AccessBridge, JawBridge
Comment out the line by inserting a leading # to deactivate both bridges. This Web site tells you how to how to download the Java Access Bridge:
http://java.sun.com/products/jfc/accessibility.html
The IBM Just-In-Time (JIT) compiler dynamically generates machine code for frequently used bytecode sequences in Java applications and applets during their execution. |The JIT V5.0 compiler delivers new optimizations |as a result of compiler research, improves optimizations implemented in previous |versions of the JIT, and provides better hardware exploitation.
The IBM SDK and Runtime Environment include the JIT, which is enabled by default in user applications as well as SDK tools. Normally, there is no need to invoke the JIT explicitly; the compilation of Java bytecode to machine code occurs transparently. However, if you encounter a problem with the Runtime Environment while executing a Java application or an applet, you can disable the JIT to help isolate the problem. Disabling the JIT should be a temporary measure only; the JIT is required for adequate performance.
There are three ways to disable the JIT:
At the command prompt where the application is run, type:
set JAVA_COMPILER=NONE
You can also permanently set JAVA_COMPILER by using the graphical user interface. Open Control Panel, select System, and on the Advanced tab, select Environment Variables.
java -Djava.compiler=NONE MyApp
java -Xint MyApp
Both command-line options override the JAVA_COMPILER environment variable.
To enable the JIT explicitly, set the JAVA_COMPILER environment variable to "jitc", or use the -D option to set the java.compiler property to "jitc". Alternatively, use the -Xjit option (and omit the -Xint option) on the JVM command line to turn on the JIT.
If the JAVA_COMPILER environment variable or the java.compiler property is set to "" (the empty string), the JIT remains disabled. To unset the environment variable properly, type set JAVA_COMPILER= at the command prompt.
To determine whether 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)
For more information about the JIT, see the Diagnostics Guide.
The Garbage Collector manages the memory used by Java and by applications running within the VM.
When the Garbage Collector receives a request for storage, unused memory in the heap is set aside - "allocation". The Garbage Collector also checks for areas of memory are no longer referenced, and releases them for reuse - "collection".
The collection phase can be triggered by a memory allocation fault, which occurs when no space is left for a storage request, or by an explicit System.gc() call.
Garbage collection can significantly affect application performance, so the IBM virtual machine provides various methods of optimising the way garbage collection is carried out, thus reducing the effect on your application.
For more detailed information on garbage collection, see the Diagnostics Guide.
The -Xgcpolicy option controls garbage collector behavior, making tradeoffs between throughput of the application and overall system and the pause times that are caused by garbage collection.
The format of the option and its values is:
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. Because 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, -Xgcpolicy: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.
The JVM uses two techniques to reduce pause times:
The -Xgcpolicy:optavgpause command-line option requests the use of concurrent garbage collection to reduce significantly the time that is spent in garbage collection pauses. Concurrent GC reduces the pause time by performing some garbage collection activities concurrently with normal program execution to minimize the disruption caused by the collection of the heap. The -Xgcpolicy:optavgpause option also limits the effect of increasing the heap size on the length of the garbage collection pause. The -Xgcpolicy:optavgpause option is most useful for configurations that have large heaps. With the reduced pause time, you might experience some reduction of throughput to your applications.
During concurrent garbage collection a significant amount of time is wasted identifying relatively long-lasting objects that cannot then be collected. If the GC concentrates on just those objects that are most likely to be recyclable, you can further reduce pause times for some applications. Generational GC achieves this by dividing the heap into two "generations", the "nursery" and the "tenure" areas. Objects are placed in one of these areas depending on their age. The nursery is the smaller of the two and contains younger objects; the tenure is larger and contains older objects. Objects are first allocated to the nursery; if they survive long enough they are promoted to the tenure area eventually.
Generational GC depends on most objects not lasting long. Generational GC reduces pause times by concentrating the effort to reclaim storage on the nursery because it has the most recyclable space. Rather than occasional but lengthy pause times to collect the entire heap, the nursery is collected more frequently and, if the nursery is small enough, pause times are comparatively short. However, generational GC has the drawback that, over time, the tenure area might become full if too many objects last too long. To minimize the pause time when this situation occurs, use a combination of concurrent GC and generational GC. The -Xgcpolicy:gencon option requests the combined use of concurrent and generational GC to help minimize the time that is spent in any garbage collection pause.
If the Java heap becomes nearly full, and very little garbage is to be reclaimed, requests for new objects might not be satisfied quickly because no space is 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 OutOfMemoryError, which results in JVM termination if the exception is not caught and handled. At this point the JVM produces a "javadump" diagnostic file. In these conditions, you are recommended either to increase the heap size by using the -Xmx option, or to reduce the number of application objects in use. For more information, see the Diagnostics Guide.
When a signal is raised that is of interest to the JVM, a signal handler is called. This signal handler determines whether it has been called for a Java or non-Java thread.
If the signal is for a Java thread, the JVM takes control of the signal handling. If an application handler for this signal is installed and you did not specify the -Xnosigchain command-line option, the application handler for this signal is called after the JVM has finished processing.
If the signal is for a non-Java thread, and the application that installed the JVM had previously installed its own handler for the signal, control is given to that handler. Otherwise, if the signal is requested by the JVM or Java application, the signal is ignored or the default action is taken.
Where a signal is generated externally (for example, when you enter CTRL-BREAK), a new thread is created to execute the signal handler. In this case, the JVM signal handler performs its processing and if an application handler for this signal is installed and you did not specify the -Xnosigchain command-line option, the application handler for this signal is called.
For exception and error signals, the JVM either:
For information about writing a launcher that specifies the above hooks, see: http://www-106.ibm.com/developerworks/java/library/i-signalhandling/. This item was written for Java V1.3.1, but still applies to later versions.
For interrupt signals, the JVM also enters a controlled shutdown sequence, but this time it is treated as a normal termination that:
The shutdown is identical to the shutdown initiated by a call to the Java method System.exit().
Other signals that are used by the JVM are for internal control purposes and do not cause it to terminate. The only control signal of interest is SIGBREAK, which causes a Javadump to be generated.
Table 1 below shows the signals that are used by the JVM. The signals are grouped in the table by type or use, as follows:
| Signal Name | Signal type | Description | Disabled by -Xrs |
|---|---|---|---|
| SIGINT (2) | Interrupt | Interactive attention (CTRL-C). JVM exits normally. | Yes |
| SIGTERM (15) | Interrupt | Termination request. JVM will exit normally. | Yes |
| SIGBREAK | Control | A break signal from a terminal. JVM uses this for taking Javadumps. | Yes |
|The IBM JVM uses structured |exception handling and the SetConsoleCtrlHandler() API. These are disabled with -Xrs. -Xnosigchain is ignored on Windows.
Use the -Xrs (reduce signal usage) option to prevent the JVM from handling most signals. For more information, see Sun's Java application launcher page.
The signals 2 (SIGINT) and 15 (SIGTERM) on JVM threads causes the JVM to shut down; therefore, an application signal handler should not attempt to recover from this signal unless it no longer requires the JVM.
The Runtime Environment contains signal-chaining. Signal-chaining enables the JVM to interoperate more efficiently with native code that installs its own signal handlers.
Signal-chaining enables an application to link and load the shared library jsig.dll before msvcrt.dll. The jsig.dll library ensures that calls to signal() are intercepted so that their handlers do not replace the JVM's signal handlers. Instead, these calls save the new signal handlers, or "chain" them behind the handlers that are installed by the JVM. Later, when any of these signals are raised and found not to be targeted at the JVM, the preinstalled handlers are invoked.
To use jsig.dll, link it with the application that creates or embeds a JVM.
The libjsig.dll library also hides JVM signal handlers from the application. Therefore, calls such as signal(), sigset(), and sigaction() that are made after the JVM has started no longer return a reference to the JVM's signal handler, but instead return any handler that was installed before JVM startup.
The IBM SDK contains the XSLT4J processor and the XML4J parser that conform to the JAXP 1.3 specification. These tools allow you to parse and transform XML documents independently from any given XML processing implementation. By using "Factory Finders" to locate the SAXParserFactory, DocumentBuilderFactory and TransformerFactory implementations, your application can swap between different implementations without having to change any code.
|The XML technology included with the IBM SDK is similar to |Apache Xerces Java and Apache Xalan Java. See http://xml.apache.org/xerces2-j/ and http://xml.apache.org/xalan-j/ for more information.
The XSLT4J processor allows you to choose between the original XSLT Interpretive processor or the new XSLT Compiling processor. The Interpretive processor is designed for tooling and debugging environments and supports the XSLT extension functions that are not supported by the XSLT Compiling processor. The XSLT Compiling processor is designed for high performance runtime environments; it generates a transformation engine, or translet, from an XSL style sheet. This approach separates the interpretation of style sheet instructions from their runtime application to XML data.
The XSLT Interpretive processor is the default processor. To select the XSLT Compiling processor, you can:
To implement properties in the jaxp.properties file, copy jaxp.properties.sample to jaxp.properties in C:\Program Files\IBM\Java50\jre\lib. This file also contains full details about the procedure used to determine which implementations to use for the TransformerFactory, SAXParserFactory, and the DocumentBuilderFactory.
To improve the performance when you transform a StreamSource object with the XSLT Compiling processor, specify the com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager class as the provider of the service org.apache.xalan.xsltc.dom.XSLTCDTMManager. To determine the service provider, try each step until you find org.apache.xalan.xsltc.dom.XSLTCDTMManager:
The XSLT Compiling processor detects the service provider for the org.apache.xalan.xsltc.dom.XSLTCDTMManager service when a javax.xml.transform.TransformerFactory object is created. Any javax.xml.transform.Transformer or javax.xml.transform.sax.TransformerHandler objects that are created by using that TransformerFactory object will use the same service provider. You can change service providers by modifying one of the settings described above and then creating a new TransformerFactory object.
If you are using an older version of Tomcat, this limitation might apply.
If you are using an older version of Xerces (prior to 2.0) or Xalan (prior to 2.3) in the endorsed override, you might get a null pointer exception when you launch your application. This exception occurs because these older versions do not handle the jaxp.properties file correctly.
To avoid this situation, use one of the following workarounds:
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory= org.apache.xerces.jaxp.SAXParserFactoryImplor
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory= org.apache.xerces.jaxp.DocumentBuilderFactoryImplor
set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory= org.apache.xalan.processor.TransformerFactoryImpl
The following sections give information about using the SDK for Windows to develop Java applications. See SDK tools for details of the tools available.
To debug Java programs, you can use the Java Debugger (JDB) application or other debuggers that communicate by using the Java Platform Debugger Architecture (JPDA) that is provided by the SDK for Windows.
More information on problem diagnosis using Java can be found in the IBM Java Diagnostics Guide.
The Java Debugger (JDB) is included in the SDK for Windows. The debugger is invoked by the jdb command; it "attaches" to the JVM using JPDA. To debug a Java application:
java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<port> MyApp <args>
jdb -attach <port number>The debugger will attach to the JVM, and you can now issue a range of commands to examine and control the Java application; for example, type run to allow the Java application to execute.
To find out more about JDB options, type:
jdb -help
To find out more about JDB commands:
You can also use JDB to debug Java applications running on remote machines. JPDA uses a TCP/IP socket to connect to the remote JVM.
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> MyApp <args>
|jdb -connect com.sun.jdi.SocketAttach:hostname=<machine name or IP address>, port=<number> |
When you launch a debug session using the dt_socket transport, be sure that the specified ports are free to use.
|The Java Virtual Machine Debugging Interface (JVMDI) is not supported in this release. It has been replaced by |the Java Virtual Machine Tool Interface (JVMTI).
For more information on JDB and JPDA and their usage, see these Web sites:
Some Java applications must be able to determine whether they are running on a 32-bit JVM or on a 64-bit JVM. For example, if your application has a native code library, the library must be compiled separately in 32- and 64-bit forms for platforms that support both 32- and 64-bit modes of operation. In this case, your application must load the correct library at runtime, because it is not possible to mix 32- and 64-bit code.
The system property com.ibm.vm.bitmode allows applications to determine the mode in which your JVM is running. It returns the following values:
You can inspect the com.ibm.vm.bitmode from within your application code using the call:
System.getProperty("com.ibm.vm.bitmode");
Valid JNI version numbers that native programs can specify on the JNI_CreateJavaVM() API call are:
This version number determines only the level of the JNI native interface to use. The actual level of the JVM that is created is specified by the J2SE libraries (that is, v5.0). The JNI interface API does not affect the language specification that is implemented by the JVM, the class library APIs, or any other area of JVM behavior. For more information, see http://java.sun.com/j2se/1.5.0/docs/guide/jni.
If your application needs two JNI libraries, one built for 32- and the other for 64-bit, use the com.ibm.vm.bitmode system property to determine if you are running with a 32- or 64-bit JVM and choose the appropriate library.
With the Applet Viewer, you can run one or more applets that are called by reference in a Web page (HTML file) by 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 a whole Web page that contains many HTML tags. It parses only the APPLET tags and no other HTML on the Web page.
To run an applet with the Applet Viewer, type the following at a command prompt:
appletviewer name
where name is one of the following:
For example, to invoke the Applet Viewer on an HTML file that calls an applet, type at a command prompt:
appletviewer <demo>\GraphLayout\example1.html
where <demo> is replaced by the full path into which you unzipped the demo package.
For example, http://java.sun.com/applets/NervousText/example1.html is the URL of a Web page that calls an applet. To invoke the Applet Viewer on this Web page, type at a shell prompt:
appletviewer http://java.sun.com/applets/NervousText/example1.html
The Applet Viewer does not recognize the charset option of the <META> tag. If the file that the Applet Viewer loads is not encoded as the system default, an I/O exception might occur. To avoid the exception, use the -encoding option when you run appletviewer. For example:
appletviewer -encoding JISAutoDetect sample.html| | |
A unique set of CLSIDs have been added to the IBM JVM from Service Refresh |1. Here are the new CLSIDs:
|1ACECAFE-0015-0000-0000-ABCDEFFEDCBA
|1ACECAFE-0015-0000-0000-ABCDEFFEDCBBYou can refer to the above CLSIDs |in the OBJECT Tag for your applets.
|In addition, the following existing CLSIDs are also supported for compatibility |purposes:
|CAFEEFAC-0015-0000-0000-ABCDEFFEDCBA
|CAFEEFAC-0015-0000-0000-ABCDEFFEDCBB
You can debug applets by 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 HTML file that calls the applet. For example:
cd <demo>\TicTacToe appletviewer -debug example1.html
Where <demo> is replaced by the full path into which you unzipped the demo package.
You can find documentation about how to debug applets using the Applet Viewer at the Sun Web site: http://java.sun.com.
| | |You can enable large page support, on systems that support it, by starting |Java with the -Xlp option.
|Large page usage is primarily intended to provide performance improvements |to applications that allocate a lot of memory and frequently access that memory. |The large page performance improvements are mainly caused by the reduced number |of misses in the Translation Lookaside Buffer (TLB). The TLB maps a larger |virtual memory range and thus causes this improvement.
|For the JVM to use large pages, your system must have an adequate number |of contiguous large pages available. If large pages cannot be allocated, even |when enough pages are available, possibly the large pages are not contiguous.
|Large page allocations will only succeed if the local administrative |policy for the JVM user is configured to allow "Lock pages in memory".
The Java 2 Platform, Standard Edition (J2SE) supports, at a minimum, the specifications that are defined in the Official Specifications for CORBA support in J2SE. In some cases, the IBM J2SE ORB supports more recent versions of the specifications.
This SDK 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://www.omg.org/cgi-bin/doc?formal/99-10-07
Bidirectional GIOP is not supported.
This SDK supports Portable Interceptors, as defined by the OMG in the document ptc/01-03-04, which you can obtain from:
http://www.omg.org/cgi-bin/doc?ptc/01-03-04
Portable Interceptors are hooks into the ORB through which ORB services can intercept the normal flow of execution of the ORB.
This SDK supports the Interoperable Naming Service, as defined by the OMG in the document ptc/00-08-07, which you can obtain from:
http://www.omg.org/cgi-bin/doc?ptc/00-08-07
The default port that is 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 that is 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.
The initial context that is returned from the Transient Name Server is now an org.omg.CosNaming.NamingContextExt. Existing programs that narrow the reference to a context org.omg.CosNaming.NamingContext still work, and do not need to be recompiled.
The ORB supports the -ORBInitRef and -ORBDefaultInitRef parameters that are defined by the Interoperable Naming Service specification, and the ORB::string_to_object operation now supports the ObjectURL string formats (corbaloc: and corbaname:) that are 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 5.0. 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, which is returned from ORB.init(), and serviceRef is a CORBA Object, which is connected to the ORB. This mechanism is an interim one, and is not compatible with future versions or portable to non-IBM ORBs.
A 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.
For example, to trace events and formatted GIOP messages, type:
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true myapp
Do not turn on tracing for normal operation, because it might cause performance degradation. Even if you have switched off tracing, FFDC (First Failure Data Capture) is still working, so that only serious errors are reported. If a debug output file is generated, examine it to check on the problem. For example, the server might have stopped without performing an ORB.shutdown().
The content and format of the trace output might vary from version to version.
The following properties help you to tune the ORB:
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.
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 to avoid connections ending unnecessarily.
For example, to make the ORB use port 1050, type:
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.
When running with a Java 2 SecurityManager, invocation of some methods in the CORBA API classes might cause permission checks to be made, which might 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.
The ORB implementation classes in this release are:
These are the default values, and you are advised not to set these properties or refer to the implementation classes directly. For portability, make references only to the CORBA API classes, and not to the implementation. These values might be changed in future releases.
Java Remote Method Invocation (RMI) provides a simple mechanism for distributed Java programming. RMI over IIOP (RMI-IIOP) uses the Common Object Request Broker Architecture (CORBA) standard Internet Inter-ORB Protocol (IIOP protocol) to extend the base Java RMI to perform communication. This allows direct interaction with any other CORBA Object Request Brokers (ORBs), whether they were implemented in Java or another programming language.
The following documentation is available:
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.
For more information, see the Sun Java site: http://java.sun.com.
|From Java 5.0, the IBM BigDecimal class has been adopted |by Sun as java.math.BigDecimal. The com.ibm.math.BigDecimal class is reserved |for possible future use by IBM, and, currently, you are recommended to regard |it as deprecated. You are recommended to migrate existing Java code to use |java.math.BigDecimal.|
||The new java.math.BigDecimal uses the same methods as both |the previous java.math.BigDecimal and com.ibm.math.BigDecimal. Existing code |using java.math.BigDecimal continues to work correctly. The two classes do |not serialize.|
|To migrate existing Java code to use the java.math.BigDecimal class, change |the import statement at the top of your java file from: import com.ibm.math.*; to import java.math.*;.
The IBM SDK and Runtime Environment set the Euro as the default currency for those countries in the European Monetary Union (EMU) for dates on or after 1 January, 2002.
To use the old national currency, specify -Duser.variant=PREEURO on the Java command line.
If you are running the UK, Danish, or Swedish locales and want to use the Euro, specify -Duser.variant=EURO on the Java command line.
|In V5.0 SR3, the default for the Slovenian locale is set |to the Euro. If you install SR3 before 1 January 2007, you might want to change |the currency to the Tolar.
| | ||From Service Refresh 5, the following new locale is added: | Serbia (SE), with these three new locale variations:
|The existing locale variations for the former Serbia and Montenegro are |maintained as before. The 3-letter country code SRB, corresponding to the |2-letter country code RC, is also added. |
The Java Communications application programming interface (API) package (JavaComm) is an optional package provided for use with the Runtime Environment for Windows. You install JavaComm independently of the SDK or Runtime Environment.
The JavaComm API gives Java applications a platform-independent way of performing serial and parallel port communications for technologies such as voice mail, fax, and smartcards. After writing serial or parallel port communications for your application, you can then include those files with your application.
The Java Communications API supports Electronic Industries Association (EIA)-232 (RS232) serial ports and Institute of Electrical and Electronics Engineers (IEEE) 1284 parallel ports and is supported on systems with the IBM Version 5.0 Runtime Environment.
Using Java Communications API, you can:
You should make sure that a copy of the SDK or Runtime Environment is installed before you install the Java Communications API.
To install the Java Communications API from a zip file:
If you accepted the default directory when you installed the Runtime Environment, the comm.jar file is in C:\Program Files\IBM\Java50\jre\lib\ext.
If you unzip the file in another directory, the files are placed in the same directory structure, but C:\Program Files\IBM\Java50\ is replaced by the directory where you unzipped the file.
After you install Java Communications API, you must:
When printing with the Java Communications API, you might have to press "Form feed" or "Continue" or similar on the printer.
To uninstall Java Communications API, delete the following files from the directory where you installed the Runtime Environment:
By default, the Runtime Environment is installed in the C:\Program Files\IBM\Java50\ directory.
You can find API documentation and samples for Java Communications API at the Sun Web site: http://java.sun.com.
The Java Plug-in is a Web browser Plug-in. If you use the Java Plug-in, you can bypass your Web browser's default JVM and instead use a Runtime Environment of your choice to run applets or beans in the browser.
You must allow applets to finish loading to prevent your browser from 'hanging'. For example, if you use the Back button and then the Forward button while an applet is loading, the HTML pages might be unable to load.
The Java Plug-in is documented by Sun at: http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.
| |Operating System | |Internet Explorer | |Netscape | |Mozilla |
|---|---|---|---|
| |Windows 2000 | |5.5 SP2, 6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x, 1.5, |2.0 |
| |Windows XP | |6.0, 7.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x, 1.5, |2.0 |
| |Windows Server 2003 | |6.0, 7.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x, 1.5, |2.0 |
Note that Internet Explorer 5.01, the default browser on Windows 2000, is not supported.
| | |Static versioning allows applets to request a specific JVM version to be |run under. Because this capability also allows applets to exploit old security |vulnerabilities on systems which have been upgraded to a new JVM, Secure Static |Versioning (SSV) is now used on Internet Explorer.
|By default, all applets are run under the latest installed JVM. To disable |SSV, set the following registry key to 0:
|HKEY_LOCAL_MACHINE/Software/IBM/Java Deployment/Policy/EnableSecureStaticVersioning
|If the registry key does not exist, SSV is enabled.
||SSV will not function if third-party browser extensions |are disabled in Internet Explorer. To enable third-party browser extensions:|
||If third-party browser extensions are disabled after SSV |has been used, SSV will continue to function.|
|To provide protection for the Mozilla and Firefox browsers, the plug-in |for Internet Explorer will automatically remove all java plug-ins from |the Mozilla and Firefox plug-in directories. This happens each time |an applet is run under Internet Explorer.
|To reinstall a Java plug-in on Mozilla or Firefox, use the Java |Control Panel.
Because of limitations in particular browsers, you might not be able to implement all the functions of the org.w3c.dom.html package. One of the following errors will be thrown:
The Java Plug-in supports double-byte characters (for example Chinese Traditional BIG-5, Korean, Japanese) as parameters for the tags <APPLET>, <OBJECT>, and <EMBED>. You must select the correct character encoding for your HTML document so that the Java Plug-in can parse the parameter. Specify character encoding for your HTML document by using the <META> tag in the <HEAD> section like this:
<meta http-equiv="Content-Type" content="text/html; charset=big5">
This example tells the browser to use the Chinese BIG-5 character encoding to parse the HTML file using. All the parameters are passed to the Java Plug-in correctly. However, some of the older versions of browsers might not understand this tag correctly. In this case, you can force the browser to ignore this tag, but you might have to change the encoding manually.
You can specify which encoding you want to use to parse the HTML file:
Java Web Start is used to deploy Java applications. Web Start allows users to launch and manage applications directly from the Web. Applications are cached to minimize installation times. Applications are automatically upgraded when new versions become available.
|Web Start supports these java-vm-args documented at http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources:
IBM Web Start also supports -Xgcpolicy to set the garbage collection policy.
For information on the browsers that support Web Start, see Supported browsers.
For more information about Web Start, see: http://java.sun.com/products/javawebstart and http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. For more information about deploying applications, see: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.
You can invoke Web Start in three ways:
All Java Web Start applications are stored in the Java Application Cache. An application is only downloaded if the latest version is not in the cache.
| | |Static versioning allows Web Start applications to request a specific JVM |version to be run under. Because this capability also allows applications |to exploit old security vulnerabilities on systems which have been upgraded |to a new JVM, Secure Static Versioning (SSV) is now used by default.
|With SSV, the user will be warned before running any unsigned Web Start |application that requests a specific JVM be used. Signed applications and |applications which request the latest version of the JVM run as normal.
|You can disable SSV by setting the deployment.javaws.ssv.enabled property |in the deployment.properties file to false.
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 probably consists of the following parts:
To run your application, a user needs the Runtime Environment for Windows. The SDK for Windows software contains a Runtime Environment. However, you cannot assume that your users have the SDK for Windows software installed.
Your SDK for Windows software license does not allow you to redistribute any of the SDK's files with your application. You should ensure that a licensed version of the SDK for Windows is installed on the target machine.
| | |The IBM Virtual Machine (VM) allows you to share bootstrap and application |classes between VMs by storing them in a cache in shared memory. Class sharing |reduces the overall virtual memory consumption when more than one VM shares |a cache. Class sharing also reduces the startup time for a VM after the cache |has been created. The shared class cache is independent of any active VM and |persists beyond the lifetime of the VM that created the cache.
| |The IBM SDK allows you to share as many classes as possible, while appearing |transparent to the user.
| |The shared class cache contains read-only static class data and metadata |that describes the classes. Any VM may read or update the cache. The VMs that |are sharing must be at the same release. You must take care if runtime bytecode |modification is being used. (See Runtime bytecode modification.)
| |Because the shared class cache persists beyond the lifetime of any VM, |the cache is updated dynamically to reflect any modifications that might have |been made to JARs or classes on the file system. The dynamic updating makes |the cache transparent to the application using it.
| |Enable class sharing by using the -Xshareclasses option |when starting a VM, to make the VM connect to an existing cache or to create |one if it does not exist. All bootstrap and application classes loaded by |the VM are shared by default. Custom class loaders share automatically if |they extend the application class loader; otherwise, they must use the Java |Helper API provided with the VM to access the cache. (See Adapting custom classloaders to share classes.)
| |Access to the shared class cache is limited by operating system permissions |and Java security permissions. Only a class loader that has registered |to share classes can add classes to the shared class cache. If a Java SecurityManager |is installed, class loaders, excluding the default bootstrap, application, |and extension class loaders, must be granted permission to share classes by |adding SharedClassPermission lines to the java.policy file. (See Using SharedClassPermission.) |The RuntimePermission "createClassLoader" restricts the creation of new class |loaders and therefore also restricts access to the cache.
| |Multiple caches can exist on a system and are specified by name as a suboption |to the -Xshareclasses command. A VM can connect to only |one cache at any one time. You specify cache size on startup using -Xscmx<n>[k|m|g], but this size is then fixed for the lifetime of |the cache. Caches exist until they are explicitly destroyed using a suboption |to the -Xshareclasses command or until the system is |rebooted.
| |All cache utilities are suboptions to the -Xshareclasses command. Use -Xshareclasses:help to see a list |of available suboptions.
| |Use the -Xshareclasses and -Xscmx command-line options to enable and configure class sharing.
|You can |use the following suboptions with the -Xshareclasses option:
|To enable class sharing, add -Xshareclasses[:name=<name>] to your application command line. The VM will either connect to an existing |cache of the given name, or create a new cache of that name. If a new cache |has been created, it will be populated with all bootstrap and application |classes being loaded until the cache becomes full. If two or more VMs are |started concurrently, they will all populate the cache concurrently.
|To check that the cache has been created, run java -Xshareclasses:listAllCaches. To see how many classes and how much class data is being shared, run java -Xshareclasses:[name=<name>],printStats. (These utilities can |be run after the application VM has terminated or in another command window.)
|For more feedback on cache usage while the VM is running, use the verbose suboption. For example, java -Xshareclasses:[name=<name>],verbose.
|To see classes being loaded from the cache or stored in the cache, add |-Xshareclasses:[name=<name>],verboseIO| to your application |command line.
|To delete the cache created, run java -Xshareclasses:[name=<name>],destroy. You should have to delete caches only if they contain many stale |classes or if the cache is full and you want to create a bigger cache.
|You are recommend to tune the cache size for your specific application, |because the default is unlikely to be the optimum size. The best way to determine |the optimum cache size is to specify a large cache (using -Xscmx), run the application, and then use printStats to determine how |much class data has been stored. Add a small amount to the value shown in |printStats for contingency. Note that because classes can be loaded at any |time during the lifetime of the VM, it is best to do this analysis after the |application has terminated. However, a full cache does not have a negative |impact on the performance or capability of any VMs connected to it, so it |is quite legitimate to decide on a cache size that is smaller than required.
|If a cache becomes full, a message is output to the command line of any |VMs using verbose suboption. All VMs sharing the full cache will then load |any further classes into their own process memory. Classes in a full cache |can still be shared, but a full cache is read-only and cannot be updated with |new classes.
| |Class sharing is particularly useful on systems that use more than one |VM running similar code; the system benefits from reduced virtual memory consumption. | It is also useful on systems that frequently start up and shut down VMs, |which benefit from the improvement in startup time.
|The overhead to create and populate a new cache is minimal. The VM startup |cost in time for a single VM is typically between 0 and 5% slower compared |with a system not using class sharing, depending on how many classes are loaded. |VM startup time improvement with a populated cache is typically between 10% |and 40% faster compared with a system not using class sharing, depending on |the operating system and the number of classes loaded. Multiple VMs running |concurrently will show greater overall startup time benefits.
||Duplicate classes are consolidated within the shared class |cache. For example, class A loaded from myClasses.jar and class A loaded from |myOtherClasses.jar (with identical content) is stored only once in the cache. |The printAllStats utility shows multiple entries for duplicated classes, with |each entry pointing to the same class.|
|When you run your application with class sharing, you can use the operating |system tools to see the reduction in virtual memory consumption.
| |The maximum theoretical cache size is 2 GB. The cache is |limited by the following factors:
||Any VM using a JVMTI (JVM Tool Interface) agent that can |modify bytecode data should use the modified=<modified_context> suboption |if it wants to share the modified classes with another VM. (See Using command-line options for class sharing.) |The modified context is a user-specified descriptor that describes the type |of modification being performed. The modified context partitions the cache |so that all VMs running under the same context share a partition. This partitioning |allows VMs that are not using modified bytecode to safely share a cache with |those that are using modified bytecode. All VMs using a given modified context |must modify bytecode in a predictable, repeatable manner for each class, so |that the modified classes stored in the cache have the expected modifications |when they are loaded by another VM. Any modification must be predictable because |classes loaded from the shared class cache cannot be modified again by the |agent.|
||If a JVMTI agent is used without a modification context, |classes are still safely shared by the VM, but with a small impact on performance. |Using a modification context with a JVMTI agent avoids the need for extra |checks and therefore has no impact on performance. A custom ClassLoader that |extends java.net.URLClassLoader and modifies bytecode at load time without |using JVMTI automatically stores that modified bytecode in the cache, but |the cache does not treat the bytecode as modified. Any other VM sharing that |cache loads the modified classes. The modified=<modification_context> suboption can be used in the same way as with JVMTI agents to partition |modified bytecode in the cache. If a custom ClassLoader needs to make unpredictable |load-time modifications to classes, that ClassLoader must not attempt to use |class sharing.|
|See the Diagnostics Guide for more detail |on this topic.
| |For operating systems that can run both 32-bit and 64-bit |applications, class sharing is not permitted between 32-bit and 64-bit VMs. |The listAllCaches suboption lists 32-bit or 64-bit caches, |depending on the address mode of the VM being used.
|The shared class cache requires disk space to store identification information |about the caches that exist on the system. This information |is in the user profile directory. If the identification information |directory is deleted, the VM cannot identify the shared classes on the system |and must recreate the cache.
|The permissions for accessing a shared classes cache |are enforced by the operating system. If a cache name is not specified, the |user name is appended to the default name so that multiple users on the same |system create their own caches by default.
| |If a SecurityManager is being used with class sharing and the running application |uses its own classloaders, these classloaders must be granted shared class |permissions before they can share classes. You add shared class permissions |to the java.policy file using the ClassLoader class name (wildcards are permitted) |and either "read", "write", or "read,write" to determine the access granted. |For example:
|permission com.ibm.oti.shared.SharedClassPermission
| "com.abc.customclassloaders.*", "read,write";If a ClassLoader |does not have the correct permissions, it is prevented from sharing classes. | You cannot change or reduce the permissions of the default bootstrap, application, |or extension classloaders.
| |Most Java applications use the VM's own classloaders or have custom classloaders |that extend java/net/URLClassLoader. Applications using these classloaders |can automatically share bootstrap and application classes. Custom classloaders |that do not extend java/net/URLClassLoader will require modifications to make |use of class sharing. All custom class loaders must be granted shared class |permissions if a SecurityManager is being used, see Using SharedClassPermission. |IBM provides several Java interfaces for various types of custom classloaders, |which allow the classloaders to find and store classes in the shared class |cache. These classes are in the com.ibm.oti.shared package. The Javadoc for |this package is provided with the SDK in the file docs/apidoc.zip. See the Diagnostics Guide for more information on |how to use these interfaces.
If you are entitled to services for the Program code pursuant to the IBM Solutions Developer Program, contact the IBM Solutions Developer Program through your normal method of access or on the Web at: http://www-1.ibm.com/partnerworld/.
If you have purchased a service contract (that is, IBM's Personal Systems Support Line or equivalent service by country), the terms and conditions of that service contract determine what services, if any, you are entitled to receive with respect to the Program.
The User Guides that are supplied with this SDK and the Runtime Environment have been tested by using screen readers. You can use a screen reader such as the Home Page Reader or the JAWS screen reader with these User Guides.
To change the font sizes in the User Guides, use the function that is supplied with your browser, usually found under the View menu option.
For users who require keyboard navigation, a description of useful keystrokes for Swing applications is in "Swing Key Bindings" at http://www-128.ibm.com/developerworks/java/jdk/additional/
|In addition to the GUI, the iKeyman tool provides the command-line |tool IKEYCMD, which has the same functions that the |iKeyman GUI has. IKEYCMD allows you to manage keys, |certificates, and certificate requests. You can call IKEYCMD from native shell scripts and from programs that are to be used when |applications need to add custom interfaces to certificate and key management |tasks. IKEYCMD can create key database files for all |the types that iKeyman currently supports. IKEYCMD can |also create certificate requests, import CA signed certificates, and manage |self-signed certificates.
To run an IKEYCMD command, enter:
java [-Dikeycmd.properties=<properties file>] com.ibm.gsk.ikeyman.ikeycmd <object> <action> [options]
where:
For more information, see the iKeyman User Guide at: http://www.ibm.com/developerworks/java/jdk/security/index.html.
If you traverse the drop-down list of a JComboBox component with the cursor keys, the button or editable field of the combo box does not change value until an item is selected. This is the desired behavior for this release and improves accessibility and usability by ensuring that the keyboard traversal behavior is consistent with mouse traversal behavior.
Web Start v5.0 contains several accessibility and usability improvements over the previous release, including better support for screen readers and improved keyboard navigation.
You can use the command line only to launch a Java application that is enabled for Web Start. To change preference options, you must edit a configuration file, Application Data\IBM\Java\Deployment\deployment.properties in the user's home directory. Take a backup before you edit this file. Not all the preferences that can be set in the Java Application Cache Viewer are available in the configuration file.
| | |To enable JConsole to run on Windows with the Windows look and feel, JConsole |needs to be launched with the following command line:
|JConsole -J-Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel|
This will enable the High Contrast color schemes available in windows to |be adopted by JConsole.
You can obtain JCE unrestricted jurisdiction policy files from http://www.ibm.com/developerworks/java/jdk/security/index.html. Documentation about the IBM security packages JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS and hardware cryptography is also available at this Web site.
Note these limitations in the IBM 32-bit SDK for Windows, v5.0:
If you see this exception, you can set the system property java.nio.debug=pipe to see which port numbers are being blocked.
If you have any comments about the usefulness, or otherwise, of this User Guide, we would be pleased to hear from you through one of these channels. Please note that these channels are not set up to answer technical queries, but are for comments about the documentation only. Send your comments:
The fine print. By choosing to send a message to IBM, you acknowledge that all information contained in your message, including feedback data, such as questions, comments, suggestions, or the like, shall be deemed to be non-confidential and IBM shall have no obligation of any kind with respect to such information and shall be free to reproduce, use, disclose, and distribute the information to others without limitation. Further, IBM shall be free to use any ideas, concepts, know-how or techniques contained in such information for any purpose whatsoever, including, but not limited to, developing, manufacturing and marketing products incorporating such information.
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 user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:
The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the information. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this information at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:
Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
IBM is a trademark of International Business Machines Corporation in the United States, 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.
Microsoft, Windows and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Other company, product, or 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.
This product includes software developed by the Apache Software Foundation http://www.apache.org/.