Release Notes Java 2 SDK, Standard Edition Version 1.4.1

Contents

Overview
Java Plug-in Technology
AWT
Java 2D Technology
Swing
Security
CORBA, Java IDL, and Java RMI-IIOP
Virtual Machines
New I/O (NIO) APIs
Java Naming and Directory Interface API
Java Media Framework Bug Affecting Java Sound
Comformance on Solaris with OpenWindows
Platform Time Zone Detection on Microsoft Windows
Applet Notes
Windows XP with Samba Mounted Drives
Linux Notes
Sun ONE Studio (formerly Forte for Java) and NetBeans
Tools and Utilities
Notes on Japanese Locale
Serialization
Solaris 2.6 Operating Environment Not Supported
Floating-Point Exceptions

The Java 2 SDK, Standard Edition, v1.4.1 is an upgrade release of the Java platform containing new features and enhancements in many functional areas. This release has version number 1.4.1-b21. To determine the version number of your J2SE software, use the following command:

java -version

Refer to the following links for more details:

Changes in Java 2 SDK 1.4.1

Bug Fixes in the Initial 1.4.1 Release (1.4.1/fixedbugs/index.html)

Bug Fixes in Subsequent 1.4.1 Update Release Versions

Compatibility between J2SDK 1.4.1 and Previous Releases

The notes in the following sections describe known bugs, workarounds, and other important issues to be aware of in this release.

Using Java Plug-in 1.4.1 in conjunction with Netscape ^TM 6.x browsers can cause erratic behavior, including closure of the browser window, for applets that invoke applet functions from Javascript. This problem is due to a bug in the browser, and you can avoid this problem by using Netscape 7.0 browsers.

A Java Plug-in cache problem exists that can cause an "java.lang.IllegalStateException: zip file closed" exception to occur. See Applet Notes.

The following notes pertain to AWT functionality in this release.

• On Windows 2000 and Windows XP, a TextArea (1.4.1/docs/api/java/awt/TextArea.html) will sometimes display only a vertical scrollbar, but not a horizontal scrollbar, even though the SCROLLBARS_BOTH field is set to "true". For a discussion of this problem, see the bug report for 4648702.

• If you have installed English Visual C++ 6.0 onto a machine that also has an Asian edition of Windows NT installed, you may encounter strange artifacts when rendering Asian text in a TextArea component. You may also see this problem if you have installed Microsoft Exchange or Microsoft Office 97 onto a machine running an Asian Windows NT 4.0. Although this problem was reported on the Japanese version of Windows NT, it will probably occur on other non-Latin versions of NT as well, such as Chinese or Korean.

  The problem is caused when the installation of those programs replaces the Asian Riched32.dll file with the English version of the same file. The problem can be corrected by replacing Riched32.dll with the Asian version.

On Microsoft Windows platforms, Java 2D functionality in J2SE 1.4.1 is implemented using DirectDraw and Direct3D for various offscreen rendering functions. Bugs in some Direct3D drivers can cause a system crash (blue screen). If you encounter this problem while running a graphical application, consider updating your driver (the latest drivers for a particular card are usually available on the website of your computer, video card, or video chip manufacturer, such as http://www.nvidia.com or http://www.atitech.com).

One example of a known problem is that using Direct3D on some small subset of Windows 2000 systems has been known to cause a system crash. You can also try launching your application with the following command-line flag set:

-Dsun.java2d.d3d=false

This forcibly disables our use of Direct3D and avoids any Direct3D-specific problems.

You can also try the following flag:

-Dsun.java2d.ddoffscreen=false

This flag disables our use of DirectDraw and Direct3D for offscreen images (such as the Swing back buffer).

If problems persists, try launching the application with this flag:

-Dsun.java2d.noddraw=true

This flag disables our use of DirectDraw and Direct3D completely and thus avoids any problems you may be seeing associated with our use of those APIs and their respective drivers on your system.

For more information about performance-related flags, see Flags for Controlling Performance and Quality, a section in the High Performance Graphics white paper (also available in PDF format).

• On newer Microsoft Windows platforms, Windows 2000 and Windows XP, mnemonics are normally hidden. On these platforms mnemonics can be made visible by pressing the alt key. When using Swing's Windows Look and Feel pressing alt may not make the mnemonics visible. You can workaround this with the following code:

  frame.getRootPane().getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW).put(
       KeyStroke.getKeyStroke(KeyEvent.VK_ALT, Event.ALT_MASK, false),
       "repaint");
  

  See bug report 4736093 for more information.

• The text Components no longer register key bindings using a Keymap. They have been migrated completely to a combination of InputMap and ActionMap. You can continue to use Keymap, but Swing will no longer register bindings in a Keymap. See bug report 4682626.

The following notes pertain to Security functionality in this release.

• On Unix platforms, the Sun SecureRandom implementation uses /dev/random to seed itself, if available. This approach can improve the startup time of cryptographic applications considerably, but can also cause delays if the kernel entropy pool is empty. Solaris 8 users experiencing this problem should ensure that they have patch 112438-01 (SPARC) or 112439-01 (x86) installed. It is also possible to edit the <java.home>/lib/security/java.security file to specify a different URL for seeding. Note that if the URL cannot be opened, the implementation defaults to the pure-Java seeding implementation.
• A bug in Sun's JSSE v1.0, v1.0.1, and v1.0.2 caused SSL_DHE_DSS_* cipher suites to encode DSA signatures incorrectly when those signatures were used as part of a DSA server key exchange message.
  
  An interoperability system property controls which behavior is active. This property was introduced in Sun's JSSE 1.0.2 :

com.sun.net.ssl.dhKeyExchangeFix
true	Use the correct behavior. (Interoperable with JSSE 1.0.3)
false	Use the "broken" behavior. (Interoperable with JSSE 1.0, 1.0.1, and 1.0.2)

For backwards compatibility, the SunJSSE provider in J2SDK 1.4 and above also has this property; its default value is true.

Release	Default Behavior	Switch
J2SDK 1.4.0/above	correct	true
JSSE 1.0.3	correct	true
JSSE 1.0.2	broken	false
JSSE 1.0.1	broken	N/A
JSSE 1.0	broken	N/A

• When exchanging an RSA-based PreMasterSecret, RFC 2246-TLSv1 specifies that the PreMasterSecret message should contain the latest (newest) version supported by the client. Some SSL implementations send the current session's version number (incorrect), while others send the correct message. Most servers accept messages of either type.
  
  These differences are only an issue if the client requests a particular protocol version that the server doesn't support, and as a result the server requests a lower version number and then only accepts one message type (either correct or incorrect).
  
  Servers using the SunJSSE in J2SDK 1.4.1 accept messages of either type.
  
  Servers using the SunJSSE in J2SDK 1.4.0's JDK accept the incorrect message type only. (Currently most popular Web browsers send the incorrect message.)
  
  Clients using the SunJSSE in J2SDK 1.4.1 can control which message type is active by using a system property:

com.sun.net.ssl.rsaPreMasterSecretFix
true	Use the correct RFC 2246 behavior
false	Use the incorrect behavior.

Given that most servers accept either message type, for interoperability with servers using SunJSSE in J2SDK 1.4.0 the current default is false:

Release	Default Behavior	Switch
J2SDK 1.4.1	incorrect	false
J2SDK 1.4.0	incorrect	N/A

Limitations for Java IDL and Java RMI-IIOP - For information on limitations regarding the use of Java IDL and Java RMI-IIOP, please read the document (1.4.1/docs/guide/idl/limitations.html) Limitations for Java IDL and Java RMI-IIOP.

The following notes pertain to the Java HotSpot virtual machines (VMs) in this release.

• Beginning with J2SE 1.4.1, the Java HotSpot Server VM does not support operation on chips with SPARC^® v8 architecture. The SPARCstation^® family of processors, includng the SPARCstation Workstation, SPARCstation Classic, SPARCstation 2, SPARCstation 4, SPARCstation 5, SPARCstation 10, SPARCstation 20, and SPARCstation^® Voyager processors, are affected by this change . The Java HotSpot Client VM does support operation on SPARC v8 platforms. See the (1.4.1/docs/guide/vm/index.html)Java HotSpot VM documentation for information on the Server VM and Client VM.

  UltraSPARC^® processors and are not affected by this change.

• As part of its internal consistency checking, the VM verifies that addresses returned by VirtualAlloc are reasonable. The VM running under the 32-bit Windows XP x86 OS rejects addresses for which bits 24-31 are all set to one, while under 64-bit XP ia64 the VM rejects those for which bits 24-63 are all set to one. This is a reasonable check when running under 32-bit Windows XP, which reserves to itself addresses with bit 31 set to one. Such is not the case under 64-bit Windows XP, leading to a very rare assertion failure. This problem will be fixed in a future release.

• The Java HotSpot VM cannot expand its heap size if memory is completely allocated and no swap space is available. This can occur, for example, when several applications are running simultaneously. When this happens, the VM will exit after printing a message similar to the following.

    Exception java.lang.OutOfMemoryError: requested <size> bytes
  

  If you see this symptom, consider increasing the available swap space by allocating more of your disk for virtual memory and/or by limiting the number of applications you run simultaneously. You may also be able to avoid this problem by setting the command-line flags -Xmx and -Xms to the same value to prevent the VM from trying to expand the heap. Note that simply increasing the value of -Xmx will not help when no swap space is available.

  This issue is being tracked in bug 4697804.

The following notable NIO bugs have been fixed in 1.4.1:

• Asynchronous closing and interruption do not work on Linux (bug 4460583).
• Selector only supports 63 channels on the Microsoft Windows operating system (bug 4503092).

The following bug still exists in 1.4.1:

• Interruption of file-locking operations not completely implemented (bug 4460065).

For information about NIO, see the main (1.4.1/docs/guide/nio/index.html) and supplemental NIO documentation.

The following notes pertain to JNDI functionality.

• The "java.naming.provider.url" property is used by the JNDI/DNS service provider to configure how to communicate with DNS server(s). If this property has not been set or if its value specifies neither a hostname nor port, then on releases earlier than the Java 2 SDK, v 1.4.1, the hostname and port default to "localhost" and 53, respectively. Under the same circumstances on the Java 2 SDK, v 1.4.1, the DNS provider will attempt to determine and use the server(s) configured for the underlying platform (on Solaris or Linux, for example, the provider will read the /etc/resolv.conf file). If DNS has not been configured on the underlying platform, the hostname and port default to "localhost" and 53.

  This change affects applications that are deployed in an environment in which DNS has been configured in the underlying platform to use servers other than "localhost" and port 53, and at the same time expect "localhost" and port 53 to be used without specifying them explicitly. The affected applications will use a different DNS server than expected when migrating from Java 2 SDK v 1.4 to Java 2 SDK v 1.4.1. The workaround is for the application to explicitly specify "localhost" in the URL.

• The "java.naming.provider.url" property is used by the JNDI/LDAP service provider to configure how to communicate with the LDAP server. On releases earlier than the Java 2 SDK, v 1.4.1, the value of this property is a single LDAP URL string that specifies the hostname and port of the LDAP server, and the root distinguished name of the naming context to use. The syntax of the URL is specified by RFC 2255. On the Java 2 SDK, v 1.4.1, the value of this property is a list of space-separated LDAP URLs. The LDAP provider will attempt to use each URL in turn until it is able to create a successful connection using one of them and set the "java.naming.provider.url" property to the successful LDAP URL.

  This change does not affect applications that use a valid LDAP URL as specified in RFC 2255. This change affects only applications that assumed that a space character is valid in an LDAP URL and used such a URL as the value of the "java.naming.provider.url" property. According to RFC 2255, a space character in an LDAP URL must be encoded as the triplet "%20". On the Java 2 SDK v 1.4 and earlier releases, the LDAP provider will accept the space character as part of the URL. On the Java 2 SDK v 1.4.1, the provider will treat the space character as a separator between multiple LDAP URLs. The affected applications might experience "name not found" errors when migrating from Java 2 SDK v 1.4 to Java 2 SDK v 1.4.1. The workaround is for the application to replace each space character in the invalid URL with the triplet "%20".

• The "java.naming.provider.url" property is used by the JNDI/LDAP service provider to configure how to communicate with the LDAP server. Its value is one or more LDAP URLs. An LDAP URL can also be supplied as the name argument to methods in the initial context and be used to resolve LDAP referrals. In these situations, on the Java 2 SDK v 1.4.1, if neither a hostname nor port has been specified but a distinguished name has been specified in the URL (e.g., "ldap:///dc=example,dc=com"), the LDAP provider will use the distinguished name to determine and use the hostname and port of the LDAP server(s) configured in corresponding DNS SRV records, using the algorithm described in
  http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-07.txt

  If a connection is established using data from DNS, the provider will set the "java.naming.provider.url" property to an LDAP URL constructed using the selected hostname, port and distinguished name.

  If no such DNS records exist, the hostname and port default to "localhost" and 389, respectively.

  On systems earlier than the Java 2 SDK, v 1.4.1, unspecified hostname and port always default to "localhost" and 389, respectively; no attempt is made to use DNS SRV records.

  This change affects applications that are deployed in an environment in which DNS has been configured with SRV records to use LDAP servers other than "localhost" and port 389 and at the same time expect "localhost" and port 389 to be used without specifying them explicitly in an LDAP URL that contains a distinguished name . The affected applications will use a different LDAP server than expected when migrating from Java 2 SDK v 1.4 to Java 2 SDK v 1.4.1. The workaround is for the application to explicitly specify "localhost" in the LDAP URL.

Bug 4387291 in Java Media Framework (JMF) 2.1 and earlier versions prevents the output of sound when using Java 2 SDK 1.4.1. To avoid this problem, use JMF 2.1.1 (or later) in which this bug has been fixed.

When running the J2SE 1.4.1 platform on the Solaris operating environment, behavior in conformance with the Java 2 Platform specification is not guaranteed when using OpenWindows. In particular, some APIs related to handling focus, such as the Component.requestFocus() (1.4.1/docs/api/java/awt/Component.html#requestFocus()) method, fail when using OpenWindows. This problem is due to a bug in OpenWindows. See the bug description for 4505899 for more information.

This bug does not exist in the CDE window manager.

If you select a time zone that doesn't observe daylight saving time (e.g., Tokyo Standard Time) on installation of a Microsoft Windows operating system, that selection may turn off the global system setting "Automatically adjust clock for daylight saving changes." Under this setting, the Java runtime detects the platform time zone in the GMT offset format (e.g., "GMT+09:00"), not as a time zone ID (e.g., "Asia/Tokyo"). To fix this installation problem, take the following steps after the installation (unless you intend to turn off the setting):

1. Open Date/Time in Control Panel.
2. On the Time Zone tab, choose a time zone that observes daylight saving time (e.g., "(GMT-08:00) Pacific Time (US & Canada); Tijuana"), select the "Automatically adjust clock for daylight saving changes" check box, and press the Apply button.
3. Choose your time zone back and press the OK button.

The following notes pertain to running applets on the J2SE 1.4.1 platform.

• Invoking modal popup dialogs from an applet's stop or destroy methods is not recommended. Using modal popup dialogs inside these methods can result in problematic behavior, including NullPointerException, the dialog box not being displayed, the dialog box remaining alive even after applet is destroyed, or in the worst case, browser hang. This problem is being tracked as bug 4672707.

• Method java.applet.getDocumentBase() (1.4.1/docs/api/java/applet/Applet.html#getDocumentBase()) is supposed to return the absolute URL of the directory of the document containing the applet. Method java.applet.getCodeBase() (1.4.1/docs/api/java/applet/Applet.html#getCodeBase()) is supposed to return the URL of the applet itself. In the Java 2 SDK, the behavior of these two methods is reversed. This problem is being tracked as bug 4456393.

• When deploying an applet via Java Plug-in with cache enabled, if that applet is in a JAR file that contains multiple class files, and if one of those classes calls javax.crypto.Cipher.getInstance(), operations which require access to the same jar file fail with "java.lang.IllegalStateException: zip file closed" exception. There are three possible workarounds:
  • Turn the Java 1.4 plugin cache off.
  • Place the class file that calls Cipher.getInstance() into its own jar file and place the rest of the class files into another jar file -- that way you can create as many instances as needed. Example: <PARAM NAME = "archive" VALUE = "TestApplet.jar, Encrypt.jar"> where Encrypt.jar contains the class that calls Cipher.getInstance().
  • Install the JCE Unlimited Strength Jurisdiction Policy Files, if you live in an eligible country (which is most countries). However, this is a client-side workaround that may not be viable for large-scale applet deployment.
  This problem is being tracked as bug 4740901.

When using Windows XP (either 32 and 64-bit version) with Samba mounted drives, if the FileOutputStream(name) constructor is called and an empty directory with the same name exists, the directory will be deleted. This is not a bug in the J2SE platform, but it is being tracked as bug report 4693219.

The following notes apply to use of this release on Linux platforms.

• The following problems can occur intermittently on multi-processor systems. No workaround exists for these problems; the Linux system must be upgraded to eliminate them. No patch is currently available for Linux on 64-bit Itanium systems. However, using only one processor on an Itanium system will avoid these problems.
  • A glibc 2.2 bug in versions 2.2.4 and earlier can cause the virtual machine to hang on exit when there is only one remaining active thread. This problem can affect Linux platforms such as Red Hat 7.0, 7.1, and 7.2 that have glibc versions 2.2 to 2.2.4. The problem is fixed in glibc 2.2.5. See bug report 4656697.
  • The Linux 2.4 SMP kernel sometimes issues duplicate PIDs, which can lead to anything from network errors to crashes. This problem is fixed in kernel 2.4.18. See bug reports 4650839 and 4682743.
  • An apparent bug in the Linux 2.4.9 kernel can sometimes cause an application running on the Java platform to occupy essentially all CPU resources, causing the application to hang. This problem is being tracked in bug report 4701394.

• Behavior in comformance with the API specification is not guaranteed while running as superuser on any version of Linux whose kernel was compiled with the CONFIG_IP_TRANSPARENT_PROXY option. The default kernel shipped with the RedHat 6.2 distribution is compiled with this option. To avoid incompatibilities associated with this problem, either do not use the Java platform while superuser or else upgrade to a Linux operating system whose kernel was not compiled with the CONFIG_IP_TRANSPARENT_PROXY option. Red Hat 7.1 ships with the version 2.4 kernel which does not have this problem.

• Because Red Hat 7.* on Japanese does not have a TrueType font for JIS X 0201 by default, the Japanese font properties file, font.properties.ja, does not include any definition for JIS X 0201. The workaround is to install a TrueType JIS X 0201 font and modify the font.properties.ja file accordingly.

• On 64-bit Itanium Linux platforms, Japanese characters may not display correctly with the drawString method. See bug report 4704500.

See also the Known Problems section of the Linux Installation Notes.

Sun ONE Studio 3.0, Community Edition and NetBeans 3.2.1 will work in conjunction with the Java 2 SDK 1.4.1. However, Forte for Java 2.0 and NetBeans 3.2 do not work with Java 2 SDK 1.4.1.

Tools and Utilities

The following notes pertain to the tools and utilities in this release.

• Javac tool - Changes are listed at Enhancements and Changes.

• Javadoc tool - The following list includes both major outstanding 1.4.1 bugs and all known regressions (features that work in 1.3.x but are broken in 1.4.0 and 1.4.1). New features and bug fixes are documented at (1.4.1/docs/tooldocs/javadoc/whatsnew-1.4.1.html)What's New in Javadoc 1.4.1. For all bugs, see What Bugs are in Javadoc?
  • Regression: Links to external methods using -link or -linkoffline are not generated. No known workaround. Bug 4615751

  • Regression: Links to "Serialized Form" mistakenly no longer contain anchors to classes. Bug 4521661

  • Regression: Doesn't generate cross references between classes/interfaces. Bug 4628281

  • Regression: @link does not link to external -link'd classes Bug 4652655

  • Taglet does not allow use of inline tags. Bug 4654636

• 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, available for download from http://www.research.avayalabs.com/project/libsafe/.

Because Red Hat 7.* on Japanese does not have a TrueType font for JIS X 0201 by default, the Japanese font properties file, font.properties.ja, does not include any definition for JIS X 0201. The workaround is to install a TrueType JIS X 0201 font and modify the font.properties.ja file accordingly.

Instances of java.lang.Throwable and subclasses (including all exceptions) serialized by Java 2 SDK 1.4.0 or 1.4.1 cannot be deserialized by the Microsoft Windows JDK 1.1 implementation used by Internet Explorer browsers. Deserialization of such objects results in a ClassNotFoundException being thrown. This issue is described in bug report 4634165.

The Solaris 2.6 Operating Environment is not a supported platform for J2SE 1.4.1. One ramification of this is that support for Motif 1.2 in the J2SE 1.4.1 platform has been dropped.

A processor's floating-point unit (FPU) usually has a control word which affects its behavior on certain floating-point events, such as overflow (generating a result too large to represent as a finite value), underflow (generating an especially small result), and divide by zero (e.g. 1.0/0.0). Java precisely defines the outcome of these events; Java uses the default returns values from the IEEE 754 floating-point standard. For example, overflow and divide by zero generate either positive or negative infinity. Other language environments may allow different outcomes from such events; for example, instead of returning an infinity, dividing by zero could generate an exception and stop the program. If a program with different floating-point semantics is called from a Java program, the called program may alter the FPU control word to implement its own semantics. However, such a called program should restore the FPU control word to its previous value. If the called program does not restore an altered FPU control word, and Java program could terminate with an improper floating-point exception after the external program exited. However, some commercial dlls are known not to restore the FPU control word to its previous value when they return to the calling thread. If your program terminates with a floating-point exception, you should consider this possibility as the source of the problem.

See bug 4644270 as an example of this issue.