Java SE 6 Advanced Revision Bug Fixes and Updates

The following tables summarize changes made in all Java SE 6 Advanced revisions. Bug fixes and any other changes are listed below in date order, most current revision first. Note that bug fixes in previous revisions are also included in the current revision.

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

java -version

The OS, processor architecture, server, and other hardware in use must be supported by the virtualization product.

As of Java for Business 6u16, support is available for VirtualBox, Solaris Containers and Solaris LDOMs.

Changes in 6u91 b31

Please note that fixes from prior revisions (6u85 b31) are included in this revision.

New Features and Changes

SSLv3 is disabled by default

Starting with JDK 6u91 release, the SSLv3 protocol (Secure Socket Layer) has been deactivated and is not available by default. See the java.security.Security property jdk.tls.disabledAlgorithms in <JRE_HOME>/lib/security/java.security file.

If SSLv3 is absolutely required, the protocol can be reactivated by removing "SSLv3" from the jdk.tls.disabledAlgorithms property in the java.security file or by dynamically setting this Security property to "true" before JSSE is initialized.

Starting with JDK 6u85, unsafe server certificate change in SSL/TLS renegotiations is not allowed by default. Server certificate change in an SSL/TLS renegotiation may be unsafe and should be restricted:

if endpoint identification is not enabled in an SSL/TLS handshaking; and

if the previous handshake is a session-resumption abbreviated initial handshake; and

the identities represented by both certificates (in previous handshake and this handshake) cannot be regraded as the same.

If unsafe server certificate change is really required, please set the system property, jdk.tls.allowUnsafeServerCertChange, to "true" before JSSE is initialized. Note that this would re-establish the unsafe server certificate change issue.

The system property org.omg.CORBA.ORBSingletonClass is used to configure the system-wide/singleton ORB. The handling of this system property has changed to require that the system wide/singleton ORB be visible to the system class loader. This is a change from previous releases where the singleton ORB was located using the thread context class loader of the first thread to call the no-argument ORB.init method. The implication of this change is that the system-wide/singleton ORB needs to be deployed on the class path or in the extension directory.

Applications that bundle their own ORB and only configure the property org.omg.CORBA.ORBClass should not be impacted by this change. The per-application ORB will be located via the thread context class loader of the thread calling the 2-argument ORB.init method as before.

See 8025005 (not public).

Area: xml/jaxpSynopsis: Custom entities mapping files are no longer loaded with full permission

Legacy code may use the JDK internal API SerializerFactory to create a Serializer. In the process, a custom entity mapping file may be specified through the format parameter. The custom file was then loaded with full permission. As of this release, files that complies with java.util.ResourceBundle format, that is, with a ".properties" extension, will continue to be loaded with full permission. However, any other custom mapping files will require specific file access permission when the program is running with a SecurityManager.

The workaround to any issues caused by lack of permission to using an arbitrary file as the entity mapping file is, either changing the file to a resource bundle, or granting file read permission.

Known Issues

Simultaneous multiple thread operations on the same FileChannel can create a scenario where the NativeThreadSet buffer needs to grow and a subsequent removal operation can lead to negative array index reference. A stack similar to this would be seen:

java.lang.ArrayIndexOutOfBoundsException: -1
at sun.nio.ch.NativeThreadSet.remove(NativeThreadSet.java:54)
at sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:257)

A JDK 6u71 based fix is available. If you encounter such an issue, please contact Oracle Support.

Known Issues

If the portion of the codebase that specifies the protocol, host, and port, are not the same for the unsigned JAR file (or class files) as for the JavaScript or HTML, the code will fail without a mixed code dialog warning.

You can work around this using one of the following approaches:

Put the JAR files (or class files) and the HTML/JavaScript on the same host.

Sign the JAR files. (Self signed can cause the LiveConnect dialog to show already; or add a manifest file that specifies the Caller-Allowable-Codebase attribute.)

Use the Deployment Rule Set (DRS) to allow the app and HTML to run without a warning.

When specifying the codebase, using the Caller-Allowable-Codebase attribute or the Deployment Rule Set, make sure to list the domain where the JavaScreipt/HTML is hosted.

Change in Networking API Implementation on Windows platforms

The implementation of the networking APIs has been changed on Windows to use the SO_EXCLUSIVEADDRUSE socket option by default. This change is necessary to address anomalies that arise when using both IPv4 and IPv6 applications that require to bind to the same port.

This change may cause issues for applications that rely on the ability to have multiple processes bound to the same address and port. When such issues occur, use sun.net.useExclusiveBind system property as a temporary workaround to restore legacy behavior.

Changes in 6u21-rev-b09

OlsonData 2010k

Disabling mmap Usage (on Solaris or Linux)

This release includes a new system property, sun.zip.disableMemoryMapping, which allows the user to disable the mmap usage in Sun's java.util.zip.Zipfile implementation (on Solaris and Linux platforms). Solaris or Linux applications that use java.util.zip.ZipFile may experience a SIGBUS VM crash if the application accidentally overwrites any zip or jar files that are still being used by the same Java runtime. Although this is a programming error of the offending application, this system property provides a solution to avoid the VM crash. With the property set to true (-Dsun.zip.disableMemoryMapping=true, or simply -Dsun.zip.disableMemoryMapping) the Sun JDK/JRE runtime disables the mmap usage and the VM crash that might otherwise occur by overwriting the jar or zip file can be avoided.

Changes in 6u6-rev-b03

Auto Update Off

Beginning with this revision, the JRE auto update feature defaults to OFF.

Auto Update behavior may be unpredictable if this revision is co-installed with any other Java SE implementation (Java for Business or Java SE) that does not have the auto update scheduler already turned off (AU-OFF). Results will also be unpredictable if this revision for Java for Business is installed and then subsequently a Java SE Update is installed with auto update turned on (the default for Java SE).

To workaround this problem, ensure that any other Java SE implementation residing on a system has auto update turned off prior to installing this revision or a subsequent revision. Or else, remove any other Java SE implementation before installing this or a subsequent revision.