Print-friendly Version

Release Notes JavaTM 2 Platform Standard Edition Development Kit 5.0 (JDK 5.0)

Introduction

OS & Hardware Platforms

Linux Notes

Virtual Machine

HotSpot VMs

Core Libraries

New I/O (NIO)

Security

JAXP

Platform Time Zone Detection on Microsoft Windows

Serialization

Floating-Point Exceptions

Java Native Interface

Java Management Extensions Technology

Integration Libraries

RMI

JDBC

User Interface

Java Sound Technology

Java 2D Technology

Fonts for Japanese Locale

AWT

Swing

Deployment

General Deployment

Java Plug-in

Java Update

Server VM

Tools and Tool Architecture

Java Compiler (javac)

Java Application Launcher (java)

java.lang.instrument and Java Virtual Machine Tool Interface (JVM TI)

Java Platform Debugger Architecture (JPDA)

Java Virtual Machine Profiler Interface (JVMPI)

Java Virtual Machine Debug Interface (JVMDI)

J2SE Monitoring and Managment Console (jconsole)

Javadoc Tool

The Java 2 Platform Standard Edition Development Kit 5.0 (JDK 5.0) is a feature release of the Java platform. It contains new features and enhancements in many functional areas.

This document summarizes known bugs, workarounds, and other important issues to be aware of in this release.

For further information, refer to the following links:

• New Features in the J2SE 5.0 Platform
• Bug Fixes in the Initial 5.0 Release
• Update Release Notes (Bugs Fixed in Update Releases)
• J2SE 5.0 Compatibility Previous Releases
• Java Community Process Review for J2SE 5.0 API Specification

To determine the version number of your J2SE software, use the following command:

java -version

For platform-dependent issues and bugs in particular J2SE technologies, search this page for the platform name ("Windows", "Linux", or "Solaris^TM").

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

• Linux kernels for Itanium prior to 2.4.20 have serious virtual memory bugs. These early kernels are the standard kernels that come with RedHat for Itanium. Java applications running on these kernels, especially on multi-processor machines, will likely experience random segment faults and in general will be unreliable. Please verify that you have the 2.4.20 kernel or a later one installed by using the 'uname -a' command. You can obtain an updated kernel for RedHat Advanced Server from either HP or RedHat.

• 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.
  • 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.
  • Tomcat sometimes hangs on RedHat 9. See bug report 4970650.

• Because several Red Hat Linux versions do not have a TrueType font for JIS X 0201 by default, the font configuration files for these versions do not include any definition for JIS X 0201. The workaround is to install a TrueType JIS X 0201 font into the J2RE's lib/fonts/fallback directory.

• Java support for the GNOME desktop and the association for JAR and JNLP files can be incorrectly removed if an older non-FCS RPM is removed after a new RPM has been installed. To avoid this problem, uninstall old non-FCS versions of 5.0 before installing newer versions. If you are already experiencing this problem you will need to uninstall all versions of the Java 5.0 RPM, and then re-install the newest version. (Note: this problem does not effect how the JRE works from the command prompt.) See bug report 5063669.

• Some files may not be deleted after removing all Java RPM versions from 1.4.2 and higher. These files are used to associate the Java JAR and JNLP file extensions with the current JRE. If you have uninstalled all versions of the Java RPM from 1.4.2 and higher, it is safe to remove these files. See bug report 5063681 for more details.

See also the Troubleshooting section of the Linux Installation Notes.

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

• The -Xincgc option now invokes the concurrent garbage collector instead of the train garbage collector. The concurrent garbage collector is a low-pause garbage collector that generally provides better performance than the train garbage collector. The train garbage collector will not be supported in 1.5 (now known as 5) and beyond. For issues regarding garbage collection options, please use your usual support or feedback channels. Details on garbage collection tuning are available at Tuning Garbage Collection with the 5.0 Java^TM Virtual Machine .

• 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. UltraSPARC^® processors are not affected by this change. The Java HotSpot Client VM does support operation on both SPARC v8 and v9 platforms. See the Java HotSpot VM documentation for information on the server VM and client VM.

• 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. Out of swap space?
  

  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 can also decrease your usage of memory by reducing the value of the -Xmx flag, which limits the size of the Java object heap.

  This issue is being tracked in bug 4697804.

• The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow.

• Tomcat hangs after 24 hours (1310 iterations) on Solaris with both -client and -client -Xcomp flags. This problem is fixed in Tomcat/Apache versions 4.1.30 and 5.0.17.

• The following bug still exists in 5.0: Interruption of file-locking operations not completely implemented (bug 4460065).

• In J2SE 1.4.2. both ISO-2022-CN-CNS and ISO-2022-CN-GB encoding support have been removed from the java.nio.charset API. It is still possible to use java.io or java.lang.String APIs to encode an input stream or String into these target encodings. J2SE 1.4.1 previewed a limited (but incomplete) ISO-2022-CN-* java.nio charset support. The limitations included the inability to perform round-trip conversion, and specifically the existence of bug 4737614 "sun.nio.cs.ext.ISO2022_CN_CNS.newDecoder() returns null".

For information about NIO, see the NIO documentation.

The following notes pertain to issues with Security functionality in this release.

• Public key certificates may be validated using an OCSP service. However, the location of the OCSP service must be specified explicitly by setting the ocsp.responderURL security property. A certificate's Authority Information Access extension is not examined.

• The jarsigner tool in version 5 supports the option of signature timestamping when signing a JAR file. However, JRE versions prior to version 5 fail to recognize such timestamps and will view the JAR file as unsigned. This forward compatibility problem is currently being corrected in the maintenance releases to versions 1.3.1 and 1.4.2.

• 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 JDK 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, 1.4.2, or JDK 5.0 (1.5.0) accept messages of either type.
  
  Servers using the SunJSSE in J2SDK 1.4.0's JDK accepts the incorrect message type only. (Currently most popular Web browsers send the incorrect message.)
  
  Clients using the SunJSSE in J2SDK 1.4.1 or 1.4.2 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, 1.4.2, and JDK 5.0 (1.5.0)	incorrect	false
J2SDK 1.4.0	incorrect	N/A

See JAXP Release Notes for known bugs and issues in this release.

If you select a time zone that doesn't observe daylight saving time (e.g., Tokyo Standard Time) on an 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.

For information on changes to Serialization functionality for this release, see Serialization Changes in J2SE 5

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.

Java Native Interface

The Java Native Interface specification has been unified into a single document. In previous releases, the 1.2 and 1.4 enhancements were separated out from the 1.1 specification. The JNI spec also incorporates clarifications to standard UTF-8 encoding and "Java modified UTF-8" encoding. (See RFE 4915107.)

Java Management Extensions (JMX) Technology

Java Management Extensions (JMX^TM) technology was added to the J2SE platform in version 5.0. Details of the JMX API that is included in J2SE 5.0 can be found in the JMX documentation.

For information on changes to RMI functionality for this release, see RMI Changes in J2SE 5

Java Database Connectivity (JDBC)

For 5.0, the JDBC ODBC bridge is not supported for AMD-64 processors on any operating system, as ODBC drivers are not available.

• A known bug causes the new Sequencer loop feature to fail if the end point is set to -1.
  A workaround is to use:
  sequencer.setLoopEndPoint(sequencer.getTickLength());
  This bug will be fixed for the final 5.0 release. (See 4967587.)

• The equals() method in AudioFileFormat.Type and AudioFormat.Encoding now compares the name, and not the class instance. Applications that compare Encodings or Types with "==" are advised to use the equals() method instead. (See RFE 4925483.)

• MidiSystem.getReceiver() and MidiSystem.getTransmitter() were modified to preferably return an external MIDI port's Receiver/Transmitter. Only if no external port is installed, a Synthesizer or Sequencer instance will be returned. (See RFE 4934509.)

• MidiSystem.getSequencer() maintains backwards compatibility by returning a Sequencer object which is connected to the default Synthesizer. This behavior can be changed in 3 ways:
  1. Set the default Synthesizer in the sound.properties file. (See RFE 4776511.)
  2. To unconnect the Sequencer from the default Synthesizer, get a list of Transmitters from the Sequencer, and close them all. (See RFE 4931387.)
  3. Use the new method MidiSystem.getSequencer(boolean) with parameter false. (See RFE 4931400.)

• Due to the new sequencer implementation, the default Sequencer cannot be cast to a Synthesizer anymore. (See RFE 4773012.)

On Microsoft Windows platforms, Java 2D functionality in J2SE 1.4.1 and beyond is implemented using DirectDraw and Direct3D for various offscreen rendering functions. Bugs in some Direct3D drivers have been known to cause problems in previous releases. If you encounter rendering or crashing problems 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.

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.

Fonts for Japanese Locale

• Because several Red Hat Linux versions do not have a TrueType font for JIS X 0201 by default, the font configuration files for these versions do not include any definition for JIS X 0201. The workaround is to install a TrueType JIS X 0201 font into the J2RE's lib/fonts/fallback directory.

The following notes pertain to AWT functionality in this release.

• Depending on the system setup, always-on-top windows (or frames or dialogs) may not be supported. They are supported on Microsoft Windows, and on Linux and Solaris running GNOME2/Metacity, as well as Linux running KDE/kwin. They are not supported on Solaris running CDE/dtwm. It is possible that always-on-top window will not work on Linux and Solaris running session and window managers not specified above.
  
  See bug report 4632143 for more information.
• We recommend using the latest build of Metacity (which is currently 2.6.2). There were some bugs that occurred with versions prior to 2.4.34 (problems with programmatic iconification, and non-resizable frames, for example) that have since been fixed.
• There were several focus-related bugs noticeable when running applets in Mozilla in release J2SE 1.4.2 and earlier. The complete list can be found in the detailed release notes. One such bug, 4806274, occurs when calling requestFocus to set the focus on a component — such as setting the focus on a text field when starting up an applet — this may not work when running Netscape 7 on Solaris. In order to fix these problems, release J2SE 5 should run with an XEmbed-enabled version of Mozilla, such as Mozilla v1.5 or higher for Linux. On Solaris, Sun Mozilla at least version 1.4 or higher is required. Using this release with an older version of Mozilla or with Netscape is not sufficient.
• Specifying the positioning of a window (or frame) with a 0,0 location can be achieved by setting the java.awt.Window.locationByPlatform property to true. When the locationByPlatform property is true, and a new window is created with a 0,0 location, the underlying window manager tiles the window according to its own logic. Otherwise, AWT won't know whether the window was put at 0,0 intentionally or was just unspecified and the window will be placed at the upper-left-hand corner of the screen.
  
  See bug report 4102292 for more information.
• 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.

See the AWT release notes for more information.

The following note pertains to Swing functionality in this release.

• In release 5, the Java look and feel has changed. The new look and feel, which is automatically loaded, is called Ocean. Ocean maintains the widget size used by the previous default look and feel — Metal. Only the look and a small portion of the feel has changed. The Metal look and feel can be specified by setting the system property swing.metalTheme=steel.
  See bug report 4607364 and the detailed Swing release notes for more information.

• After switching from GTK L&F to another L&F at runtime, changes to native GNOME settings (such as application font) appear to cause the GTK L&F to be partially reloaded. This can result in portions of the GUI appearing with the GTK look with other parts displaying in the actual L&F selected. Other symptoms may include error messages or stack traces. Developers and users should be warned against switching from GTK L&F to another L&F at runtime and then changing native GNOME settings. Switching back to the GTK L&F may, in theory, resolve the problem, but this has not been fully determined.
  See bug report 5077738.

General Deployment

• IE, Mozilla, or Netscape 7 may crash during different builds of the JRE 5 (for example, a Beta1, Beta2, Release Candidate or final build), if an older JRE is picked up by a newer Plug-in. The crash is caused by an out-of-sync deployment.properties file. The workaround is to remove the user-level deployment.properties file. See bug report 4930673 .

• For Linux specific deployment issues, see the Linux Notes section.

Internet Explorer will hang if an applet displays a UI component in its stop() or destroy() method and a user triggers stop() or destroy() by pressing the Back or Refresh button in the brower.

Java Update provides the latest updates of J2SE Runtime Environment to end users in a proactive and automatic manner. In release 5, the customizable user options are now configurable through the "Update" tab in the new Java Control Panel.

The server VM is not installed with the stand-alone Windows JRE installation, nor is it installed with the public JRE installed with the JDK installation. If you want the server VM to work with the public JRE, you will need to create the directory

<drive>\:Program Files\Java\jre1.5.0\bin\server

and copy the server VM from

<drive>\:Program Files\Java\jdk1.5.0\jre\bin\server

Java Compiler (javac)

The -source 5 option is required for compiling with the new language features. (Option -source 1.5 is a synonym.) This is the default starting with the 5.0 Beta 2 release. Notice that for the Beta 1 release, -source 1.4 was the default.

The -target 5 option is the default and generates class files compatible with VMs for 5.0. (Option -target 1.5 is a synonym.) Specify the -target 1.4 option to generate class files that are compatible with 1.4 or 5 VMs. Notice that for the Beta 1 release, -target 1.4 was the default.

Concurrent javac processes may lead to crash. This is an infrequent bug. Workarounds are either to use the -client jvm, or do only one build at a time. See bug report 5074555 .

Java Application Launcher (java)

In the Solaris java command for version 1.2.2, -Xhprof was a synonym for -Xrunhrof. The -Xhprof option has not been supported since 1.3.

These interfaces are new in 5.0.

If a subclass of ClassLoader passes a null class name to one of the java.lang.ClassLoader.defineClass methods (or uses the deprecated form which does not supply a class name) and java.lang.instrument is enabled with the -javaagent option to the java command or a JVM TI agent has enabled the ClassFileLoadHook event, the VM will crash. See bug report 5096167 for more details.

At the lowest level of JPDA, JVMDI has been replaced with Java Virtual Machine Tool Interface (JVMTI). JVMTI is a new native programming interface for use by development and monitoring tools. It provides both a way to inspect the state and to control the execution of applications running in the Java virtual machine (VM). JVMTI is intended to provide a VM interface for the full breadth of tools that need access to VM state, including but not limited to: profiling, debugging, monitoring, thread analysis, and coverage analysis tools.

Java Virtual Machine Profiler Interface (JVMPI)

This interface has been deprecated. The Java Virtual Machine Tool Interface (JVMTI) will replace it in the next major release.

Java Virtual Machine Debug Interface (JVMDI)

This interface has been deprecated. The Java Virtual Machine Tool Interface (JVMTI) will replace it in the next major release.

J2SE Monitoring and Management Console (jconsole)

The following notes pertain to jconsole functionality in this release:

• The Windows Tile feature in the 5.0 release fails to work with the default window size. The workaround is to resize the window to a much bigger size when jconsole starts up. See bug report 5067121 for details.

• If a JVM terminates while jconsole is connecting to it, jconsole may disable the Memory tab with grey color in subsequent new connections. The workaround is to make new connections with a new jconsole process. See bug report 5074001 for details.

Javadoc Tool (javadoc)

The Javadoc tool has no known crash, hang or other major bugs. The complete list of Javadoc fixed bugs and new features are documented at What's New in Javadoc 5.0.