Print-friendly Version

Java 2 SDK v1.3.0 for Solaris Release Notes

These release notes include:

• Product Summary and Enhancements
• Limitations in this Release
• Product Notes
• Installation
• Troubleshooting

The most up-to-date version of these release notes may be found online:

http://java.sun.com/j2se/1.3/relnotes-solaris.html

http://java.sun.com/j2se/1.3/docs

Specific information regarding compatibility of Java 2 SDK v1.3.0 with previous releases is available in the Developer's Guide and online at:

http://java.sun.com/j2se/1.3/compatibility.html

Product Summary and Enhancements

The Java 2 SDK, Standard Edition, v. 1.3.0 is the latest release of the Java 2 Platform for the Solaris operating environment. It includes the following new features and enhancements:

Performance Enhancements

This release of the Java 2 SDK contains two VM implementations, each with Java HotSpot technology. The Java 2 Client VM is the default VM, specially tuned for fast start-up times for client-side applications. The Java 2 Server VM is tuned for fastest peak operating speed for long-running server-side applications. In addition, the class libratires have been tuned for better performance. In particular, JFC/Swing and AWT libraries make GUI-based applications better start-up time, more responsive, faster operation, and smaller memory footprint.

Applet Caching and Automatic Deployment of Optional Packages

Applet caching ensures that often-used applets are always available for rapid loading and fast staru-up by keeping copies of the applets in a local cache. This does away with the need for a browser to download the applet over the network every time it's needed - the local cached copy can be rapidly loaded instead.

Optional packages are sets of features and APIs that, while not part of the Java 2 Platform, are available separately for developers to use for specialized programming needs. Examples of optional packages are JavaHelp and JavaMail. The Java 2 SDK v1.3 introduces a feature that enables applets to specify version and vendor information for any optional packages that they require.

RMI-IIOP Added

The Java 2 SDK includes two significant enhancements to support for CORBA technologies: a production CORBA IDL compiler written in the Java language and the RMI over IIOP API. CORBA IDL (Interface Definition Language) defines only interfaces for distributed systems. By using a neutral language to define interfaces, CORBA can support multiple languages. For the first time, the Java 2 SDK includes an IDL compiler to compile language-neutral CORBA IDL into standard Java language bindings. These language bindings work with the JavaIDL Object Request Broker to support traditional CORBA programming in the Java language.

Java Naming and Directory Interface (JNDI) Added

JNDI enables developers to add naming and directory functionality to applications. JNDI consists of an API and SPI (Service Provider Interface). Java applications use the API to access a variety of naming and directory services. The SPI enables a variety of naming and directory services to be plugged in transparently, allowing the Java application using the JNDI API to access their services.

Java Sound Added

Java 2 SDK includes the Java Sound API which define a set of standard classes and interfaces for low-level audio support. The Java Sound API enables Java programs to capture, process, and play audio and MIDI (Musical Instrument Digital Interface) data. The Java Sound API is supported by an efficient sound engine which guarantees high-quality audio mixing and MIDI synthesis capabilities for the platform. Additionally, the API defines a set of service provider interfaces which developers may use to extend the capabilities of the current implementation. Users can install modules that provide support for additional file formats, codecs, and devices.

On Solaris platforms with UTF-8 locales, textfields in frames that have been packed are not properly sized. This may cause problems with how the text is displayed including no text displayed at all. To workaround the problem, resize the frame that contains the textfield(s) and the text will be displayed properly. This problem is being tracked as bug number 4366053.

Java Plug-in Fails to Load on Netscape Browser

On first attempt, the Netscape browser sometimes fails to load Java Plug-in 1.3 correctly. If you see this problem, close and restart the browser. The browser will correctly load the Java Plug-in on the second attempt. This problem is being tracked as bug 4358142.

Drag and Drop Limitation

Performing several (about 10 or 15) rapid drag-and-drop operations in succession may result in a thread error message, or, in the worst case, the cursor may freeze and the screen will stop responding to user action. This problem is being tracked as bug 4313374.

Users who encounter the frozen screen can log on remotely (using rlogin) to the machine that's experiencing the problem, use the ps utility to identify the process that's hung, and terminate it from the remote location using the kill utility.

libmawt.so Not Loaded Properly on Solaris 2.6/Intel

On Solaris 2.6 for Intel x86 platforms, the libmawt.so library is not loaded properly. This problem may manifest itself in several ways, depending on the application. Some typical symptoms:

• UnsatisfiedLinkError in AWT applications (libmawt.so: open failed: No such file for directory).
• The policytool will not open.
• The Java Plug-in Control Panel will not open.

Workaround this problem by modifying the LD_LIBRARY_PATH. On csh:

setenv LD_LIBRARY_PATH /usr/j2se/jre/lib/i386/motif12:$LD_LIBRARY_PATH

This problem is being tracked as bugs 4322020 and 4357674.

When it becomes available, linker patch 105491-09 will fix this problem. Check the SunSolve web site for availability of this patch.

Stdout and Stderr for Child Processes

The behavior of the output and error streams of child processes is different in this production release of J2SE than it was in the previously available reference implementations of J2SE. (The behavior of streams has not changed as compared with previous production versions of J2SE.) Unlike the reference implementation of J2SE 1.3, the streams in this production version are not automatically read in the background. If you see that a process forked using Runtime.exec() hangs after printing substantial output to its stdout or stderr streams, please try something like the following:

import java.io.*; public class StreamMonitor implements Runnable { private InputStream istream; public StreamMonitor(InputStream stream) { istream = new BufferedInputStream(stream); new Thread(this).start(); } public void run() { byte[] buffer = new byte[4096]; try { while (true) { istream.read(buffer); } } catch (IOException e) { try { istream.close(); } catch (IOException e2) {} // Should allow clean exit when process shuts down } } }

Then, after creating the process:

new StreamMonitor(process.getInputStream());
new StreamMonitor(process.getErrorStream());

J2SE 1.3 includes the Java HotSpot Client VM and Java HotSpot Server VM. These VMs support the new Java Platform Debugger Architecture (JPDA), a set of interfaces designed for use by debuggers in development environments. See the JPDA documentation for details.

http://java.sun.com/j2se/1.3/docs/guide/jpda/

The sun.tools.debug interface that was compatible with the VM implementation in previous releases of the Java platform is obsolete and is not supported by J2SE 1.3.

For compatibility with existing JNI applications, J2SE 1.3 contains the following symbolic link:

/usr/j2se/jre/lib/<arch>/libjvm.so -->
   /usr/j2se/jre/lib/<arch>/client/libjvm.so

This links the location that the VM had in J2SE 1.2 to the location of J2SE 1.3's default VM, the Java HotSpot Client VM.

Setting LD_LIBRARY_PATH:

• Client VM - If the application is to be run with the Java HotSpot Client VM, LD_LIBRARY_PATH can be set to

  $JAVA_HOME/jre/lib/$ARCH/
  

  This is symbolically linked to the Client VM's directory. As an alternative, the Client VM's directory can be explicitly placed at the front of LD_LIBRARY_PATH:

  $JAVA_HOME/jre/lib/$ARCH/client:$JAVA_HOME/jre/lib/$ARCH
  

• Server VM - If the application is to be run with the Java HotSpot Server VM, the Server VM's directory must be placed in front of $JAVA_HOME/jre/lib/$ARCH:

  $JAVA_HOME/jre/lib/$ARCH/server:$JAVA_HOME/jre/lib/$ARCH
  

The symbolic link allows a JNI application to be linked against the Java HotSpot Client VM with

CC ... -L $JAVA_HOME/jre/lib/$ARCH -l jvm

A JNI application can link against the Java HotSpot Client VM even if later the application will be run with the Java HotSpot Server VM.

See the J2SE 1.3 JNI documentation for more information on the Java Native Interface.

http://java.sun.com/j2se/1.3/docs/guide/jni/

Font Packages Information

Please refer to the README for information related to the font packages.

Viewing Java man Pages

The Java 2 SDK man pages are installed in /usr/j2se/man. In order to be able to read them, enter

setenv MANPATH /usr/j2se/man:$MANPATH

Per-Process File Descriptor ( fd ) Limits

The maximum recommended open fd s for Solaris 2.6 is 1024. For Solaris 7 and subsequent releases, the maximum is 65527.

Native Method Interface (NMI) Applications Not Supported by This Release

As with version 1.2, applications written using NMI are incompatible with J2SE 1.3, 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 the Java 2 SDK to reside on Solaris systems.

For further information, see Running with Multiple Versions of this document.

Release Version

The release version for this and future releases may be displayed by using the command java -version.

International Locale Support

In the following table, the locales supported by J2SE 1.3 are indicated with an X. For a list of patches required for support of various locales, see the patch lists in the README.sparc or README.i386 file.

Table 1: Supported Locales

Locale	Solaris Version
	2.6	7	8
German
de_DE.UTF-8		X	X2
de.ISO8859-15	X1	X1	X
de	X	X	X
Spanish
es_ES.UTF-8		X	X2
es.ISO8859-15	X1	X1	X
es	X	X	X
French
fr_FR.UTF-8		X	X2
fr.ISO8859-15	X1	X1	X
fr	X	X	X
Italian
it_IT.UTF-8		X	X2
it.ISO8859-15	X1	X1	X
it	X	X	X
Swedish
sv_SV.UTF-8		X	X2
sv.ISO8859-15	X1	X1	X
sv	X	X	X
Korean
ko.UTF-8			X2
ko	X	X	X
Japanese
ja_JP.UTF-8		X	X2
ja	X	X	X
ja_JP.PCK	X	X	X
Simplified Chinese
zh.UTF-8			X2
zh	X	X	X
zh.GBK		X	X
Traditional Chinese
zh_TW.UTF-8			X2
zh_TW	X	X	X
zh_TW.BIG5		X	X

____________________________

1 The Euro currency symbol does not display on IA platforms in ISO8859-15 locales on Solaris 2.6 and Solaris 7.

2 An error message appears unless the following optional font packages are installed: SUNWi2of, SUNWi4of, SUNWi5of, SUNWi7of, SUNWi9of.

Installation

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.

The top level directory where the J2SE files are installed is determined by the BASEDIR parameter in the admin file (see admin(4) and pkgadd(1) for details). This release uses /usr as the default BASEDIR value and stores files under the directory $BASEDIR/j2se . For example:

$BASEDIR/j2se/bin/java

Running with Multiple Versions

The /usr/java symbolic link is used to define the default Java environment on a Solaris system when more than one Java environment is installed. Currently, JDK 1.1 is installed in /usr/java1.1, J2SE 1.2.2 is installed in /usr/java1.2, and J2SE 1.3.0 is installed in /usr/j2se.

Prior to the Solaris 8 release, the /usr/java symbolic link pointed to /usr/java1.1 if both JDK 1.1 and J2SE 1.2.2 were installed. Starting with the Solaris 8 release, the /usr/java symbolic link points to /usr/java1.2 by default if both JDK 1.1 and J2SE 1.2.2 are installed.

Since there are symbolic links in /usr/bin (also known as /bin) that use /usr/java (for example, /usr/bin/java refers to /usr/java/bin/java), this /usr/java link can change the default Java installation seen by most users. Many Java applications run on any of J2SE 1.3.0, J2SE 1.2.2, or JDK 1.1, but users and applications might want to be selective about which Java installation they use.

Java users that want to use JDK 1.1 should add /usr/java1.1/bin to their PATH settings before /usr/bin. Java users that want to use J2SE 1.3.0 should add /usr/j2se/bin to their PATH settings before /usr/bin. Also, depending on the situation, you might need to make changes to other environment variables such as CLASSPATH, LD_LIBRARY_PATH, or JAVA_HOME, although none of these environment variables are required.

It is possible for root users to make J2SE 1.3.0 the default Java platform by modifying the /usr/java symbolic link to point to /usr/j2se. However, changing the symbolic link in this manner may cause problems for some Java applications that are expecting to use earlier versions of the Java platform. See the online compatibility documentation for incompatibilities between J2SE 1.2 and J2SE 1.3.

http://java.sun.com/j2se/1.3/compatibility.html

Troubleshooting

Non-default Installation

# An unexpected exception has been detected in native code outside the VM. # Program counter= ... # # Problematic Thread: prio=... tid=... nid=... #

If these variables are consistent, and you are running native code through JNI, check the JNI documentation:

http://java.sun.com/j2se/1.3/docs/guide/jni.

Location of libjvm.so files

jre/lib/sparc/client/libjvm.so (on SPARC)
jre/lib/i386/client/libjvm.so (on x86)

jre/lib/sparc/server/libjvm.so (on SPARC)
jre/lib/i386/server/libjvm.so (on x86)

See also the section on the Java Native Interface for information about setting LD_LIBRARY_PATH.

The Exact VM and Classic VM are no longer part of the Java 2 platform, and legacy code that uses the Invocation API to launch an application based on old paths to the Exact or Classic VMs will not work.

libthread panic or I/O exception

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

Solaris patch installation

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 Solaris patches to run this version of the Java runtime environment.

NOTE: It is essential that you install the appropriate Solaris patches in order for the SDK to function properly. The README.sparc or README.i386 contain lists of recommended fonts. For the most up-to-date list of required patches, check the web site at

http://java.sun.com/j2se/1.3/install-solaris-patches.html

If there is a libthread patch required for your version of Solaris software, it should always be installed after the other appropriate patches in the readme .

Out of Memory/Internal Error for Applications Embedding the Java virtual machine

To avoid this problem, link libthread before libjvm or set LD_PRELOAD to include libthread.so. In csh , type:

setenv LD_PRELOAD libthread.so 

LD_PRELOAD=libthread.so export LD_PRELOAD 

NOTE: For more information, see the ld.so.1(1) man page .