» search tips 

• APIs
• Downloads
• Products
• Support
• Training
• Participate

	Join Sun Developer Network

The Java SE project team wishes to thank these community members for contributing to the JDK.

Known Bugs and Issues

The following list summarizes known bugs, workarounds, and other important issues to be aware of in this release.

OS & Hardware Platforms

Linux Notes

Solaris Notes

Windows Notes

Windows Vista Notes

Virtual Machine

HotSpot VMs

Core Libraries

Security

Java Debugger Wire Protocol

Java Native Interface

Java Scripting

JAX-WS

Integration Libraries

JDBC

User Interface

Java 2D

Swing

AWT

Deployment

General Deployment

Applets

Documentation

Supported Configurations

Linux Notes

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

• The Java VM may be unstable in a chroot(3) environment on some versions of Linux if the /proc filesystem is not mounted. This is due to the fact that some Linux libraries and VM routines attempt to extract information (processor counts, stack boundaries, and memory configuration) from the /proc filesystem. These routines may failover to incorrect defaults or crash, particularly if the process is multithreaded.

  To detect whether this Linux bug exists, issue the getconf _NPROCESSORS_CONF shell command from the chroot(3) environment. It should return the correct number of processors on your system. If it doesn't, you need to mount the /proc filesystem in order to run Java inside a chroot(3) file system.

Solaris Notes

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

• On Solaris, thread interruption of a thread attempting certain I/O operations results in interruption of the operation and the throwing of InterruptedIOException in circumstances where thread interruption is ignored on Linux and Windows platforms. This Solaris-specific I/O interruption in response to thread interruption is enabled by default, as with previous releases, but is now controllable with the new UseVMInterruptibleIO Hotspot option switch. By default, this switch is on to maintain previous behavior. If the switch is turned off with:

  -XX:-UseVMInterruptibleIO
  

  then the Solaris-specific I/O interruption in response to thread interruption is disabled.

  At the next major Java SE release cycle the switch may be changed to default to off, to improve portability. If this change is made, the switch will remain available to allow Solaris-specific behavior as required.

  See bug report 4385444 for more information.

• Refer to the Hotspot VMs section for specific limitations.

Windows Notes

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

• As discussed in the Microsoft document "Best Practices for Creating DLLs", there are strict limitations on the kind of code that you can utilize from within DLLMain, due to the potential for deadlocks. It is likely that any attempt to use Java Native Interface (JNI) functions from within DLLMain will result in such a deadlock, and so JNI functions should not be used in that context. Specifically, the MSDN documentation for DLLMain states that "Because DLL notifications are serialized, entry-point functions should not attempt to communicate with other threads or processes. Deadlocks may occur as a result".
• A thread priority regression in J2SE 5.0 has been corrected in Java SE 6 as well as J2SE 5.0, Update 6. Correct behavior is restored and a workaround no longer is needed.

  On Windows, by default Java thread priority MAX_PRIORITY is no longer mapped to the highest native priority (THREAD_PRIORITY_TIME_CRITICAL). Instead it is mapped to THREAD_PRIORITY_HIGHEST. This change is necessary because THREAD_PRIORITY_TIME_CRITICAL threads may interfere with system threads and affect system responsiveness.

  If you need to revert to the prior behavior (THREAD_PRIORITY_TIME_CRITICAL), you can set -XX:ThreadPriorityPolicy=1 .

  See bug report 5101898 for more information.

• Java SE 6 applications that use custom launchers must be installed with msvcr71.dll in the same directory as the launcher executable. This follows the new Windows C runtime distribution model, per http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_C_Run.2d.Time_Libraries.asp.

  Further detail can also be found under bug report 6509291.

• Refer also to the Hotspot VMs section for specific limitations.
• Refer also to the General Deployment section for specific limitations.

Windows Vista Notes

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

• On Windows Vista, there is a more restrictive sandbox for signed applets. A user has fewer privileges than if they were running on another Windows OS.

  On a Windows OS other than Windows Vista, when running a signed applet, a user is prompted with a security warning dialog box and must respond. If "Yes" is clicked, the applet will have AllPermissions to run on the user's machine. This includes permission to write/delete a file from the local disk.

  On a Windows Vista OS, this is no longer true. Instead, AllPermissions is limited to Java Applet scope, not Windows scope. Because a process running in IE has a low integrity level, it will not be able to write/delete a file from a medium/high integrity level directory.

• A signed JNLP application can run only with medium integrity. Granting AllPermissions in a Java Web Start application only permits the Security Manager to allow operations that it would otherwise deny by throwing SecurityExceptions. It does not in any way elevate the permissions a user or a process has on the system.

  For example, a typical (non-admin) user might only be able to read and write files within their own home directory (unless other directories are specifically created to allow permissions to all users).

• User Experience Changes for HTTPS Connections

  On Windows Vista OS, several new behaviors (refer to bug report 6408329) have been introduced in the area of security and user experience for HTTPS connections. They are as follows:

  • HTTPS Certificate

    IE7 blocks navigation to HTTPS sites that present a digital certificate having any of the following problems:

    • Certificate was issued to a hostname other than the current URL's hostname.
    • Certificate was issued by an untrusted root.
    • Certificate is expired.
    • Certificate is revoked.

    Upon encountering a digital certificate problem, IE7 presents an error page that explains the problem. The user may choose to ignore the warning and proceed in spite of the certificate error (unless the certificate was revoked). If the user clicks through a certificate error page, the address bar flood fills with red to serve as a persistent notification of the problem.

  • Mixed-Content Prompt

    A user no longer sees the so-called Mixed-Content prompt, which read:

    "This page contains both secure and nonsecure items.
    Do you want to see the nonsecure items? 
    

    IE7 renders only the secure content and offers the user the opportunity to unblock the nonsecure content using the Information Bar.
  • New Default Protocol Mode

    IE7 of Windows Vista has changed the default HTTPS protocol setting to disable the weaker SSLv2 protocol and to enable the stronger TLSv1 protocol.

  With the above changes in IE7 of Windows Vista, a Java plugin user will see different behavior when running their applets.

• AutoDownload of JREs is Disabled in the Control Panel

  Since the posted autodl bundles cannot run on Vista (without being re-written, and re-staged for all releases) the autodl feature is turned off by default, and the entry is disabled in the advanced tab of the Control Panel.

• Change Cache Location Dialog Disabled in the Control Panel

  Since the cache location must be set to a low-integrity directory, the ability to change it is disabled in the control panel. Refer to bug report 6422509.

• Java Plug-in Extension Installer Mechanism may Fail for a Non-administrator User Running in IE

  The extension install mechanism added to plugin in 1.4.2 uses Runtime.exec() to run a java extension installer (running java -jar <file>), or to run a native extension (running <file>). Normally these installers do things like write files to the lib/ext directory of the jre. These processes will run with the same limited privileges the user has, so may fail when (for example) writing a file where the user has no permission to write.

  This problem would also apply to any Java Web Start application that attempts to install an extension in lib/ext (though this is not a common practice).

  Refer to bug report 6432317.

• Gamesville- Bottle Rocket Applet Fails to Load

  This issue is related to the new Javascript implementation in IE7. A Microsoft bug (140684) has been filed and is under investigation by Microsoft.

• Yahoo-Finance Stock Screener Applet Fails to Load

  This bug is due to user error. The application checks for IE6 and then reverts to a pre-IE6 behavior that is incompatible with IE7. This change/limitation is documented by Microsoft.

  Refer to bug report 6421625.

• Icon Cannot be Added to Tray from an Applet Running Under IE7 on Vista

  Attempting to add an icon to the system tray fails silently, without exceptions. This is the result of security tightening in Internet Explorer 7.

  Refer to bug report 6419042.

• On Windows Vista, the use of DirectDraw for hardware acceleration is currently disabled by default because of incompatibilities with Vista's Desktop Window Manager.

  The -Dsun.java2d.noddraw=false property can be used to re-enable the use of the DirectDraw pipeline. However, this is not recommended due to rendering artifacts and performance problems. To also enable the Direct3D pipeline, a combination of the aforementioned flag and -Dsun.java2d.d3d=true should be used.

  See bug report 6343853 for more information.

• Java SE 6 applications/applets (standalone, Java Plug-in, Java Web Start) do not support running in Windows XP Compatibility Mode.

• Java Control Panel: Under the advanced tab, the Default Java for browser checkboxes does not work for a standard user. To workaround the issue, you will need to run the Java Control Panel as an administrator.
  See bug report 6486929 for more information.

• Java Control Panel: Upon exit of Java Control Panel, you might see a Program Compatibility Assistant dialog box displayed by Windows Vista. We recommend choosing "This control panel works correctly" so that the dialog does not appear again next time you exit Java Control Panel.

  Choosing "Open the control panel using recommended settings" causes Java Control Panel to work incorrectly. To undo the setting, you will need to remove the following registry entry that contains javacpl.cpl or jpicpl32.cpl:

  • HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatiblity Assistant\Persisted
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

  See bug report 6485081 for more information.

• From the Desktop folder, attempts to choose a user directory or the Public directory will fail. For example:
  • Open a JFileChooser under the Windows Look and Feel.
  • Click the Desktop button on the left.
  • Try to enter either your own or the Public directory from the desktop. It won't go into the directory. No exceptions are thrown on the console.

  A workaround is to enter these directories by other means. For example:

  c: -> c:/users/ -> c:/users/<user dir>
  c: -> c:/users/ -> c:/users/Public
  

  See bug report 6488081 for more information.

• When using JFileChooser under the Ocean look and feel, user and Public directories are not shown properly when viewed from the Desktop folder (click Look In, select Desktop), or in the Look In combo box. Instead they are shown as a long sequence of letters/digits. Selecting these sequences does not allow you to enter the directories.

  To access these directories, use the work-around mentioned above for 6488081.

  See bug report 6488082 for more information.

• JFileChooser has a Recent Items button under the windows look and feel. Clicking it shows a folder that always appears empty.

  See bug report 6488492 for more information.

Virtual Machine

HotSpot VMs

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

• Windows native code using JNI and compiled with the common language runtime compiler option (/clr) may encounter a .NET TypeLoadException when any of the following types are used in managed code: jobject, jfieldID, jmethodID, jrawMonitorID. If the .NET exception is unhandled, it will be reported by the Hotspot error handler as exception code 0xe0434f4d in Windows system library kernel32.dll. The failure is caused by the issue described at http://support.microsoft.com/default.aspx?scid=kb;EN-US;871182.

  A workaround is to mark functions referencing the above types with the preprocessor directive pragma unmanaged.

  See bug report 6220093 for more information.

• The Solaris Hotspot VM java.library.path has changed. In prior releases, if the java.library.path property was not explicitly set, a Solaris Hotspot VM created by JNI_CreateJavaVM would in some cases incorrectly initialize the property. This behavior has been corrected. The specific changes are as follows:
  • Initialize java.library.path from the data model specific LD_LIBRARY_PATH_32 or LD_LIBRARY_PATH_64 if it is set, otherwise LD_LIBRARY_PATH.
  • System crle(1) settings will be recognized.
  • The 64-bit VM now correctly appends /usr/lib/64 to java.library.path instead of /usr/lib.

  Except for the /usr/lib/64 change, these changes only affect VMs created with JNI_CreateJavaVM. Applications created via the Java launcher are not affected.

  In very rare cases, applications that used incorrect LD_LIBRARY_PATH settings to work around this bug may need to adjust their environment to avoid UnsatisfiedLinkErrors when loading native libraries. In this case, it is recommended that you correct your LD_LIBRARY_PATH setting or explicitly set java.library.path to the desired value.

• On Solaris x86, if the stack size is set to "unlimited" by the shell that invokes java, the VM fails. This is a known Solaris x86 kernel bug (6374692). A Solaris x86 Kernel patch (118855) is being developed to address this particular issue.

  A workaround is to specify a finite stack size greater than 131359. For example:

  % ulimit -s 131360
  

  JNI users can work around the problem by inserting the following in the native code, before calling the JNI invocation functions.

  mmap(0, 0x1000, 0, MAP_PRIVATE | MAP_FIXED | MAP_ANON, -1, 0);
  

  See bug report 6444959 for more information.

• In prior JDK releases, the java command line launcher invoked the JVM in the primordial thread created by the operating system. This imposed several limitations on tuning the stack size and on the stack itself. With this release, the JVM is invoked from a user level thread, allowing stack sizes to be configured by the user.

  See bug report 6316197 for more information.

• In prior JDK releases, Xcheck:jni was stringent in its checking and would abort on the first minor error encountered. Updates in this release allow errors to be flagged as warnings, and the JVM will continue. This is intended to aid in debugging and uncovering potential underlying issues.

  Please note that it's not safe for user JNI Applications to call into most JNI methods with a pending Exception. The exception must first be cleared or handled as described in the the JNI Specification.

  If a JNI method is called with a pending exception, and if the JNI method while performing VM operations takes an Exception, the pending Exception is discarded and the new Exception is thrown.

  See bug report 6253381 for more information.

• At this release, the -Xincgc option invokes the incremental mode of the concurrent garbage collector instead of the standard mode of that collector. The incremental mode of the concurrent garbage collector does its concurrent work in time slices that are scheduled between minor collections. The intent of the incremental mode is to allow the application access to the processor otherwise used for the concurrent. This mode can be particularly useful on single processor platforms.
• Use of the -Xprof option to generate profiling data can cause a significant slowdown in the execution of your application. To workaround this problem, you can use the following VM option:

  -XX:SuspendRetryCount=5
  

  See bug report 6474293 for more information.

Core Libraries

Security

• Refer to the Windows Vista section for specific limitations.

Java Debugger Wire Protocol

• The specification descriptions of the location fields for the MONITOR_WAIT and MONITOR_WAITED events are incorrect. For both of these, the location field is defined as location contended monitor enter.

  For the MONITOR_WAIT event, this should say:

  location   location at which the wait will occur
  

  And for the MONITOR_WAITED event, this should say:

  location   location at which the wait occured
  

Java Native Interface (JNI)

• On x86 and x64 platforms, JNI native libraries that modify the MXCSR register should treat this register as callee saved. Although the x86 native ABIs do not specify whether MXCSR is caller or callee saved, in Java SE 6, JNI treats it as callee saved in order to achieve better performance.

  If an application cannot tolerate this, specifying the -XX:+RestoreMXCSROnJNICalls VM option will force the old caller saved MXCSR behavior.

Java Scripting

• Java SE 6 includes the javax.script API (JSR 223) and a Rhino (Rhino) based JavaScript engine reference implementation.

  Most of Rhino version 1.6R2 is included (note bug 6330900). However, due to footprint size, a few components are not included. These are items that depend on either the class generation library or on the XMLBeans library. They are as follows:

  • The script to Java bytecode compilation (also called "optimizer") is not included. This feature depends on the class generation library. Its removal means that JavaScript will always be interpreted. Its removal does not affect script execution because the optimizer is transparent.

    Rhino adds experimental continuation support which works only in interpreted mode. Because we always use interpreted mode, JavaScript continuations will work "out of the box" without any settings (such as setting optimization level to -1).

  • Rhino's JavaAdapter has been removed. JavaAdapter is the feature by which a Java class can be extended by script and Java interfaces can be implemented by script. This feature also requires the class generation library. We have replaced this with our own implementation of JavaAdapter. In our implementation, only a single Java interface may be implemented by a JavaScript object. For example, the following works as expected.

    var v = new java.lang.Runnable() {
                  run: function() { print('hello'); }
            }
    v.run();
    

    In most cases, JavaAdapter is used to implement a single interface with Java anonymizer class-like syntax. The uses of JavaAdapter to extend a Java class or to implement multiple interfaces are rare.

  • E4X (ECMAScript for XML - ECMA Standard E4X) has been excluded. Attempting to use XML literals in JavaScript code will result in a syntax error. This feature depends on the XMLBeans library.

  • The Rhino command line tools (including shell) are not included. Instead, we include the jrunscript utility (JDK only). This is a command line scripting language independent shell with the default language being JavaScript.

JAX-WS

• The wsgen -keep flag is designed to keep the generated Java source files. Without this switch, wsgen is required to generate only classes and does not keep Java source files.

  At this time, there is a bug in wsgen. Regardless of whether or not -keep is present on the command line, wsgen always generates Java source files.

  See bug report 6442344 for more information.

• wsgen may fail on classes containing debug information.
  In some cases, wsgen fails to work with classes compiled with debug information. If the web service uses SOAPBinding.Style.Document and parameterStyle is SOAPBinding.ParameterStyle.WRAPPED, and if any WebMethod uses javax.xml.ws.Holder<T> as WebParam, wsgen generates incorrect wrapper classes and compilation fails.
  To workaround, recompile the classes without variable-name debug information, using the javac option -g:lines,source instead of -g. For more information on this option, see the javac options page.
  See bug report 6468404 for information about the root cause of this problem.

Integration Libraries

Java Database Connectivity (JDBC)

• A regression introduced in J2SE 5.0 created a binary compatibility problem with java.sql.Timestamp.compareTo which was only detectable at run-time.
  This bug is fixed in Java SE 6, Beta2 and in J2SE 5.0, Update 7 (5.0u7).

  See bug report 5103041 for more information.

User Interface

2D

• Refer to the Windows Vista section for specific limitations.
• The implementation of some stroke and fill operations has changed. These changes were designed to improve the overall quality of curved shapes in particular, and to have more consistency between a stroked shape and the same shape when filled.
  In some cases, pixels that used to be touched will no longer be touched, and in other cases, pixels that were not previously touched will now be touched. Since the latter change in behaviour can extend the area of a fill, it may cause a noticeable difference with very small shapes such as bullets or tick marks when they are tightly enclosed in a component, and if the fill extends an additional pixel, thus overlapping the border of the component.
  This may sometimes be worked around by using the following code which may produce results closer to the old behaviour.

  graphics2d.setRenderingHint(
     RenderingHints.KEY_STROKE_CONTROL,
     RenderingHints.VALUE_STROKE_PURE);
  

  Alternatively the shape can be adjusted to fit.

Swing

• Refer to the Windows Vista section for specific limitations.
• In prior JDKs, it was possible to pass an illegal value, JFrame.EXIT_ON_CLOSE, into the setDefaultCloseOperation(int operation) method of javax.swing.JDialog. JDialog does not support exit-on-close behavior, and would instead silently DO_NOTHING_ON_CLOSE.

  In Java SE 6, passing an illegal value into JDialog.setDefaultCloseOperation(int operation) results in an IllegalArgumentException at runtime.

  See bug report 5109681 for more information.

• At compile time, javac incorrectly issues a "Sun Proprietary" warning if the code being compiled uses any classes within the following packages:
  • com.sun.java.swing.plaf.windows
  • com.sun.java.swing.plaf.motif
  • com.sun.java.swing.plaf.gtk

  This warning is intended to warn developers against using proprietary APIs. But it should NOT be issued for the packages mentioned above. As such, it is meaningless for those packages only.

  See bug report 6476749 for more information.

AWT

• On Solaris and Linux, the current implementation forces JWindow to stay on top of all other windows. To workaround, you can use an undecorated frame.

  See bug report 5070056 for more information.

• In some synthetic situations (such as repeated showing/disposing of a toplevel) the JVM may crash.

  See bug report 6387273 for more information.

Deployment

General Deployment

• On Solaris and Linux systems, if the Java Control Panel is set to "Use Browser Settings" for proxies, Java Plug-in and Java Web Start do not recognize the default browser. In order to connect to the internet behind a corporate firewall, the browser proxy settings are needed. In JDK6, proxy settings are determined in the following order: Firefox, Mozilla, Netscape. Thus, if the Firefox proxy settings are incorrect, Java Web Start and Java Plug-in also cannot connect to the internet. The result will be "unable to connect to URL" exceptions when running Java Plug-in applets or Java Web Start applications.
  The workaround is to set proxy settings properly in Firefox, or to use the Java Control Panel to manually set the proxy settings.

  See bug report 6478804 for more information.

• When installing the Linux x64 bundle for either the JDK or the JRE, you may see error messages like the following:

  cp: cannot stat : 
  No such file or directory
  

  You can safely ignore these messages; Java is installed correctly and is functional.

  See bug report 6438881 for more information.

Applets

• Shutdown hooks do not work in applets displayed in Internet Explorer.

  See bug report 6434129 for more information.

• See Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer for information and background on this topic.

• If the URL to your applet JAR resources contains a query string and the http header returned by the webserver indicates that the resource should not be cached (that is, cache-control: no-store; or both last-modified and expiration not set), the resource will not be cached by Java Plug-in.

  Due to bug 6506479, when Java Plug-in downloads the resource to the temporary location, the query portion of the URL is not used, hence your JAR resource might not be downloaded correctly.

  To workaround the problem, when using a JAR resource URL that contains a query string, please make sure your webserver will return the appropriate headers so that applet JAR resources can be cached.

  See bug report 6506479 for more information.

Documentation

Supported Configurations

• In the 'Supported Writing Systems' table of the 'Supported Locales' document, there is a superscript (5) which denotes that Sun Java Desktop System Release 3 is supported for certain encodings. This is not correct. JDK 6 is not supported on Sun Java Desktop System for Linux.

About Sun  |  About This Site  |  Newsletters  |  Contact Us  |  Employment  |  How to Buy  |  Licensing  |  Terms of Use  |  Privacy  |  Trademarks     © 2010, Oracle Corporation and/or its affiliates A Sun Developer Network Site Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.    Sun Developer RSS Feeds