Cloud Account Sign in to Cloud Sign Up for Free Cloud Tier

Oracle Account

Release Notes Java 2 SDK, Standard Edition Version 1.3.1

Overview

The Java 2 SDK, Standard Edition, version 1.3.1 (J2SDK 1.3.1) is a maintenance release containing fixes for bugs identified in previous versions. For more details on these fixes, see:

Java Virtual Machine

The following notes pertain to the Java virtual machine.

For Linux users - The newer glibc-2.2.x libraries cannot correctly handle initial thread stack sizes larger than 6 MB. This can cause a segmentation fault on come Linux platforms that use the newer libraries. Such platforms include Red Hat 7.0, Mandrake 8.0, SuSe 7.2, and Debian 2.2. The problem will not occur on Linux platforms that are using glibc-2.1.x such as Red Hat 6.1 and 6.2. It will also not affect Red Hat 7.1 because it uses a different thread stack layout. This problem is being tracked as bug 4466587.

Workaround - Use " ulimit -s 2048" in bash shell or " limit stacksize 2048" in tcsh to limit the initial thread stack to 2 MB.

A limitation in the 1.x versions of the libsafe library, available from Avaya Labs Research, can cause Java 2 SDK tools to fail with the message "Invalid initial heap size: -Xms8m." Trying to use the java application launcher by setting the -Xms option explicitly will fail also. This limitation is fixed in the most recent release of the libsafe library, version 2.0.
On Linux platforms, a thread that is waiting on an I/O operation will not wake up if a file involved in the I/O operation is closed. This problem is being tracked as bug 4344135. To avoid this problem, set the J2SE_PREEMPTCLOSE environment variable to 1.




J2SE_PREEMPTCLOSE=1
export J2SE_PREEMPTCLOSE

Bug 4323062: Any Windows NT Service embedding Java VM aborts when user logs out

This bug has been fixed in J2SDK 1.3.1. In order to enable the fix, the -Xrs command-line option must be passed to the JVM. The additional command line argument is necessary because the fix necessarily disables the J2SDK 1.3 shutdown hooks mechanism and forbids the use of the sun.misc.Signal class. For more background, please see at least the last section of the evaluation on the Bug Parade:

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=432306

A JNI bug can cause the JVM to crash after a program has finished, with an error message similar to the following.



Another exception has been detected while
we were handling last error.

Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC                = 0x0x41621c7a
SIGNAL            = 11
FUNCTION NAME     = (N/A)
LIBRARY NAME      = (N/A)
Please check ERROR REPORT FILE for 
further information, if there is any. 
Good bye.

This problem is seen mostly on Linux Red Hat 7.1 SMP, though theoretically it could appear on Microsoft Windows and Solaris platforms also.

Workaround - Add an explicit exit call at the end of the application's main method: Runtime.getRuntime().exit(0)

Running code on the Java platform over automounted NFS on Red Hat 7.1 can result in frequent crashes in dlopen() on Red Hat. This problem is apparently due to the NFS automounter, and the problem will disappear if you explicitly mount the directory with mount -t nfs.

Font Properties

This release has the following problems with respect to font properties.

When using Red Hat Linux versions other than 6.1, the font.properties file may fail to display some Symbol/Dingbats characters properly on some AWT components. To correct this, use this revised font.properties file to replace the one at <JAVA_HOME>/jre/lib/.
Due to bug 4419794, font properties can throw warning messages for UTF-8 locales on Solaris 8 (Intel Architecture). If you need to use UTF-8 locales on Solaris 8 on Intel hardware, update your system to Solaris 8 Update Release 4 in which this problem has been fixed.

Xserver Bug on Solaris

A Solaris Xserver bug can cause a system crash when an application written in the Java programming language references fonts. This problem is described in bug report 4391019. The following Solaris patches for Xserver will be available by mid-June 2001, and they may help to reduce this problem.

For Solaris 2.6: 105633-55 (Sparc) 106248-41 (Intel)

For Solaris 7: 108376-24 (Sparc) 108377-22 (Intel)

For Solaris 8: 108652-31 (Sparc) 108653-26 (Intel)

Check the SunSolve web site for availability of these patches.

RMI

The following are important changes to RMI (Remote Method Invocation) functionality in this release.

"accept" java.net.SocketPermission requirement for receiving remote calls

Due to a bug in previous J2SDK implementations, it was possible to export a remote object in a given access control context and then receive a remote call to that object over a given socket connection even if the access control context did not have "accept" java.netSocketPermission for the remote java.net.InetAddress and port of the socket connection.

This bug has been fixed; therefore, in some cases, code that exports remote objects might need to be granted more permissions that it did with previous implementations in order to function correctly.

As an example of how to grant such permissions using the default security policy file syntax, permission to accept socket connections from a host named terrier.east.sun.com can be expressed by the following permission entry (in the grant entry for the appropriate code source): <

permission java.net.SocketPermission "terrier.east.sun.com", "accept";

As described in the documentation for java.netSocketPermission , the host specification may begin with a wildcard "*"; therefore, permission to accept socket connections for any host can be expressed by the following permission entry in a given grant entry:

permission java.net.SocketPermission "*", "accept";

Unexported remote objects not getting garbage collected
ObjectOutputStream replacement table performance

In previous implementations, an ObjectOutputStream instance remembered replaced objects (that is, those objects which have been returned by a call to ObjectOutputStream.replaceObject or by a class-defined writeReplace method) in such a way that a linear search was used to determine whether or not an object had a replacement. Therefore, if the number of objects replaced in a given stream was large, the overhead of the search became prohibitively expensive for each new object serialized. This bug has been fixed so that the implementation now uses a more efficient algorithm for remembering for object replacements. This fix to the object serialization implementation also benefits the scalability of object replacement during RMI argument and return value marshalling.

CORBA, RMI-IIOP and Java IDL

The following comments pertain to CORBA, RMI-IIOP, and Java IDL functionality in this release.

The Sun ORB has not been tested for interoperability with ORBs from other vendors, and the Sun ORB is not guaranteed to work with other vendor's ORBs.
If a J2SDK 1.3.1 server first connects with a J2SDK 1.3 client, and then a J2SDK 1.3.1 client tries to send a Serializable instance which uses writeUTF or readUTF in its writeObject or readObject methods, respectively, a MARSHAL exception will occur. Similarly, if a J2SDK 1.3.1 server first connects with a J2SDK 1.3.1 client, and then a J2SDK 1.3 client tries to send an instance of the same type of class, a MARSHAL exception will occur. This problem is being tracked as bug 4434140.
Work around - Change the Serializable class to use writeObject and readObject instead of writeUTF and readUTF.
J2SDK 1.3 mapped writeUTF and readUTF calls to CORBA strings rather than wstrings. Thus, it was impossible to use these methods for sending Strings with characters whose values were greater than 8 bits. This is fixed in J2SDK 1.3.1, but if communicating with J2SDK 1.3, the same limitation will apply. This problem is being tracked as bug 4379597.

Work around - Use writeObject and readObject instead of writeUTF and readUTF. Both JDK 1.3.1 as well as J2SDK 1.3 map these to CORBA wstring calls when the method parameters are Strings.

The Java ORB shipped with J2SDK 1.3.1 contains fixes to support evolutionary changes to the serializable classes as specified by the Java Serialialization Specification.

Due to this support, the J2SDK 1.3.1 and future J2SDK releases can handle class evolution. For example, if a class V shipped in J2SDK 1.3.1 evolves in a future J2SDK release, an application client (sending/receiving class V) executing on J2SDK 1.3.1 will be able to interoperate with the server (receiving/sending evolved class V) executing on the future J2SDK release, and vice versa.

However, previous release J2SDK 1.3.0 has bugs that prevent class evolution. (See, for example, bug report 4365188 on the Java Developer Connection web site.) Therefore, there will be interoperability problems when J2SDK 1.3.1 tries to send any evolved classes to J2SDK 1.3.

When writing code in OMG IDL, do not use an interface name as the name of a module. Doing so runs the risk of getting inconsistent results when compiling with tools from different vendors, thereby jeopardizing the code's portability. For example, code containing the same names could be compiled with the IDL to Java compiler from Sun Microsystems and get one result. The same code compiled with another vendor's IDL to Java compiler could produce a different result.

Java 2D Technology

Bug 4178909 in the Java 2D libraries sometimes prevents applications from being displayed properly when running in 8-bit mode. This problem should only affect the first time that a application is run after either a reboot or setting the display mode to 8 bits.

There are also some bugs related to DirectDraw. If you run into a DirectDraw problem, you might consider turning off DirectDraw:

-Dsun.java2d.noddraw=true

Some display drivers will cause monitor images, including windows, to appear to re-sync or jump when DirectDraw is accessed. If you see this, check the manufacturer's web site for a newer driver that may cure the problem.

The Java platform does not support 16-color displays. If you see problems drawing graphics and GUI components on a 16-color display, try changing the color depth to 256 color mode or higher.

Drag and Drop

These notes pertain to Drag&Drop functionality in this release.

The following features are implemented and functional, but are not completely tested and are not supported for this release.
- Drag and Drop transfers of:
  - Platform native, and/or user defined, data types
  - Instances of arbitrary classes, loaded by distinct ClassLoader instances, within the same JVM*
  - Serialized Java Objects between JVMs (or ClassLoaders)
- Linking of RMI java.rmi.Remote sub-interfaces between JVMs
A change in Drag&Drop behavior was introduced in J2SE 1.3.1 as part of the fix for bug 4313374. In the new behavior, drag operations are blocked until any previous drag-and-drop operation is completed. Prior to J2SE 1.3.1, drag operations could be initiated even if another Drag&Drop operation was currently in progress.
A well-constructed application will call either
```
    DropTargetDropEvent.rejectDrop(), or both 
    DropTargetDropEvent.acceptDrop(int) and           
    DropTargetDropEvent.dropComplete(boolean) inside   
   DropTargetListener.drop(DropTargetDropEvent). 
```
This will terminate the current Drag&Drop operation before the Drag&Drop subsystem can recognize and initiate another. Therefore, this change in behavior should only affect incorrectly written applications.

Accessibility

AWT and Swing components have inner classes that implement the Java Accessibility API and provide accessibility support appropriate for the components. However, accessibility support for the following AWT classes is not completely implemented in this release:



java.awt.TextComponent
java.awt.Menu
java.awt.MenuItem
java.awt.List

Full accessibility support for all components will be implemented in a future release of the Java 2 platform.

AWT and Swing

The following comments pertain to AWT and Swing functionality in this release.

Bug 4504963 causes the cursor to respond erratically to mouse movements on Windows 2000 and Windows XP platforms that use non-default mouse speeds. To avoid this problem, use the Mouse control panel to set your mouse speed to the default value (a value in the middle of the available range).
A program which calls the static method Toolkit.getDefaultToolkit won't terminate and return the command prompt. This problem is being tracked by bug reports 4030718 and 4403762, which will be fixed in J2SDK 1.4.0 Beta.

Workaround - Call System.exit() when your application is finished.

The new Component.getListeners() method fails to return PropertyChangeListeners. If you've added a listener with addPropertyChangeListener(),

myComponent.getListeners(PropertyChangeListener.class)

will return an empty array.

Bug 4199374 concerns a focus management problem with JWindow objects. In particular, this bug prevents Component.requestFocus() from giving focus to components in a JWindow. This bug was fixed in update releases J2SDK 1.2.2_05 and J2SDK 1.3.0_02. However, it is not fixed in J2SDK 1.3.1.

JDBC

On Windows NT, the JDBC 2.0 bridge supports the ODBC 2.x and ODBC 3.x driver manager and drivers. The JDBC 2.0 bridge has been tested only with an ODBC 3.x driver manager and with both ODBC 2.x and 3.x drivers.

Merant recommends that the JDBC 2.0 bridge be used with version 3.5 or higher of Merant's DataDirect ODBC drivers.

Security

The following security-related issues pertain to this release.

The jarsigner utility can verify files signed by the Netscape SignTool 1.3 if the code-signing certificates are not self-signed. Note: One can get official Netscape code-signing certificates from VeriSign ^TM. Those certificates are issued by VeriSign. They are not self-signed.

The Netscape SignTool 1.3 does not put certificates in the signature file if the code-signing certificate is self-signed, and jarsigner cannot verify a signed JAR file if the signature file doesn't contain the signer's certificate. Note: The code-signing certificate generated by the SignTool 1.3 itself is just for tesing, and it is self-signed. It is a known issue that the jarsigner cannot verify a JAR file signed by the Netscape SignTool 1.3 if the code-signing certificate is a self-signed testing certificate.

In the Java 2 SDK, application classes are loaded by an actual ClassLoader instance. This makes it possible for application classes to use installed extensions and also separates the application class path, which is specified by the user, from the bootstrap class path, which is fixed and normally should not be modified by the user. The -Xbootclasspath option can be used to override the boostrap class path if necessary.

However, this means that in the Java 2 SDK, application classes no longer have all permissions by default. Instead, they are granted permissions based on the system's configured security policy. This may cause some applications that write their own security code based on the original security model in 1.0/1.1 to throw an exception and not start in the Java 2 SDK. A workaround is to run these applications with the oldjava application launcher, which is documented on the reference page for the java application launcher.

The following notes summarize issues related to security policies and signing.
- The default security policy implementation used by the Java 2 platform is specified by the policy.provider property in the Java security properties file, jre/lib/security/java.security. If you specify a non-default security policy implementation, you must put your new, non-default security properties class file on the bootclasspath. You can do so by using the -Xbootclasspath command-line option. See the Java application launcher reference page for information on this option. This will cause the policy file to be loaded by the bootstrap class loader. If the new default policy file is placed elsewhere, such as on the class path or in an extension, it will not be picked up and the default policy provided in sun.security.provider.PolicyFile will be used instead.
- Beginning with version 1.2.2, the Java 2 SDK uses a new class-loading mechanism. Under the new class loader, if any class file belonging to a package in a Jar file is signed, all class files belonging to the same package must have been signed by the same signers. It is no longer possible to use a Jar file in which some classes of a package are signed and others are unsigned or signed by a different signer. Jar files may still contain packages that are unsigned. However, if any packages contain signed classes, all class files of that package must be signed by the same signer. Existing Jar files that don't meet this criterion will not be usable with this version of the Java 2 Platform.
The keytool tool currently can import or print a Base64-encoded certificate from a file only if the file is terminated by a newline (linefeed). If there is no linefeed at the end of the certificate file and you try to import or print the certificate, you will get an "Unsupported encoding" CertificateException or a keytool error message such as "Failed to parse input" or "Input not an X.509 certificate."

If you get such a message or exception, perhaps the problem is a missing terminating linefeed. One reason this may occur is that sometimes a certificate reply from a Certificate Authority (in response to a Certificate Signing Request) does not contain a terminating linefeed.

In UNIX, you can determine whether or not a file has a terminating linefeed by executing the following command:

od -xc <certificate_name>

where <certificate_name> is the name of the file containing the certificate. For example, if the file is named mycert the command would be

od -xc mycert

If the resulting output contains a "\n" (without the quotes) at the very end, there is already a linefeed at the end. If not, you can add one.

If you are unsure whether or not the certificate file contains a terminating linefeed, you can simply add one per the following paragraph (having extras never hurts) and retry the -import or -printcert command. If the command now works, the problem was the missing linefeed. If you still get an error, there is a different problem with your certificate.

To add a linefeed to the end of a Base64-encoded certificate file, open the file in any text editor, place your cursor at the very end of the file, and add a linefeed (or carriage return linefeed), for example by simply pressing the Enter key on your keyboard.

Networking

This release has the following known bugs and limitations in the networking API:

On Windows 2000, datagram applications may receive an unexpected SocketException indicating that the socket is closed. This is related to new behaviour in Windows 2000 when the remote application is unavailable. A potential workaround is to close and re-create the DatagramSocket. This issue is being tracked as bug 4361783.
J2SDK 1.3.0 introduced a HTTP/1.1 client implementation. Web servers such as Apache return chunked enocded response to HTTP 1.1 clients, but the chunked encoding handling of J2SDK 1.3.0 and 1.3.1 don't stream the chunked response from the server. In practice, this means that methods such as java.net.URLConnection.getInputStream don't return until the server's response is finished. This problem is described in bug 4333920.

Workaround: For Apache, the workaround is to put the following in httpd.conf.

BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0

The HTML 4.0 specification recommends that non-ASCII characters in Uniform Resource Identifiers (URIs) should be encoded in one or more UTF-8 bytes. Many existing CGI scripts handle non-ASCII characters by using bytes from the encoding in which a document is received. However, classes URLEncoder and URLDecoder do not support either of these methods of handling non-ASCII characters in URIs. Instead, these classes substitute one or more bytes for the characters as defined in the underlying platform's default encoding. This is bug 4257115.
A call to method HttpURLConnection.getResponseCode on the client can cause the virtual machine to crash when there are extra CRs in the HTTP header field sent by a Win98 or WinNT server. This is bug 4258697.

Workaround: the stack overflow can be avoided by configuring the http server to send a HTTP 1.0 response. For Apache, this can be done by putting the following in httpd.conf.

BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0

If your application uses the networking classes, it may not run reliably under Winsock 1.1. If your networking application must support Windows 95, which includes Winsock 1.1, you will want users of your application to have Winsock 2.0. (Windows NT 4.0, Windows 2000, Windows ME and Windows 98 include Winsock 2.0.) You can download the Winsock 2.0 from this address:

Java Plug-in Component

The following notes pertain to the Java Plug-in component in this release.

Beginning with J2SE 1.3.1_01a, Java Plug-in supports <applet> tags for launching applets and for initiating autodownload of the JRE/Java Plug-in on Microsoft Windows platforms.
Bug 4406285 is fixed in Java Plug-in 1.3.1_01a and later versions. This bug caused heavy use of SSL from an applet to result in a large memory leak in Microsoft Internet Explorer browsers. However, memory leaks can still occur for applets that use https in Netscape Navigator 4.x and Netscape 6 browsers. We believe this problem is not related to bug 4406285 but is a different problem possibly caused by the Netscape browser's secure https connections.
On Linux platforms, mulitple copies of an applet cannot be printed from the web browser. The browser must be closed and restarted for each print after the first. This problem is being traced as bug number 4450194.
When installing an extension through the Java Plug-in component, a warning dialog box will appear alerting the user to the fact. If the user clicks the "Deny" button, however, the warning dialog box may sometimes nevertheless reappear, asking the user to approve or deny installation of the same extension. This bug will be fixed in a future release.
In version 1.3.0_01, signature verification changed to use the cert CA store comes with the Sun Java runtime environment instead of the store that comes with Microsoft Internet Explorer. This change was made because using the cert store in Internet Explorer doesn't work for applets running in Netscape web browsers. Additional error- handling code has been introduced in version 1.3.1 to deal with unverifiable signatures. See bug report 4424604.

Localization Notes

Documentation

The following comments pertain to documentation for this release.

Due to bug 4459595, the Serialized Form page in the API spec for this release contains some broken links to files for private and package-private classes.

Tools Cannot Convert Japanese PCK Strings on Solaris 2.6

An error occurs when using Japanese strings as arguments of the java command on Solaris 2.6 ja_JP.PCK locale. To workaround this problem, change line 89 /usr/java/bin/.java_wrapper from

exec $DEBUG_PROG "$prog" $opts "$@"

exec $DEBUG_PROG $prog $opts $@

Traditional Chinese Text Problems

The following problems with Traditional Chinese fonts are known exist for this release.

Microsoft Windows 95 for Traditional Chinese Version 2.0 does not contain the traditional Chinese fonts specified in the Java 2 SDK's font properties files. Using the Java 2 SDK or Java 2 Runtime Environment on that operating system will result in "font not found" warnings, and text may not display properly. This problem does not exist on the newer Microsoft Windows 95 for Traditional Chinese Version 2.0 Second Release, released in October 1996, which does contain the specified fonts.
In the Traditional Chinese environment on Microsoft Windows 95, Chinese characters do not display properly on Swing components. For more details on this problem, see bug report 4431319 on the Java Developer Connection web site.

Support for Windows 2000

In the English locale, version 1.3.1 of the Java 2 SDK is supported on Windows 2000 Professional, Windows 2000 Server, Window 2000 Advanced Server. The DataCenter edition of Windows 2000 is not supported. In non-English locales, only the Professional edition of Windows 2000 is supported. Known issues with Windows 2000 include:

Windows 2000 and multiple-monitor support - Multiple monitors are not yet fully functional on the Windows 2000 platform. In particular, 256 color mode only behaves properly if all monitors are set to 256 color mode. 16-bit (or higher) color mode is highly recommended.
If you see the following error message on Windows 2000 during installation
config.nt. The system file is not suitable for running MS-DOS
and Microsoft Windows Applications.
it indicates a problem with the %SystemRoot%\System32\COMMAND.COM file that has been seen on some installations of Windows 2000. If you encounter this error message when you try to launch the installer, consult the Microsoft web site at
http://support.microsoft.com/support/kb/articles/Q142/2/71.asp
for information about resolving the problem.
Process hang - An application may hang because of a deadlock in Ntdll on Microsoft Windows 2000 Professional, Server, and Advanced Server operating systems. This problem may occur, for example, in applications that use input and output streams of java.lang.Process objects. See the Microsoft Support Services web site for more information, including a fix:

http://support.microsoft.com/support/kb/articles/Q271/1/82.ASP

Installation on Windows NT

When you install version 1.3.1 of the Java Runtime Environment, the ActiveX Control file at C:\Winnt\Downloaded Program Files\Java Runtime Environment 1.3.1 will have a status of "Damaged." This is merely a cosmetic issue, and the "Damaged" status should have no adverse affect in any situation.

Nevertheless, there is a workaround if for some reason you cannot have a status of damaged. Go to "Start -> Run" and type in "regedit". From the regedit windows, navigate to the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution Units\8AD9C840-044E-11D1-B3E9-00805F499D93\DownloadInformation". Double-click on the INF string and delete the highlighted string under "Value data". The ActiveX Control file will have a status of "Installed."