Release Notes Compaq Software Development Kit (SDK) v 1.1.8-14 [COMPAQ] for the Tru64™ UNIX® Operating System for the Java™ Platform ------------------------------------------------------------------------ Contents * Introduction * New Features * Fixed Problems * Compatibility * Known Issues * Installation o Tru64 UNIX Patches o Installing the Kit o Deinstalling the SDK v 1.1.8 Kit o Deinstalling Other Versions * Using Multiple Versions o Changing Your PATH to Use SDK v 1.1.8 o Making SDK v 1.1.8 the Default System Java Environment Version o Switching the Default Version o Making Applications Insensitive to Changes in the Default Java Environment Version o Troubleshooting Multiple Versions * Using the SDK on Tru64 UNIX Systems o Determining Your Java Environment Version o Determining Your Default Java Environment Version o Controlling Heap Size o Controlling Stack Size o Mandatory Flag for Compiling C/C++ Code for JNI on Tru64 UNIX o Using the SDK with a Large Number of Threads * Prior Releases * Documentation and Other Information o More Information * Problem Reporting Introduction Thank you for downloading the Compaq Software Development Kit (SDK) v 1.1.8-14 for the Tru64™ UNIX® Operating System for the Java™ Platform (hereafter called the Compaq SDK or, simply, the SDK). These release notes contain installation instructions, known issues, new features, and other information specific to the Tru64 UNIX port of Sun Microsystems' Java Development Kit (JDK). This kit installs SDK v 1.1.8-14, an update to SDK v 1.1.8-13. The SDK v 1.1.8-14 update kit is based on Sun's JDK 1.1.8_009 Solaris Reference Release. This kit includes all the functionality and bug fixes that are in Sun Microsystems' JDK V1.1.8 and passes all the tests in Sun's Java Compatibility Kit test suite (JCK V1.1.8A). Use the java -version command to check the version of the SDK that you are using. This kit can be used to develop and run Java applets and programs on systems installed with Tru64 UNIX V4.0F, V4.0G, or V5.0A and higher. If you need to upgrade your version of Tru64 UNIX, refer to the Compaq Tru64 UNIX web site for additional information. Because these release notes are provided in both .txt and .html format, the URLs for hotlinks within this file are explicitly stated, or "installed files" are referenced (see the Documentation section of these release notes). IMPORTANT: Please make sure you understand the Copyright (COPYRIGHT, installed file) and License (LICENSE, installed file) information before using this release. New Features SDK v 1.1.8 is primarily a bug-fix release. Changes made to the JDK by Sun Microsystems since the first 1.1 beta release are in the file named changes.txt in the installed SDK documentation. This release also includes the following new features from Compaq: * The SDK v 1.1.8 release provides better packing of class fields on Tru64 UNIX systems. The allocation of non-static class fields has been changed in SDK v 1.1.8 to improve the memory usage of the JVM at runtime. This change does not have any effect on class files. The improved memory usage is limited to the in-memory classes once they have been loaded into the JVM. This change in field allocation will be transparent to most users. However, see the Compatibility section for when you will need to recompile native methods. * Starting with SDK v 1.1.8 from Compaq, you can have multiple SDK versions installed on your Tru64 UNIX system, and the ability to change the default version. See Using Multiple Versions. Fixed Problems This kit installs SDK v 1.1.8-14. The following sections provide important information about problems that Compaq has fixed in current and previous releases of SDK v 1.1.8. Problems Fixed in SDK v 1.1.8-14 This kit is based on the JDK 1.1.8_009 Solaris Reference Release from Sun Microsystems and is provided for your use on Tru64 UNIX systems. This kit also fixes the following problem: * Previously, using SDK v 1.1.8-13, the jar command created .jar files which could not be read. This problem has been fixed in this release. See sun_changes_1_1_8_009.txt for a list of other problems fixed by Sun in the 1.1.8_009 Solaris Reference Release. Problems Fixed in SDK v 1.1.8-13 The SDK v 1.1.8-13 kit is based on the JDK 1.1.8_008 Solaris Reference Release from Sun Microsystems and is provided for your use on Tru64 UNIX systems. This kit also fixes the following problems: * Many improvements have been made to SDK v 1.1.8 handling of Chinese and Japanese fonts. * Problems that caused earlier versions of SDK v 1.1.8 to hang or seg fault have been resolved. * Incompatibility involving zlib and SDK v 1.1.8 has been resolved. Problems Fixed in SDK v 1.1.8-10 The SDK v 1.1.8-10 kit is based on the JDK 1.1.8_008 Solaris Reference Release from Sun Microsystems and is provided for your use on Tru64 UNIX systems. This kit also fixes the following problems: * A problem that caused a memory leak when doing garbage collection on classes has been fixed. * A correction was made to the Numeric Keypad so that it works correctly in the context of AWT classes when the Num Lock key is set. * A correction was made for JTextField and JTextArea classes so that the Caps Lock key works correctly when displaying on Motif or CDE. * A correction was made for JTextField and JTextArea classes so that the Delete key works correctly. Problems Fixed in SDK v 1.1.8-7 The SDK v 1.1.8-7 kit is based on the JDK V1.1.8-003 patch version from Sun Microsystems, and is provided for your use on Tru64 UNIX systems. This kit also fixes the following problems: * A problem that caused the Java Virtual Machine to occasionally crash when running on multi-processor machines has been fixed. * The number of array elements was previously limited to 67,108,863 due to a bug which assumed a 32-bit limit. This has been corrected such that 64-bits are utilized and the maximum array elements has grown substantially. Problems Fixed in SDK v 1.1.8-5 The SDK v 1.1.8-5 kit is based on the JDK V1.1.8-002 patch version from Sun Microsystems, and is provided for your use on Tru64 UNIX systems. This patch version fixes the following problems: * This kit incorporates Sun's code fix for bug #4081779 titled "Container.remove(component) does not release the component from GridBagLayout" and #4170095 "Unintentional memory retention in GridBagLayout". Previously, this could lead to memory leaks in certain applications. * The SDK v 1.1.8-5 kit now provides font properties files to correctly support the display of Japanese and Chinese text. * Previously, Chinese input could not be entered for TextField components. The Sun bug numbers that are related to this problem are bug #4105612 and bug #4196573. This problem has been corrected. * Previously, when running the DateTimeFormat demo program and selecting Japanese as the language, Japanese characters could not be input to the pattern field. This problem has been corrected. * Sun bug #4267381 (Focus Lost problem) has been corrected for this release. * Previously, when using the eXcursion™ window manager, the following would occur: o A frame would jump back to a previous location. o A ComponentMoved event was not being recognized. These problems have been fixed. The frame no longer jumps and the ComponentMoved events are now recognized for a frame. * Previously, when using the Motif window manager or eXcursion window manager, the titlebar and border of the window frame would occasionally appear off the screen. This problem has been fixed. Problems Fixed in SDK v 1.1.8-2 * The SDK v 1.1.8-2 kit provides a modified /usr/opt/java118/lib/font.properties.ja file, which correctly displays English text when the locale is set to Japanese. * Previously, when remotely displaying to a Tru64 UNIX machine, the components (such as JPEGs, GIFs, and Swing components) of a top-level window might not display properly. This problem has been fixed. Compatibility There are some compatibility issues with SDK v 1.1.8: * Unlike prior SDK releases, this kit does not necessarily install SDK v 1.1.8 as the default version. You may need to define your PATH environment variable or make SDK v 1.1.8 the system default before you can use SDK v 1.1.8. See Using Multiple Versions. * You should not put /usr/lib/classes.zip in your CLASSPATH if you have multiple versions installed. Many Java users routinely include /usr/lib/classes.zip in their CLASSPATH, but that can result in unexpected program behavior when using a non-default version of the SDK. See Using Multiple Versions for more information. * Because of the new way that SDK v 1.1.8 packs class fields, you might need to recompile some of your native methods. Native methods that use header files created by running javah without the jni switch should be recompiled. In this case, the generated header file reveals the runtime structure of fields in a class. The javah command generates a C struct declaration with extra fields, named _PADn_, in between the user-defined fields. These _PADn_ fields are sometimes needed to assure the proper alignment of the user-defined fields. With the change to field allocation, the number and placement of the _PADn_ fields can be different. To ensure proper functionality with this release of the SDK, you should run javah and recompile any native methods that require the new header files. Here is an example to illustrate the change. Consider the following Java code: class fieldtest { int f1; long f2; int f3; } javah in SDK v 1.1.8 generates the following struct: typedef struct Classfieldtest { int f1; char _PAD8_[4]; int64_t f2; int f3; } Classfieldtest; javah in earlier releases of the SDK generated this struct: typedef struct Classfieldtest { int f1; char _PAD8_[4]; int64_t f2; char _PAD24_[8]; int f3; } Classfieldtest; The _PADn_ fields should not be referenced by the native methods, so just recompiling with the new header file is sufficient. Known Issues This kit passes the complete set of tests in the current version (V1.1.8A) of the Java Compatibility Kit (JCK) made available by Sun to licensees. However, there are some known problems in this release. They are: Font Point Sizes The JDK V1.1.8 as implemented by Sun for Solaris and Win32 incorrectly implements font point sizes. To correct this problem, our kit includes a font properties file named lib/font.properties.truepointsize which implements correct point sizes for Java fonts. To use this file, copy it to lib/font.properties. If you then wish to revert to the incorrect font sizes used by Sun, just delete lib/font.properties. Retired Fonts As of Compaq Tru64 UNIX Version 4.0F, all Adobe fonts under /usr/lib/X11/fonts/Type1Adobe are retired and no longer ship with the operating system. For more details on this, please refer to the section "Features and Interfaces Scheduled for Retirement" in the Release Notes for the Tru64 UNIX operating system. If your Java application uses the retired Type1Adobe outline fonts, it might be affected. For example, when characters are displayed on the screen, they might not scale as expected. If you customized your font.properties file to use these outline fonts, you might need to modify it to use alternative fonts that are available on your operating system. No replacements are being provided by the operating system. However, a smaller set of outline fonts is still available in /usr/lib/X11/fonts/Type1 and /usr/lib/X11/fonts/Speedo for your use. Problem with Component.getCursor() In SDK v 1.1.8, getCursor() might return null when called on a component that has not had its cursor explicitly set. This behavior is a bug. Existing applications that assume getCursor() will not return null might not work properly with the SDK or software for the Compaq Run Time Environment (RTE) v 1.1.8 for the Tru64™ UNIX® Operating System for the Java™ Platform (hereafter called the Compaq RTE or, simply, the RTE). The bug will be fixed in a future release of the SDK software. Unexpected Backspace Key Behavior If you use a non-PC style keyboard, or you display to a PC using eXcursion™, the Backspace key might not behave as expected when used in the context of one of the Swing text widgets (JTextField, JTextArea,...). Problem Description: Pressing the Backspace key deletes the character that the cursor is on as opposed to the character preceding the cursor. This is not a bug with the SDK. It has to do with the keycode sent by the Backspace key. Workaround: This behavior can be modified by instructing the keyboard driver to send a Backspace keycode instead of a Delete keycode. For eXcursion: a. Go to directory \win32app\xcursion\keysyms and copy the appropriate keyboard mapping file (keysym) to delfix.txt. Determining your keysym file: o keysym files all start with "isenh". o The next letter is either a 'd' or 'i'. (d is for Digital, i is for IBM compatible). Use the one that you have selected in your Control Panel keymapping style. o The next 2 letters are a Country code. Use the one for your country. b. Edit the file delfix.txt: Under the main keypad section, modify: 0x0E unshifted XK_Delete to be: 0x0E unshifted XK_BackSpace c. Save and exit the file. d. Bring up the Control Panel for eXcursion. e. Select the Custom Keyboard tab. f. Under Primary Mapping, select Custom Key Def File. g. Select delfix.txt. h. Save and restart the Server. This should reprogram your backspace key to send "backspace" instead of "delete". For X11 with non-PC style keyboard: Execute the command: xmodmap -e "keysym Delete = BackSpace Delete" Installation The following sections describe how to install the SDK v 1.1.8 kit on your Tru64 UNIX system. Tru64 UNIX Patches This kit requires Tru64 UNIX V4.0F, V4.0G, or V5.0A and higher. Presently, this SDK v 1.1.8-14 release does not require any operating system patches. However, the need for patches may be discovered after this release becomes available. Therefore, we recommend that you check our patch installation page for Compaq Tru64 UNIX for the latest information. Installing the Kit If your system currently has a previous SDK v 1.1.8 kit installed, then you must deinstall that kit before installing the SDK v 1.1.8-14 kit. If your system currently has a SDK v 1.2.n or SDK v 1.1.7B or earlier SDK kit installed, then you do not need to deinstall the kit to use the SDK v 1.1.8 Update release. Starting with SDK v 1.1.8, you can have multiple SDK versions installed on your system and can change the system default Java environment version under some circumstances. If there is not a default Java environment version on your system when this kit is installed, SDK v 1.1.8 is made the default. Otherwise, SDK v 1.1.8 is installed but not as the default system version. In this case you need to define your PATH environment variable or make SDK v 1.1.8 the system default before you can use SDK v 1.1.8. See Using Multiple Versions. NOTE SDK v 1.1.8 is available from our Software Download Page and is also bundled with some versions of the Compaq Tru64 UNIX operating system. However, the Java subset names are different. Kits downloaded from our Software Download Page begin with the subset name "JAVA." In contrast, Java subsets included with the Tru64 UNIX operating system begin with the name "OSF". For a description of both Java subsets, see Step 5. For additional information about installing the SDK during the Compaq Tru64 UNIX installation, see the Compaq Tru64 UNIX Installation Guide. To install SDK v 1.1.8, perform the following steps as superuser: 1. You may leave any SDK v 1.1.n installed kit in place. The SDK v 1.1.n kit remains the default and allows the SDK v 1.1.8 kit to be enabled when the PATH environment variable is modified. If you want to deinstall prior versions, see Deinstalling Other Versions. 2. If you installed a previous SDK v 1.1.8 kit, use the setld command to delete it: a. Use the setld -i command to determine which SDK v 1.1.8 subsets are installed: setld -i | grep JAVA118 | grep installed b. To delete all of the old Java subsets found, enter the setld -d command. For example: setld -d JAVA118 JAVADEV118 JAVADOC118 3. Download the following binary kit: java118-14.tar 4. Untar it into a scratch directory, /tmp/java, for example: cd /tmp/java tar xf /tmp/java/java118-14.tar The scratch directory now contains the kit plus the following files: release_notes.txt COPYRIGHT LICENSE 5. Use the setld command to load from that scratch directory: setld -l /tmp/java There are three subsets that you can install: o JAVA118 - The mandatory subset that provides support for running Java programs and applets. o JAVADEV118 - The development environment, which allows you to compile and debug Java code. o JAVADOC118 - The documentation subset. We recommend that you install all three subsets if you intend to use the SDK in a development capacity. Compaq Tru64 UNIX Subset Names The Software Download Page uses the subset names listed in Step 5. However, if SDK v 1.1.8 has been installed as part of the Compaq Tru64 UNIX operating system installation, it will have the following subset names: * OSFJAVAnnn - The mandatory subset that provides support for running Java programs and applets. * OSFJAVADEVnnn - The development environment, which allows you to compile and debug Java code. * OSFJAVADOCnnn - The documentation subset. where nnn refers to the base operating system version number. Note that if you are updating to a later version of SDK v 1.1.8, you must first deinstall these subsets. See Deinstalling Other Versions for instructions. 6. Once you have installed the desired subsets, you can delete the scratch directory. The SDK v 1.1.8 kit is installed under its own directory tree. This means that all the binary files, include files, library files, and so on, are listed in appropriate directories under /usr/opt/java118. As noted above, SDK v 1.1.8 may or may not be the default system Java environment after installation and you may need to take action before you can use SDK v 1.1.8. See Using Multiple Versions. Once you are set up to use SDK v 1.1.8 by means of one of these methods, the java -version command should display the following for this kit: % java -version java version "1.1.8-14" Deinstalling the SDK v 1.1.8 Kit If you want to deinstall this kit in the future, perform the following steps as superuser: 1. Use the setld -i command to determine which SDK v 1.1.8 subsets are installed. For example: setld -i | grep JAVA | grep 118 | grep installed 2. To delete subsets, enter the setld -d command. For example, setld -d JAVA118 JAVADEV118 JAVADOC118 Deinstalling Other Versions To deinstall other versions, perform the following steps as superuser: 1. Use the setld -i command to determine what Java subsets are installed and which you want to delete. 2. Use the setld -d command to delete the Java subsets. For example: % setld -i | grep JAVA | grep installed OSFJAVA440 installed Java 1.1.7B-5 Environment (General Applications) OSFJAVADEV440 installed Java 1.1.7B-5 Development Environment OSFJAVADOC440 installed Java 1.1.7B-5 Online Documentation % setld -d OSFJAVA440 OSFJAVADEV440 OSFJAVADOC440 Using Multiple Versions With SDK v 1.1.7B and previous versions, it was possible to install only one SDK version on a system. Starting with SDK v 1.1.8 and SDK v 1.2.1, you can install and use multiple versions on one system. In addition, you can change the version that is used by default when you type Java commands. When you install SDK v 1.1.8, all files are installed in directories under /usr/opt/java118. In addition: * If a default system Java environment version (/usr/bin/java) is not found during installation, SDK v 1.1.8 is installed as the default system Java environment version on the system and no special actions are required before using SDK v 1.1.8. In this case, the java -version command should display the following after installation: % java -version java version "1.1.8-14" * If a default system Java environment version is found during installation, SDK v 1.1.8 is installed on the system but is not made the default Java environment version. In this case, you need to take one of the following actions before you can use it: o Change your PATH environment variable so that the directory containing the SDK v 1.1.8 binaries is searched before the system directories. See Changing Your PATH to Use SDK v 1.1.8. o Make SDK v 1.1.8 the system default. See Making SDK v 1.1.8 the Default System Java Environment Version. You can make SDK v 1.1.8 the default Java environment version on your system at any time, provided that no SDK version prior to SDK v 1.1.8 is installed. When you make SDK v 1.1.8 the default, system files such as /usr/bin/java are modified so that SDK v 1.1.8 is used whenever Java commands are entered, and defining your PATH is not necessary. Changing Your PATH to Use SDK v 1.1.8 If SDK v 1.1.8 is not the default Java environment version on your system, you must either specify the full pathname of the java command or change your PATH environment variable to use it. * To specify the full pathname of the java command: % /usr/opt/java118/java -version java version "1.1.8-14" * To switch to using SDK v 1.1.8: 1. Place directory /usr/opt/java118/bin first in your PATH. This is the directory that contains the SDK v 1.1.8 executables. For example, using csh(1): setenv PATH /usr/opt/java118/bin:$PATH 2. Verify that you are using SDK v 1.1.8: % java -version java version "1.1.8-14" 3. Check your CLASSPATH to make sure that you won't use the classes.zip file for a version of the SDK other than SDK v 1.1.8: % printenv CLASSPATH To avoid the possibility of using the wrong classes.zip file, you should: + Remove /usr/lib/classes.zip from your CLASSPATH. + Remove /usr/opt/javannn/lib/classes.zip from your CLASSPATH for any version nnn other than 118. Using classes.zip from one version of the SDK with Java commands from another can result in unexpected program behavior. For example, if SDK v 1.1.7B is the default version and your CLASSPATH contains /usr/lib/classes.zip, your program will use the SDK v 1.1.7B classes.zip. If you then define your PATH to use SDK v 1.1.8, it is likely that your program will get a segmentation fault. If your CLASSPATH is not set, the correct classes.zip file will be used by default when you modify your PATH as described above. If you want to explicity reference the SDK v 1.1.8 classes.zip in your CLASSPATH, you should modify your CLASSPATH to include /usr/opt/java118/lib/classes.zip. * To stop using SDK v 1.1.8, remove /usr/opt/java118/bin from your PATH. Making SDK v 1.1.8 the Default System Java Environment Version Perform the following steps as superuser to make SDK v 1.1.8 the default system Java environment version on your system: 1. Determine what the default system Java environment version is on your system by using the following command: /usr/bin/java -version # Note: Use /usr/bin/java to insure # that the default Java is executed. 2. Choose one of the following actions based on the version of the default system Java environment version: o If the above command results in a "command not found" message, there is currently no default system Java environment version on your system, and therefore nothing needs to be removed. After doing the following, SDK v 1.1.8 will be the default: /usr/opt/java118/bin/set_java_default.sh o If a version later than SDK v 1.1.7B, say SDK v 1.2.2, is the default, do the following to remove it as the default and to set SDK v 1.1.8 as the new default: /usr/opt/java121/bin/unset_java_default.sh /usr/opt/java118/bin/set_java_default.sh o If SDK v 1.1.7B or a previous version is the default and no one on your system needs it, deinstall the old default (see Deinstalling Other Versions) and then make SDK v 1.1.8 the default version by doing: /usr/opt/java118/bin/set_java_default.sh 3. Verify that SDK v 1.1.8 is now the new default version: /usr/bin/java -version java version "1.1.8-14" Switching the Default Version If any versions prior to SDK v 1.1.8 are installed, this section does not apply. You need to deinstall any older versions before you can make SDK v 1.1.8 or later the default version. See Deinstalling Other Versions. If you have made SDK v 1.1.n the default version (for n greater or equal to 8), this section shows how to switch the default version to SDK v 1.2.n. Also, in the future, users can have an arbitrary number of different SDK versions; this section gives a general recipe for switching from one to another. Assume that SDK v 1.1.n and SDK v 1.2.n are currently installed and that SDK v 1.1.n is the current default. To make SDK v 1.2.n the default Java environment version, perform the following steps as superuser: 1. Verify that SDK v 1.1.n is the current default: /usr/bin/java -version # Note: Use /usr/bin/java to insure # that the default Java is executed. 2. Remove SDK v 1.1.n as the current default: /usr/opt/java11n/bin/unset_java_default.sh Note that this script does not deinstall SDK v 1.1.n. You can make SDK v 1.1.n the default again later if desired. 3. Make SDK v 1.2.n the current default version: /usr/opt/java12n/bin/set_java_default.sh 4. Verify that SDK v 1.2.n is now the default version: /usr/bin/java -version Making Applications Insensitive to Changes in the Default Java Environment Version You may have applications that rely on SDK v 1.1.8. To safeguard them against future changes in the default Java environment version, you can run them from scripts that set the PATH to SDK v 1.1.8. See Changing Your PATH to Use SDK v 1.1.8. Troubleshooting Multiple Versions If you have multiple versions installed on your system and have troubles running Java applications, first check what Java environment version you are using and what the default Java environment version is on the system: % java -version # Check version being used % /usr/bin/java -version # Check default Java on system Then check your definitions of PATH and CLASSPATH: printenv PATH printenv CLASSPATH If you encounter the error "java: Permission denied", check that PATH is set properly. See Changing Your PATH to Use SDK v 1.1.8. If you get a seg fault or other unexpected behavior when running your Java application, check your CLASSPATH to make sure that you are not using a classes.zip from an SDK version other than SDK v 1.1.8. See Changing Your Path to Use SDK v 1.1.8. Using the SDK on Tru64 UNIX Systems The following sections provide some useful tips for using the SDK on Tru64 UNIX systems. Using SDK v 1.1.8 See Changing Your PATH to Use SDK v 1.1.8 for information about defining your PATH environment variable to use SDK v 1.1.8. Also, see Making SDK v 1.1.8 the Default System Java Enviornment Version if you want to make SDK v 1.1.8 the default Java environment version on your system. Determining Your Java Environment Version Use the following command to see what Java environment version you are using (refer to Frequently Asked Questions for an explanation of this version-naming convention): % java -version java version "1.1.8-14" Determining Your Default Java Environment Version Use the following command to determine the Java environment version you are currently using: % /usr/bin/java -version java version "1.1.8-14" Controlling Heap Size The initial heap size (-ms) and maximum heap size (-mx) command-line options control the size of the Java heap. The default values for these are: initial heap size = 1048576 bytes maximum heap size = 16777216 bytes The Java heap, by default, is allocated at address 0x10000. The maximum heap size prior to SDK v 1.1.7B was limited to 2147475455 by its underlying int type. (This value is slightly less than INT_MAX because of a rounding calculation applied to the user-specified value.) Starting with SDK v 1.1.7B, the -mx and -ms command-line option values are treated as longs, allowing much larger heaps. Example: java -mx40000m MyApp Heaps larger than 2147475455 are allocated at address 0x20000000000. Note that there may be a noticeable start-up delay in initializing the heap's internal data structures if you specify a very large initial heap value (for example, -ms4000m). You can avoid this by using a smaller initial heap size. This effectively spreads the cost of expanding the heap structures over the execution of the application. For JNI users who create JVM's from native code, the minHeapSize and maxHeapSize fields in the JDK1_1InitArgs structure remain as jints. However, you can use the macros SET_MIN_HEAP_SIZE and SET_MAX_HEAP_SIZE, defined in jni.h, to specify values for heaps larger than 2147475455. Please see the comments in the file jni.h for more information. Your system must be properly set up to allow very large heaps. The garbage collector initialization code will try to allocate the maximum sized heap. If this fails, it will continually apply a "backoff" factor of .75 and will try again. Heap allocation succeeds if the heap size successfully allocated is not less than the -ms value. Thus, it may appear as if you got the maximum heap size you asked for when you did not. To avoid excessive page faulting, consider the amount of physical memory available to your process when choosing the maximum heap size. Garbage collection tends to walk through the entire heap, so you'll need at least enough to insure that none of the heap is paged out. For more information on system tuning and resource limits, see the following: * Tru64 UNIX System Configuration and Tuning, specifically the section Increasing Address Space * C shell commands limit and unlimit, specifically addressspace * manpages setrlimit(2) and getrlimit(2) Controlling Stack Size You can increase or decrease the maximum native stack size using the -ssn command-line switch. Note that decreasing the native thread stack size can save memory but can also result in segmentation violation errors or other problems if the native thread stacks are too small. Mandatory Flag for Compiling C/C++ Code for JNI on Tru64 UNIX All C/C++ code compiled for use with JNI must be built (compiled and linked) with the C/C++ -pthread flag. Otherwise, your application will encounter severe multi-threading problems, even if your Java code and C/C++ code do not explicitly use threads. For more information about the -pthread flag, please see the C/C++ man pages. Using the SDK with a Large Number of Threads If you experience a "java.lang.OutOfMemoryError" when attempting to create a large number of threads, consider increasing the system (that is, kernel) parameter vm-vpagemax. A recommended setting is the number of 8k pages used in the program's virtual address space. For example, for a 1Gbyte virtual address space, vm-vpagemax should be set to 128000. This parameter is described in the Tru64 UNIX System Configuration and Tuning manual. Relevant tools are briefly described by man sysconfig and man sysconfigdb. To change the vm-vpagemax parameter, use the /sbin/sysconfigdb command to update a section of /etc/sysconfigtab. For example, to modify vm-vpagemax to be 128000, the input file to the /sbin/sysconfigdb command (specified using the -f option) would contain the following: vm: vm-pagemax = 128000 The default value for vm-vpagemax is 16384. Use the following command to determine the value of vm-vpagemax on a running system: % > sysconfig -q vm vm-vpagemax vm: vm-vpagemax = 16384 Prior Releases Features of the SDK v 1.1.7B Release * With SDK v 1.1.7B, the amount of heap space that can be used for Java objects has been increased so that Java programs can take full advantage of 64-bit addressing on Alpha. With previous versions, the heap space used for Java objects was limited to 2,147,475,455 bytes. Note, however, that the Java Debugger (jdb) does not support heap sizes larger than 2,147,475,455. With SDK v 1.1.7B, the way the SDK allocates the heap has changed: first, the SDK makes an initial check to insure that the maximum requested heap size, as specified by the -mx switch, can be allocated. Then the SDK allocates a minimum heap size and grows the heap incrementally to the maximum heap size. This means that the amount of heap space used by your Java program depends on how much it actually needs. In previous SDK releases, the maximum requested heap size was allocated by the SDK at program startup, regardless of whether or not it was actually used by your Java program. * The SDK v 1.1.7B kit includes the Sun Java demos. These demos are included in the OSFJAVADOCxxx subset of the kit (where xxx represents a number such as 440, which corresponds to the version of the operating system). The demos are installed in: /usr/share/doclib/java/demo Features of the SDK v 1.1.6 Release The SDK v 1.1.6 release fixes a garbage collector bug in previous SDK v 1.1.n releases that could lead to segmentation faults when running Java programs. The -taso option is supported for RTE. See the next section for information on the -taso option. Features of the SDK v 1.1.3 Release The -taso Option The SDK v 1.1.3 release supports the -taso option. This option causes all Virtual Machine addresses to be mapped into 31-bit address space. Specify the -taso option if your Java program calls native methods that were built with 32-bit pointers. This includes, for example, native methods that were compiled with the cc options -xtaso and -xtaso_short. To use the java -taso option: java -taso my_class_file or java_g -taso my_class_file To use -taso with appletviewer: appletviewer -J-taso my_class_file Features of the SDK v 1.1.1 Release Audio Support The SDK v 1.1.1 release contains support for Java Audio classes. Features of the SDK v 1.1 Release POSIX Threads SDK v 1.1 is implemented using POSIX threads. This allows different Java threads in your application to run on different processors, provided that you have a multi-processor machine. It also means that your Java application will run properly when linked with native APIs (such as DCE) that also are implemented using POSIX threads. Just-in-Time Compiler The SDK v 1.1 release contains a Just-in-Time (JIT) compiler to substantially increase run-time performance. The JIT compiler provides on-the-fly compilation of your application's Java byte-codes and runtime calls into native Alpha machine code. This results in significantly faster execution of your Java application compared with running it using the Java interpreter, while maintaining the same behavior. Please see our Compaq web page for benchmark results. The JIT compiler runs by default when you enter the java command. If you want to run the interpreter when you enter the java command, use the -nojit option. For example: java -nojit ... The Java Debugger runs the interpreter. Running the Java Debugger with the JIT compiler is not supported. The JIT compiler runs by default when you run appletviewer. To run appletviewer using the interpreter, use the -J-nojit option. For example: appletviewer -J-nojit ... Documentation and Other Information Documentation If the optional documentation subset (JAVADOC118) is installed, then the SDK documentation tree begins at the following location on the system where the SDK is installed: /usr/opt/java118/docs/index.html The installed documentation is in html format and includes this release notes file (which describes SDK information specific to Tru64 UNIX systems) and a readme.txt file (which contains general information on using the Java programming language). It also includes the Java Language Specification and API reference documentation. You can browse the Software Documentation page on our web site. Lastly, there is a java manpage that describes the java command and points to the installed documentation. The java manpage ships with the operating system and describes the version of the SDK that was shipped; the manpage is not updated by this kit. More Information For more information on this release, refer to our Frequently Asked Questions (FAQ) web page. If you are new to the Java programming language, you will want to browse or download Sun's Java Tutorial at http://java.sun.com/docs/books/tutorial/. Problem Reporting To report problems, refer to our Contact Us web page. ------------------------------------------------------------------------ © 2002 Compaq Information Technologies Group, L.P. Compaq Registered in U.S. Patent and Trademark Office. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other product names mentioned herein may be trademarks or registered trademarks of their respective companies. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is subject to change without notice.