The production release of the Java 2 SDK Standard Edition (previously known as Java Development Kit (JDK) 1.2) provides a high-performance Java Virtual Machine (JVM) from Sun Microsystems which has been optimized for Solaris system software. It is supported in the Solaris 7 and Solaris 2.6 system software.
These release notes include:
The documentation that accompanies this release is intended to supplement and, where applicable, to supersede the Java 2 SDK documentation set available at:
http://java.sun.com/products/jdk/1.2/docs
Specific information regarding compatibility of Java 2 SDK releases with JDK 1.1 releases is available at:
http://java.sun.com/products/jdk/1.2/compatibility.html
The Java 2 SDK, Standard Edition v. 1.2.1_03 is the latest release of the Java 2 platform for the Solaris operating environment. It includes these enhancements:
This diagnostic tool for interactively killed programs, is accessible from the SIGQUIT handler menu. It can be used to find memory leaks in your programs. A memory leak occurs when a program inadvertently retains objects, preventing the garbage collector from reclaiming the memory. Heap inspection presents a per-class breakdown of the objects in the heap, sorted by total amount of memory consumed. You can then examine reference chains to selected objects to see what is keeping them alive.
Double-word values are now aligned to 8-byte boundaries in the heap. This improves the performance of both native code and JIT-compiled Java code while ensuring correctness of volatile double-word values on SPARC systems. However, if your application allocates and retains many small objects, you may need to increase your heap size(s) slightly, since these objects will be allocated in multiples of 8 bytes, increasing your memory usage.
NOTE: If your application involves numerical calculations and native code, it could be affected by the double-word alignment change.
The Solaris VM included in the Java 2 SDK production release can improve Java performance by 500% or more compared to earlier releases. In addition, server-class applications can now handle over double the capacity of earlier releases -- enabling faster response times under peak performance loads.
The Java 2 platform for Solaris system software provides the new Java 2 APIs, improved stability, and an enhanced Java Virtual Machine (JVM) that provides substantially increased scalability and performance compared to earlier JDK 1.1-based releases. As a result, Java applications running with the Java 2 SDK on Solaris may realize double or higher the performance of earlier releases.
Increased performance is largely due to the scalable architecture of the JVM which has improved in bytecode execution, memory management and thread synchronization performance as a result of the following new features:
The Java 2 SDK includes an optimizing JIT compiler which improves performance without sacrificing application start-up time. Specifically, the JIT compiler has improved in its ability to identify optimization opportunities, translating frequently invoked methods and methods with loops into highly efficient native code.
The JVM also includes a highly optimized memory system, making memory allocation and garbage collection more efficient. It is a direct-pointer, non-conservative, fully compacting, generational memory system. This feature increases batch program performance and reduces disruptive garbage collection pauses in interactive programs.
The JVM has significantly improved implementations of the Java platform's synchronization primitives. These implementations make concurrent programs more efficient and decrease the impact of the synchronization primitives on single-threaded application performance.
The Java 2 SDK man pages are installed in /usr/java1.2/man . In order to be able to read them, enter
setenv MANPATH /usr/java1.2/man:$MANPATH
The maximum recommended open fd s for Solaris 2.6 is 1024. For Solaris 7 and subsequent releases, the maximum is 65527.
The UNIX versions of the java utilities no longer perform parameter substitution or wildcard expansion. Though this behavior did previously occur, it was not part of the specification and was contrary to expected UNIX behavior where shells perform a substitution or expansion before invoking a utility. This normal UNIX response can result in a behavior change when an expected wildcard or shell parameter is passed directly to a java utility (for example, not through a shell). If parameter substitution or wildcard expansion is required, use an intermediate shell to perform the expansion.
The JAVA_COMPILER environment variable no longer selects the JIT compiler to be used. It can now only be used to enable or disable the default JIT compiler. The JIT compiler's default state is on. To disable the JIT compiler, set the JAVA_COMPILER environment variable to NONE . In csh , this is done by entering:
setenv JAVA_COMPILER NONE
In sh or ksh , this is done by entering:
JAVA_COMPILER=NONE
export JAVA_COMPILER
To re-enable the JIT compiler, unset the JAVA_COMPILER environment variable or set it to sunwjit . In csh , the environment variable can be unset by entering:
unsetenv JAVA_COMPILER
In sh or ksh , this is done by entering:
unset JAVA_COMPILER
Setting JAVA_COMPILER to a value other than NONE or sunwjit will result in a warning and the default JIT compiler being enabled.
Applications written using NMI are incompatible with Solaris_JDK_1.2.1_03, which now supports the Java Native Interface(JNI). Recognizing that the removal of NMI support is a compatibility change, provisions have been made to allow both JDK 1.1 and 1.2 to reside on Solaris systems.
For further information, refer to:
HotJava versions 1.1.5 and earlier are incompatible with Solaris_JDK_1.2.1_03.
The release name for this and future releases may be displayed using java -version , and can be interpreted as follows for the Solaris_JDK_1.2.1_03 release:
|
Solaris_JDK_ |
= constant for all Sun Solaris JDK releases |
|
1.2.1 |
= denotes the version of the reference JDK that this version of the Solaris JDK is compatible with, as measured by the corresponding version of the JCK. |
|
03 |
= a number that increases with every new 1.2 release update. |
The following Solaris patches are required for Solaris 2.6 for the zh_TW and zh locales:
106409-01 for SPARC
106410-01 for Intel
This section discusses problems you may encounter both during and after installation. Recommendations for dealing with such problems are provided when available.
For installation instructions, refer to README.sparc or README.i386 files that accompany this release.
Information in this section affects only package installations that change the top level directory where the JDK is installed using either:
- a custom admin(4) file (e.g. pkgadd -a my_admin_file ... )
or
- no admin file (e.g. pkgadd -a none ... )
The top level directory where the JDK files are installed is determined by the BASEDIR parameter in the admin file (see admin(4) and pkgadd(1) for details). Starting with this release, Java 2 SDK uses /usr as the default BASEDIR value and stores files under the directory $BASEDIR/java1.2 . For example:
$BASEDIR/java1.2/bin/java
Previous Early Access releases of Java 2 SDK used / as the default BASEDIR value and stored files under the directory $BASEDIR/usr/java1.2.
Installing with an admin file that includes the line BASEDIR=/export will place the JDK files in the following locations.
For Solaris_JDK_1.2.1_03 and future releases:
/export/java1.2/bin/java
/export/java1.2/lib/...
For previous Early Access releases:
/export/usr/java1.2/bin/java
/export/usr/java1.2/lib/...
The /usr component, appended to BASEDIR in earlier releases, was unnecessary and has been removed in this release.
During installation, you may get warnings indicating that font packages, optional for Solaris, have not been installed:
|
|
The
/usr/java
symbolic link points to the JDK that is the default on that system. JDK 1.1 currently installs in
/usr/java1.1
. This release of Java 2 SDK will install by default in
/usr/java1.2
. The
/usr/java
symbolic link will continue to point to 1.1 after installation of 1.2 unless manually changed.
To make Java 2 SDK the default, do the following as root:
# /usr/bin/mv /usr/java /usr/java.oldlink
# /usr/bin/ln -s /usr/java1.2 /usr/java
After you do this there will be some symbolic links in /usr/bin, created by the JDK 1.1 installation that no longer point to anything. These links are for tools that are part of the JDK 1.1 distribution but not part of the Java 2 SDK distribution.
After you have changed the /usr/java symbolic link, applications using NMI will fail, but keeping both JDKs on the system makes the workaround trivial and supportable. Applications that require JDK 1.1 can still be run as long as you provide the full path to the correct invocation script; e.g. /usr/java1.1/bin/java. You may also need to explicitly set the CLASSPATH, LD_LIBRARY_PATH and JAVA_HOME environment variables in your execution environment.
To restore JDK 1.1 as the default JDK, do the following, do the following as root:
# /usr/bin/mv /usr/java.oldlink /usr/java
If you get an error message mentioning a libthread panic or an I/O exception, it is possible that the file descriptor limit has been reached.
The Java2D demo is an example of an application that requires a higher file descriptor limit than the default. The number of file descriptors can be increased in the C shell ( csh ) using the command:
limit descriptors 256
The number of file descriptors can be increased in the Bourne shell ( sh ) or the Korn shell ( ksh ), using the command:
ulimit -n 256
If you get a message such as the following, refer to the README.sparc or README.i386 for information on Solaris patches.
You must install a Solaris patch to run this version of the Java runtime environment.
If you get a message that reads ***Out of memory, exiting*** , check to see that the application is linking with libthread.so before libjvm.so . In this event, messages will appear in the early phase of VM initialization
To avoid this problem, link libthread before libjvm or set LD_PRELOAD to include libthread.so . In csh , type:
setenv LD_PRELOAD libthread.so
In sh or ksh , type:
LD_PRELOAD=libthread.so export LD_PRELOAD
These bug fixes are particularly important.
The JDK now correctly sets NLSPATH to retrieve localized messages for libXm . FileDialog strings can now be displayed in English for non-English locales.
The timestamp on InputEvents was being incorrectly returned by the InputEvent.getWhen() method.
A socket write of more than 64k elements produced an ArrayIndexOutOfBoundsException .
Calling a simple servlet using
http://somehost/servlet/ForwardServlet?forward=DateServlet
then touching DateServlet.class , calling the url again while running jdb remotely and issuing manual gc commands to collect garbage, the Java 2 JVM dumped core the second time in the cs.forward() call during garbage collection.
This was a SPARC-only problem.
A bug in the JNI attach calls were causing the VM to panic. On a heavily-loaded MP, there is a window during which the VM will fail if a garbage collection is required.
Japanese characters were not visible in Java2D or Swing applications which use Java2D fonts in the Japanese locale.
An exception should have raised in this instance.
Hostname resolution using java.net package classes such as InetAddress was not working correctly on NIS+ networks.
Default font selections for the locale zh_TW.Big5 for Solaris 2.6 were incorrect.
As there are no scalable Big 5 fonts for Solaris 2.6, Chinese characters were not visible in Swing components.
Install these patches to display Korean characters in Swing components which use the ko locale on Solaris 7:
107078-08 for SPARC
107079-08 for Intel
This section documents those open bugs deemed significant.
Both LC_CTYPE=en_US and iso_8859_1 should be 8-bit clean.
When you set the DISPLAY environment variable to a host other than the one running the virtual machine, underlined text in a network browser displays at a much slower rate than text that is not underlined.
Text rendering on Solaris platforms without DGA (Direct Graphics Access) support is significantly slower with JDK 1.2 than with 1.1. This applies to Ultra 5, Ultra 10, Solaris Intel platforms and remote display.
The server hangs when the system time changes (for instance, when Daylight Savings Time starts).
Workaround: Avoid changing the time when such sleeps are in progress.
While the mouse was moving in the application's windows, a large number of these messages occurred:
*** Calling native method notifyAll a slow way! ***
*** Calling native method wait a slow way! ***
Workaround:
For a Java application to display correctly under these circumstances, add
-verbose
to the
java
command line and redirect to
/dev/null
.
serialver -show dialog is unlocalized.
Workaround: Use Solaris 7.
ko.UTF-8 should be taken out as there is no support for UTF-8 Solaris locale. When ko.UTF-8 is supported, this string should be entered into the SUNWloc value in pkginfo .
htt_server core dumps when some specific Korean-Chinese (Hanja) words are entered.
There is no scalable font for this locale in either Solaris 2.6 or 7. Without the Canvas widget, AWT can display Korean.
Korean filename cannot be entered on either Solaris 2.6 or 7. The input method recognizes the typed characters, but does not place them in the filename text field.
Workaround: Use CDE instead of OpenWindows.
The clock applet in the demo displays blanks instead of Korean characters for the time and date. This does not happen for the ko locale.