This document describes Java™ SE 6 compatibility with J2SE 5.0 under the following topics:
The compatibility documents listed below track incompatibility between adjacent Java versions. For example, this compatibility page reports only Java SE 6 incompatibilities with J2SE 5.0, and not with previous versions. To examine Java SE 6 incompatibilities with earlier Java versions, you must trace incompatiblities through the files listed below, in order.
See the Java Language Specification Maintenance Page for a summary of changes that have been made to the specification of the Java programming language since the publication of the Java Language Specification, Second Edition .
Java SE 6 is upwards binary-compatible with J2SE 5.0 except for the incompatibilities listed below. Except for the noted incompatibilities, class files built with version 5.0 compilers will run correctly in JDK 6.
Some early bytecode obfuscators produced class files that violated the class file format as given in the virtual machine specification. Such improperly formatted class files will not run on the JDK virtual machine, though some of them could have run on earlier versions of the virtual machine. To remedy this problem, regenerate the class files with a newer obfuscator that produces properly formatted class files.
Java SE 6 does not support downward source compatibility. If source files use new language features or Java SE platform APIs, they will not be usable with an earlier version of the Java platform.
In general, the policy is as follows, except for any incompatibilities listed further below:
Maintenance releases (such as 1.4.1, 1.4.2) do not introduce any new language features or APIs. They will maintain source-compatibility with each other.
Functionality releases and major releases (such as 1.3.0, 1.4.0, 5.0) maintain upwards but not downwards source-compatibility.
Deprecated APIs are interfaces that are supported only for backwards compatibility. The
javac compiler generates a warning message whenever one of these is used, unless the -nowarn command-line option is used. It is recommended that programs be modified to eliminate the use of deprecated APIs, although there are no current plans to remove such APIs entirely from the system with the exception of JVMDI and JVMPI.
Some APIs in the sun.* packages have changed. These APIs are not intended for use by developers. Developers importing from sun.* packages do so at their own risk. For more details, see Why Developers Should Not Write Programs That Call
sun.* Packages .
Java SE 6 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 6 without modification. However, there are some minor potential source and binary incompatibilities in the JRE and JDK that involve rare circumstances and "corner cases" that we are documenting here for completeness.
JVMPI was deprecated in J2SE 5.0. It has been disabled in Java SE 6, and it will be removed in the next release. For information on temporarily enabling JVMPI in Java SE 6, contact: jvmpi_eol@Sun.com".
java.nio.channels.FileLockclass checks for files already locked by other
OverlappingFileLockExceptionif an application attempts to lock a region that overlaps a region locked through another
FileChannelinstance. Previous versions did not check for file locks obtained by other
FileChannelinstances. By default the
java.nio.channels.FileChannel.lockmethod checks if the requested lock overlaps with a region held by this Java virtual machine.
java.nio.channels.FileChannel.lockfile checking behavior, as follows:
java.nio.channels.FileChannel.lockchecks for overlapping file locks obtained using this
FileChannelinstance only. Locks acquired by other
FileChannelinstances to the same file are not checked.
java.nio.channels.FileChannel.lockchecks for overlapping file locks from all
FileChannelinstances, according to the specification.
sun.nio.ch.disableSystemWideOverlappingFileLockChecksystem property exists to provide compatibility with J2SE 1.4 and 5.0, which do not implement the JVM-wide overlapping file lock check.
sun.awt.x11.XToolkiton Solaris and other Unix-based platforms
javacwill accept more programs. However, in some rare cases,
javaccan now reject previously accepted, yet incorrect programs.
rt.jarin Java SE 6
-Xbootclasspath:<path to rt.jar>and request any resource files will fail since these resources now reside in a different jar file called
java.beans.EventHandlerEnforces Valid Arguments
java.beans.EventHandlerdocumentation more completely describes the following:
EventHandlerdoes not enforce valid arguments. The
listenerInterfacearguments need to be non-null for it to work correctly. In Java SE 6, The
createmethods now check these arguments and immediately throw an
IllegalArgumentExceptionif any arguments are null.
eventPropertyNamecauses the event to be passed to the target action.
eventPropertyNameand notes that
target/action/listenerInterfaceneeds to be non-null.
constructormethods can throw an
createto throw a
nullPointerExceptionimmediately with null target/action, rather than later on. While the exception is now thrown at a different time, the exception is still the same and is thrown at a point where code logic can catch it and appropriately deal with it.
SpringLayoutwas order dependent
SpringLayoutspecifies three Springs along each axis which dictate the size and position of a component. Only two Springs are needed along each axis, with the third being derived. If three Springs are specified, the layout is considered overly constrained and one of the Springs is dropped. Currently, the behavior for determining which Spring to drop is not intuitive and leads to ordering problems.
SpringLayoutmaintains the order in which springs have been set. As a result, specifying springs is no longer order-dependent. Support for centering and aligning along the baseline has also been added.
constraints.setX(xSpring);In J2SE 5.0, the
setXcall in effect resulted in nothing, in Java SE 6, the
setXcall is meaningful and different behavior will result.
JWindow, JDialog, JApplet, JFrameand other heavyweight components in the Swing package. New methods have been added to
RepaintManagerto manage this activity.
JTrees with drag enabled will now consider editing only after receiving a mouse-released event. Previously, certain press events (such as those not part of a drag gesture) could trigger editing. For consistency, to allow selection changes, and for drag-and-drop to properly occur on the press event; editing can now only start upon the release. With drag disabled, selection will continue to function as it has in the past.
JTreecontain a boolean method called
shouldSelectCell(). This method returns whether the current cell should be selected. It is called once editing is started. It also can be used to determine when editing has started, in order to configure the editor. When drag is enabled in a component, a cell MUST be selected before it can be dragged. For this reason, Java SE 6 ignores
shouldSelectCelland always selects cells when drag is enabled. However, Java SE 6 still calls
shouldSelectCellafter it starts editing, for those users expecting it for side-effects. There is no change if drag is disabled.
JDK1_1AttachArgsno longer used
JDK1_1AttachArgsdata structures are no longer used, but were present in the
jni.hfile and corresponding documentation.
JDK1_1AttachArgshas been removed from
JDK1_1InitArgshas been moved from
jvm.hwhere it is used internally.
kinitwill no longer echo passwords to the screen. Users will need to enter a password twice when entering a new password or changing an existing password. Scripts that use keytool to either create a new keystore or create a new key in the keystore using a password unique from the keystore password will need to be updated.
jarwill preserve file modification dates and times during extract
sun.tools.jar.useExtractionTime=true, is provided so that the Java SE 5.0 and earlier behavior can be obtained. The default value of this property in Java SE is
XMLGregorianCalendar equals()methods now return
javax.xml.datatype.XMLGregorianCalendar.equals()methods now return
falseinstead of throwing a
NullPointerExceptionfor a null parameter.
javax.management.ObjectNameas a separator for "cascading". While JSR 255 is not part of Java SE 6, it is recommended that the domain part of an
ObjectNamenot contain the string "//" to avoid future compatibility issues.