Printable Page

Release Notes Java 2 SDK, Standard Edition Version 1.5.0 Beta 1

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 Management Extensions Technology

Integration Libraries

RMI

JDBC

User Interface

Java Sound Technology

Java 2D Technology

Fonts for Japanese Locale

AWT

Swing

Deployment

Java Update

Server VM

Tools and Tool Architecture

Java Platform Debugger Architecture

Java Virtual Machine Profiler Interface

Java Virtual Machine Debug Interface

Java Compiler (javac)

The Java 2 SDK, Standard Edition, v1.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 J2SE 1.5.0 Platform

Bug Fixes in the Initial 1.5.0 Beta 1 Release

Java Community Process Review for 1.5.0 Beta 1 API Specification (to End March 4, 2004)

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").

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

• For Beta 1 on AMD Opteron 64, J2SE 1.5.0 will run only on SLES8. It will not run on either SLES8 Service Pack 3 or Redhat AS 3.0. The next Beta release will run on these platforms.

• Java VM crashes with large heap size on Linux. If a crash occurs with heap size > 256M, the first thing to try is to turn off sharing (-Xshare:off). This problem is being tracked in bug report 4983716 and has been resolved in Beta 2.

• Crash on Redhat 9 in __libc_free+0x90. Fix is to apply Redhat glibc patch or set environment variable LD_ASSUME_KERNEL=2.4.1. This problem is being tracked in bug report 4885046 and should be addressed in Beta 2.

• 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. 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.

• 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.

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

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

• The -Xincgc option has been changed to invoke the concurrent garbage collector instead of the train garbage collector. The concurrent garbage collector is a reliable garbage collector that generally provides better performance than the train garbage collector. The train garbage collector can be invoked with the -XX:+UseTrainGC option. The train garbage collector will not be supported in 1.5 and beyond.

• 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 Java HotSpot VM documentation for information on the Server VM and Client VM.

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

• 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 bug still exists in 1.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 main and supplemental NIO documentation.

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

• The jarsigner tool in version 1.5 supports the option of signature timestamping when signing a JAR file. However, JRE versions prior to version 1.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 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 or 1.4.2 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 and 1.4.2	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 1.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 Management Extensions (JMX) Technology

These notes list known restrictions in the Java Management Extensions (JMX^TM) technology included in the Beta 1 Release of J2SE 1.5.0. Details of workarounds to known bugs are given where possible. In cases where there are differences between these release notes and feature documentation, the information in these notes supersedes that in the feature documentation.

• Different applications cannot load native libraries with the same name from the MLet service (bug 4969756)
  The MLet service provides the ability to load MBean classes and native libraries from a remote server. On some platforms, the algorithm of downloading and storing native libraries in the temporary library directory does not allow you to load native libraries with the same name from different applications or from different MLets. A workaround for the limitation of loading native libraries with the same name from two different applications is to call setLibraryDirectory on the different MLets with different library directories.

• javax.management.Attribute defines equals but not hashCode (bug 4920967)
  The javax.management.Attribute class defines an equals method but not a hashCode method. Consequently, you should not use an object of type Attribute as a key in a hash map, hash table or similar.

• DescriptorSupport(String[],Object[]) fails for null parameters (bug 4960737)
  The API specification indicates that the fieldNames and fieldValues parameters to the DescriptorSupport(String[],Object[]) constructor can both be null, in which case an empty DescriptorSupport is produced. In reality, such code will incorrectly throw an exception.

• ModelMBeanInfoSupport.setDescriptor(null, "anything") should get exception (bug 4967769)
  The API specification for ModelMBeanInfo.setDescriptor indicates that if the descriptor type parameter is null, then a RuntimeOperationsException wrapping an IllegalArgumentException should be thrown. But in fact the method returns without throwing an exception in this case.

• MBeanServer specification requires wrong permission for setAttribute() (bug 4972099)
  The API specification for the javax.management.MBeanServer interface is incorrect. For the method setAttribute(), it requires MBeanPermission with getAttribute action. In fact, it should require MBeanPermission with setAttribute action.

• Deprecated deserialize method of the MBeanServer interface throws ClassNotFoundException (bug 4974913)
  The deprecated deserialize method of the MBeanServer interface sometimes throws a ClassNotFoundException. This is because the deserialize method incorrectly uses ClassLoader.loadClass instead of Class.forName(..., classLoader). The typical symptom of using loadClass instead of forName is that the method throws a ClassNotFoundException if and only if you try to load the class X[] before you have loaded the class X.

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

Java Database Connectivity (JDBC)

For 1.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 1.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.

• When running the Java2Demo application under XAWT, the main window (after the splash screen) appears in the center of the screen and then dances to the right and down. This bug does not occur when you run under MToolKit. (See the XAWT release note for information on how to specify MToolKit.) This will be fixed for beta2.
  
  See bug report 4964056 for more information.
• 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 1.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 1.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.

Java Update provides the latest updates of Java 2 Runtime Environment to end users in a proactive and automatic manner. In the 1.5 release, 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 SDK installation. If you want the server VM to work with the public JRE, you will need to create the directory

<drive>\:Program Files\Java\j2re1.4.2\bin\server

and copy the server VM from

<drive>\:sdk1.4.2\jre\bin\server

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.

The package com.sun.jdi.connect.spi is new in J2SE 1.5.0 but wasn't included in the Beta 1 downloadable doc bundle. You can view it at com.sun.jdi.connect.spi

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.

Java Compiler (javac)

The -source 1.5 option is required for compiling with the new language features.

The -target 1.4 option is the default, which generates class files that are compatible with 1.4 or 1.5 VMs. A new option -target 1.5 is available for compatibility only with 1.5 VMs.

The following are issues with javac in 1.5.0 Beta 1:

• Crashes when import annotated class. See bug report 4975363

• Get VerifyError with compound assignment and unboxing. See bug report 4975565

• Crashes when attributes with same elements are used in place of other. See bug report 4951298

• Crashes when enum defined after use in switch. See bug report 4975914