Java SE 7 and JDK 7 Compatibility

Compatibility is a complex issue. This document discusses three types of potential incompatibilities relating to a release of the Java platform:

  1. Source: Source compatibility concerns translating Java source code into class files including whether or not code still compiles at all.
  2. Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link without error.
  3. Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.

For more information, see Kinds of Compatibility, a section in the OpenJDK Developer's Guide.

Contents

The following compatibility documents track incompatibility between adjacent Java versions. For example, this compatibility page reports only Java SE 7 incompatibilities with Java SE 6, and not with previous versions. To examine Java SE 7 incompatibilities with earlier Java versions, you must trace incompatibilities through the listed files, in order.

The following documents have information on changes to the Java Language Specification (JLS) and the Java VM Specification (JVMS).

Binary Compatibility

Java SE 7 is binary-compatible with Java SE 6 except for the incompatibilities listed below. Except for the noted incompatibilities, class files built with the Java SE 6 compiler will run correctly in Java SE 7.

The class file version for Java SE 7 is 51, as per the JVM Specification, because of the invokedynamic byte code introduced by JSR 292. Version 51 class files produced by the Java SE 7 compiler cannot be used in Java SE 6.

Source Compatibility

Java SE 7 includes new language features and platform APIs. If these are used in a source file, that source file cannot be compiled on an earlier version of the Java platform.

In general, the source compatibility policy is to avoid introducing source code incompatibilities.

Deprecated APIs are interfaces that are supported only for compatibility with previous releases. 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.

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.

Behavioral Compatibility

In its simplest form, behavioral compatibility means that with the same inputs a program performs the same (or an equivalent) operation under different versions of libraries or the platform. There are aspects of the platform's behavior that are intentionally unspecified and the underlying implementation may change in a platform release. For this reason, it is recommended that code is written in such a way so that it does not depend on unspecified behavior: In this scenario, the problem is not an incompatibility in the platform, is it a bug in the code.

Incompatibilities between Java SE 7 and Java SE 6

Java SE 7 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 7 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 are documented here for completeness.

Java SE 7 Incompatibilities in the Language, the JVM, or the Java SE API

  • Area: JSR 202
  • Synopsis: Verification of Version 51.0 Class Files
  • Description: Classfiles with version number 51 are exclusively verified using the type-checking verifier, and thus the methods must have StackMapTable attributes when appropriate. For classfiles with version 50, the Hotspot JVM would (and continues to) failover to the type-inferencing verifier if the stackmaps in the file were missing or incorrect. This failover behavior does not occur for classfiles with version 51 (the default version for Java SE 7). Any tool that modifies bytecode in a version 51 classfile must be sure to update the stackmap information to be consistent with the bytecode in order to pass verification.
  • Nature of Incompatibility: behavioral
  • RFE: 6693236

  • Area: JSR 334
  • Synopsis: Improved Exception Handling May Cause source Incompatibility
  • Description: The following example shows two source incompatibilities: 
    class Foo extends Exception {}

class SonOfFoo extends Foo {}
class DaughterOfFoo extends Foo {}
...
try {
 throw new DaughterOfFoo();
} catch (final Foo exception) {
 try {
    throw exception; // used to throw Foo, now throws DaughterOfFoo
 } catch (SonOfFoo anotherException) { // Reachable?  }
}
    The first incompatibility is that the throw exception; statement throws a Foo exception in JDK 6, but throws a DaughterOfFoo exception in Java SE 7. The second incompatibility is that the catch (SonOfFoo ...) statement compiled under JDK 6 but, under Java SE 7, gets the following error: 
    error: exception SonOfFoo is never thrown in body of corresponding try statement
    Such code is likely to be rare, but should be fixed by removing the non-reachable statements.
  • Nature of Incompatibility: source
  • RFE: 6943289

  • Area: API: Language
  • Synopsis: MirroredTypeException is now a subclass of MirroredTypesException
  • Description: Previously, the two exception types in the javax.lang.model.type package, MirroredTypeException and MirroredTypesException, were unrelated. In the javac implementation, MirroredTypeException was thrown where MirroredTypesException should have been thrown. In part to address this problem, MirroredTypeException was made a subclass of MirroredTypesException. This change is binary compatible and generally preserves the behavior of existing annotation processors. However, it is possible this change may cause source incompatibilities for client programs; in those cases, changing the order of catch clauses should allow the programs to compile again.
  • Nature of Incompatibility: source
  • RFE: 6798955

  • Area: API: Language
  • Synopsis: The TypeVisitor interface has been updated
  • Description: To model the language changes in this release, several updates were made to javax.lang.model.* including adding a method to the javax.lang.model.type.TypeVisitor interface. Such an addition is source incompatible with libraries that have directly implemented the TypeVisitor interface. However, such additions were foreseen as part of this API's evolution and libraries were explicitly cautioned to extend one of the utility visitors instead of directly implementing such an interface.
  • Nature of Incompatibility: source
  • RFE: 6933147

  • Area: API: Language
  • Synopsis: Spec for java.lang.Float.parseFloat(String) and parseDouble(String) Updated to Document Exception
  • Description: The java.lang.Float.parseFloat(String) and java.lang.Float.parseDouble(String) methods have been throwing an undocument NullPointerException when passed a null argument since the methods were introduced in J2SE 1.2. The spec has been updated to document the NPEs.
  • Nature of Incompatibility: behavioral
  • RFE: 6463998

  • Area: API: Language
  • Synopsis: java.lang.Character.isLowerCase/isUpperCase Methods Are Updated to Comply with the Specified Unicode Definition
  • Description: The specification and the implementation of the isLowerCase and isUpperCase methods have been updated to comply with the Unicode Standard definition to be GD=Lu/Ll + Other_UpperCase/LowerCase. Two new methods, java.lang.Character.isAlphabetic(int) and java.lang.Character.isIdeographic(int) have also been added.
  • Nature of Incompatibility: behavioral

  • Area: API: Utilities
  • Synopsis: Inserting an Invalid Element into a TreeMap Throws an NPE
  • Description: Due to an error in java.util.TreeMap, it was previously possible to insert invalid null elements and elements not implementing the Comparable interface into an empty TreeMap or TreeSet. Only a single invalid element could be inserted into an empty TreeMap or TreeSet; additional elements would cause the expected NullPointerException or ClassCastException. Most other operations upon the collection would also fail. As of Java SE 7, inserting an invalid null element or an element not implementing Comparable into an empty TreeMap or TreeSet throws a NullPointerException.
  • Nature of Incompatibility: behavioral
  • RFE: 5045147

  • Area: API: Utilities
  • Synopsis: Formatter.format() Now Throws FormatFlagsConversionMismatchException
  • Description: The Formatter.format(String,Object...) method now throws a FormatFlagsConversionMismatchException exception when the "#" flag is specified for conversion "s" and the following argument is not a Formattable instance (including the special case "null").
  • Nature of Incompatibility: behavioral
  • RFE: 5063507

  • Area: API: NIO
  • Synopsis: The Behavior for Several java.nio.channels.DatagramChannel Methods have Changed
  • Description: The DatagramChannel is the selectable channel for datagram-oriented sockets in the java.nio.channels package. The behavior for the send, receive, and connect methods have been modified. To restore the previous behavior, the sun.nio.ch.bugLevel property can be set to the value of "1.4", "1.5", or "1.6". See the DatagramChannel class specification for more information.
  • Nature of Incompatibility: behavioral
  • RFE: 6621689

  • Area: API: NIO
  • Synopsis: Updated Socket Channel Functionality
  • Description: Developers who have their own provider implementation or mockups of the socket, server-socket, or datagram-socket channel classes in the java.nio.channels package may encounter a source code incompatibility with the Java SE 7 release. See the API specification for more information.
  • Nature of Incompatibility: behavioral
  • RFE: 4640544

  • Area: API: AWT
  • Synopsis: Spec for java.awt.Color Method Documents Potential Exception
  • Description: Prior to this release, it was possible for the java.awt.color.ICC_Profile.setData(int, byte[]) method to throw an exception, but the exception and the conditions under which it was thrown, was not documented. The specification has been updated.
  • Nature of Incompatibility: behavioral
  • RFE: 7042594

  • Area: API: AWT
  • Synopsis: The MouseEvent.getButton() method may return values outside of the [0-3] range
  • Description: Previously, the MouseEvent.getButton method returned a value between 0 and 3 when the user clicked a button or used the scroll wheel. To accommodate newer models of mice with two scroll wheels, or four and five buttons, the method now returns a value from 0 to the number of buttons. This may cause problems for code that expects a value from 0 to 3. Setting the sun.awt.enableExtraMouseButtons property to false restores the JDK 6 behavior.
  • Nature of Incompatibility: behavioral
  • RFE: 6315717

  • Area: API: AWT
  • Synopsis: Invoking Windows.setBackground may result in an UnsupportedOperationException exception
  • Description: Part of the new API to support per-pixel translucent windows has been incorporated into the existing Windows.setBackground() method. Setting the background to a non-opaque color results in making the window per-pixel translucent. However, some systems may not support this visual effect, and as such invoking the setBackground() method with a non-opaque color will result in an UnsupportedOperationException exception. This does not affect new applications that set a non-opaque color deliberately because the code should first verify that the effect is supported by invoking the GraphicsDevice.isWindowTranslucencySupported method. However, legacy applications that apply a non-opaque background color to their frames may fail when the application is run on a system that doesn't support translucency effects. We hope that this will not affect too many legacy applications because a) there are few (if any) legacy apps that apply a non-opaque background color to their frames, and b) most modern systems support tranclucency effects.
  • Nature of Incompatibility: behavioral
  • RFE: 6802853

  • Area: API: AWT
  • Synopsis: Toolkit.getPrintJob(Frame, String, Properties) now throws NullPointerException
  • Description: Prior to this release, when invoking Toolkit.getPrintJob(Frame, String, Properties) in a headless environment, a HeadlessException is thrown instead of the specified NullPointerException. As of the Java SE 7 release, a NullPointerException is thrown in this situation.
  • Nature of Incompatibility: behavioral
  • RFE: 7023011

  • Area: API: AWT
  • Synopsis: The sun.awt.exception.handler System Property has Been Replaced with Official API
  • Description: Any code that previously relied on the sun.awt.exception.handler system property should be rewritten to use the standard exception handling mechanism. See the Thread.UncaughtExceptionHandler class for details.
  • Nature of Incompatibility: behavioral
  • RFE: 4714232

  • Area: API: 2D
  • Synopsis: The Non-standard com.sun.image.codec.jpeg Package is Retired
  • Description: The com.sun.image.codec.jpeg package was added in JDK 1.2 (Dec 1998) as a non-standard way of controlling the loading and saving of JPEG format image files. This package was never part of the platform specification and it has been removed from the Java SE 7 release. The Java Image I/O API was added to the JDK 1.4 release as a standard API and eliminated the need for the com.sun.image.codec.jpeg package.
  • Nature of Incompatibility: binary and source
  • RFE: 6527962

  • Area: API: 2D
  • Synopsis: Three 2D methods are now marked final
  • Description: In the Java SE 6 release, the following three methods were introduced to the platform and should have been marked final at the time.
    • Path2D.Double.getPathIterator(AffineTransform)
    • Path2D.Float.getPathIterator(AffineTransform)
    • Path2D.getPathIterator(AffineTransform flatness)
    They have been marked final in Java SE 7. Subclasses that tried to override these methods will fail to link in Java SE 7 or later.
  • Nature of Incompatibility: binary and source
  • RFE: 6563734

  • Area: API: 2D
  • Synopsis: Handling Certain Color Spaces, as Indicated in the JPEG Spec are Now Optional
  • Description: The ImageIO JPEG Metadata Format Specification has been updated to indicate that handling of PhotoYCC, PhotoYCCA, RGBA, and YCbCrA colorspaces are optional. For more information, see JPEG Metadata Format Specification and Usage Notes.
  • Nature of Incompatibility: behavioral

  • Area: API: Internationalization
  • Synopsis: Separation of User Locale and User Interface Locale
  • Description: The default locale can be independently set for two types of uses: the format setting is used for formatting resources, and the display setting is used in menus and dialogs. The new Locale.getDefault(Locale.Category) method takes a Locale.Category parameter. Previous behavior can be restored by setting the sun.locale.formatasdefault system property to true.
  • Nature of Incompatibility: behavioral
  • RFE: 4700857 

  • Area: API: JMX
  • Synopsis: Reliable Event Handling has been Added to the JMX API
  • Description: As part of JSR 255, event handling API has been added to the JMX package. The new API changes the semantics of notification handling in some subtle ways that may affect client code that replaces or builds on the standard RMI Connector Client. Previous behavior can be restored either by using a system property or an entry in the environment Map supplied when creating the Connector Server. See the javax.management.event package documentation for more information.
  • Nature of Incompatibility: behavioral
  • RFE: 5108776 

  • Area: API: JMX
  • Synopsis: Out-of-the-Box JMX Management Has a New Keyword for ReadWrite Access
  • Description: In JDK 6, the out-of-the-box management defined access control with two levels: readonly and readwrite. The readwrite access control now has a new create keyword that lists the MBean classes that can be created. The access control from out-of-the-box management is also available programmatically, through the configuration item jmx.remote.x.access.file in the Map argument passed to JMXConnectorServerFactory.newJMXConnectorServer. For the rare case of users who use simplified access control and then create MBeans remotely, such applications can be fixed without recompiling: all that is needed is to change the contents of the access control file.
  • Nature of Incompatibility: behavioral

  • Area: API: JDBC
  • Synopsis: New RowSetFactory Interface to allow Creation of a RowSetFactory
  • Description: New API was introduced to support RowSet 1.1 and, specifically, the ability to write more portable code by creating a RowSetFactory. As part of this update, the definition of some constants has changed slightly, but should not affect most users.
  • Nature of Incompatibility: source

  • Area: API: JDBC
  • Synopsis: New JDBC Methods, Including new Methods in Interfaces
  • Description: For the Java SE 7 release, there are new methods to support JDBC 4.1. This includes methods added to the java.sql.Connection, java.sql.Driver, javax.sql.CommonDatasource, and java.sql.Statement interfaces. Because all methods of an interface must be implemented, previous code that uses these interfaces will not compile on Java SE 7 unless you add the new methods. See the JDBC documentation for more information.
  • Nature of Incompatibility: source
  • RFE: 6589685

  • Area: API: java.util package
  • Synopsis: Change in behavior of ArrayList iterator between JDK 6 and JDK 7
  • Description: With the JDK-6359979 fix, the iterator implementation for ArrayList changed. Any subtype of ArrayList that overrides size() without overriding iterator() should be careful of the implementation changes made. An optimized iterator is now present since JDK 7. Overriding the iterator() method may be required. See JDK-8158160 for further details.
  • Nature of Incompatibility: behavior

    Incompatibilities between JDK 7 and JDK 6

    JDK 7 Incompatibilities in javac, in HotSpot, or Java SE API

  • Area: HotSpot
  • Synopsis: Order of Methods returned by Class.get Methods can Vary
  • Description: In JDK 7, build 129, the following reflective operations in java.lang.Class changed the fixed order in which they return the methods and constructors of a class:
    • getMethods
    • getDeclaredMethods
    • getDeclaredConstructors
    This may cause issues for code that assumes (contrary to the specification) a particular order for methods or constructors.
  • RFE: 7023180

  • Area: Tools
  • Synopsis: Method Type-Inference and Overload Resolution
  • Description: Method type-inference is performed in two steps: during the first step we infer method type-arguments using the types of the actual arguments supplied to the generic method (this is described in the Java Language Specification (JLS), Java SE 7 Edition, section 15.12.2.7); during the second step, we infer any uninferred type-variables using constraints from declared bounds and assignment context (this is described in the JLS, Java SE 7 Edition, section 15.12.2.8). In some weird cases, it is possible for the second inference step to infer a result that would invalidate method applicability. Example: 
    class Test {

<Z> List<Z> m(List<? super Z> ls) { return null; }

 void test(List<String> ls) {
List<Integer> i = m(ls);
 }
}

    This program compiles in JDK 6 - inferring Integer for the type-variable Z. Now, if you replace Integer for Z in the declaration of 'm' [this leads to m(List<? super Integer>)], it is easy to spot that the method should not be applicable, as we are attempting to pass a List<? super String> where a List<? super Integer> is expected. This is a violation of the type-system rules, and eventually, will lead to heap pollution (see the JLS, Java SE 7 Edition, section 4.12.2.1) - that is why the JDK 7 compiler rejects the code.

  • Nature of Incompatibility: behavioral and source
  • RFE: 6638712

  • Area: Tools
  • Synopsis: Inference of Unconstrained Type-Variables with Recursive Bounds
  • Description: Due to a problem in both the Java compiler and in the JLS, inference of unconstrained type-variables (see the JLS, Java SE 7 Edition, section 15.12.2.8) failed to handle cases in which recursive type-variable bounds were exploited. This problem has been corrected in both the JDK 7 compiler and in the JLS, Java SE 7 Edition. For instance, the following program fails in JDK 6 with a the following error message: 
    class Test {

<Z extends List<Z>> List<Z> m() { return null; }

 void test() {
List<?> i = m();
 }
}

Test.java:7: incompatible types; inferred type argument(s)
java.lang.Object do not conform to bounds of type variable(s) Z
found : <Z>java.util.List<Z>
required: java.util.List<?>
List<?> i = m();
                   ^
1 error
    This program is now correctly accepted by the JDK 7 compiler. Also, a variant with the diamond operator (new in JDK 7): 
    class Test<X extends Test<X>> {

 Test<?> t = new Test<>();
}
    The above program was rejected in earlier JDK 7 builds - but it is now accepted as it should be. In other words, this inference change is crucial in improving usability of new JDK 7 features.
  • Nature of Incompatibility: behavioral and source
  • RFE: 6650759

  • Area: Tools
  • Synopsis: Shadowing Between Nested Class Names and Type-Variable Names is Now Handled Correctly
  • Description: The JLS states that a programmer can reference a type-variable declared in a class C from the entire body of C. This implies that, if C contains a nested class that has the same name as the type-variable, then the type-variable should be 'shadowed' - meaning that references to the type-variable name will be resolved as references to the nested class name instead. This could lead to incompatibilities in corner cases like the following: 
    class X<Y extends Integer> {

 class Y {}
 class Y1<T extends X<Y>> {  }
}
    The problem is that the reference to Y inside the Y1 declaration is resolved as X.Y and, since X.Y is not a subtype of Integer, the JDK 7 javac compiler reports an error.
  • Nature of Incompatibility: behavioral and source
  • RFE: 5060485

  • Area: Tools
  • Synopsis: A Class Cannot Define Two Methods with the Same Erased Signature but Two Different Return Types
  • Description: A class cannot define two methods with the same erased signature, regardless of whether the return types are the same or not. This follows from the JLS, Java SE 7 Edition, section 8.4.8.3. The JDK 6 compiler allows methods with the same erased signature but different return types; this behavior is incorrect and has been fixed in JDK 7. Example: 
    class A {

 int m(List<String> ls) { return 0; }
 long m(List<Integer> ls) { return 1; }
}
    This code compiles under JDK 5.0 and JDK 6, and is rejected under JDK 7.
  • Nature of Incompatibility: behavioral and source
  • RFE: 6182950

  • Area: Tools
  • Synopsis: Compiler Disallows Non-Overriding Methods with the Same Erased Signatures
  • Description: In JDK 7, javac has been fixed so that it correctly implements the check described in the JLS, Java SE 7 Edition, section 8.4.8 and 9.4.1. This check states that a class may not contain two methods whose erased signatures are identical, even when those methods are not override-equivalent. This restriction, due to limitations of the type-erasure technique used by javac to translate generics, was not implemented properly in javac. As a result, there were some cases in which javac detected the problem, while there were other cases in which javac did not detect the problem. As a result of this fix, the checks described in 8.4.8 and 9.4.1 are now properly implemented, resulting in a slightly stricter javac behavior. For instance, the following code is legal prior to JDK 7: 
    class A{

 public int compareTo(Object o){
    return 0;
 }
}

class B extends A implements Comparable<B> {
 public int compareTo(B b){
    return 0;
 }
}
    This code is now rejected by javac, on the basis that B contains two methods, compareTo(X) (indirectly overridden by Comparable<B>.compareTo(B)) and compareTo(Object) (from A) that are not override-equivalent, but whose erased signature is identical.
  • Nature of Incompatibility: behavioral and source
  • RFE: 6476118

  • Area: Tools
  • Synopsis: Changes in Most Specific Varargs Method Selection
  • Description: The overload resolution algorithm in the javac compiler has been fixed in how it selects the most specific varargs method when more than one method is applicable to a given call-site (see the JLS, Java SE 7 Edition, section 15.12.2.5). Because of a bug, both JDK 5.0 and JDK 6 compilers reject the following legal code: 
    class Test {

  void foo(int... i) {}
  void foo(double... d) {}

  void test() {
     foo(1,2,3);
  }
}

    In the above example, both methods are applicable (because you can pass an int where a double is expected). Since both methods are applicable, the compiler must select the so-called most-specific method, that is, the best candidate among the two. This is done by looking at the signatures of both methods; in this case, since one method (foo(double...)) is accepting an argument that is more general than the other (foo(int...)), the answer is straightforward: the most specific method is foo(int...). While the javac compiler accepts more code than it did prior to JDK 7, this fix also results in a slight source incompatibility in the following case: 

    class Test {

  void foo(int... i) {}
  void foo(Object... o) {}

  void test() {
     foo(1,2,3);
  }
}

    This code compiles in JDK 6 (the most specific method is foo(int...)). This code does not compile under JDK 7. As per 15.12.2.5, it is not possible to choose between foo(int...) and foo(Object...) as neither int is a subtype of Object, nor Object is a subtype of int. This program should be disallowed (in fact, it should never have been allowed in the first place).

  • Nature of Incompatibility: behavioral and source
  • RFE: 6199075

  • Area: Tools
  • Synopsis: Compiler No Longer Allows More Than One Occurrence of the Same Parameterized Interface
  • Description: Previously, the compiler would allow parameterized interfaces twice. For example: 
    public abstract class Test implements Iterable<Class>, Iterable<Class&g

t; {}
    or 
    public interface Test extends Iterable<Class>, Iterable<Class> {}
    or 
    public abstract class Test<T extends Iterable<Class> & Iterable<

Class>> {}
    This bug has been fixed. If source code contains more than one instance of a parameterized interface, it needs to be cleaned up.
  • Nature of Incompatibility: behavioral and source
  • RFE: 4972073

  • Area: Tools
  • Synopsis: Compiler No Longer Allows Access to Private Members of Type Variables
  • Description: In JDK 5.0 and JDK 6, javac erroneously allowed access to private members of type-variables. This is wrong, as the JLS, Java SE 7 Edition, section 4.4, states that the members of a type-variable are the members of an intersection types whose components are the type-variable bounds (intersection types are defined in section 4.9) - and intersection types do not inherit private members from their components. As a result, the following program should get a compilation error: 
    class A {

 private int val = 42;
}

class Test<X extends A> {
  void test(X x) {
int i = x.val; //error in JDK 7
  }
}

    The above program compiles in JDK 6. Note that accepting this program is inherently unsound; there is no guarantee that X will be instantiated to a type that inherits val. For instance, if we called test() on an instance whose type is Test<B>, where B is a subclass of A, val should not be accessible there. Since javac cannot guarantee the well-formedness of this program for all possible instantiations of X this program must be rejected.

  • Nature of Incompatibility: behavioral and source
  • RFE: 6246814

  • Area: Tools
  • Synopsis: Compiler Rejects Access to Static Member in Parameterized Type
  • Description: It is possible for a generic class to define a non-generic nested class, as in: 
    class Outer<X> {

static class Inner {}
}
    Since the inner class is static, it has no access to the outer class type-variables. Therefore it doesn't make sense to access the inner class type with a qualified identifier in the following form: 
    Outer<String>.Inner
    This is now clarified in the JLS, Java SE 7 Edition, section 6.5.5.2.
  • Nature of Incompatibility: behavioral and source
  • RFE: 6486430

  • Area: Tools
  • Synopsis: The apt Tool has been Decommissioned
  • Description: The apt functionality has been superceded by standardized annotation processing in JSR 269. Running the apt tool in JDK 7 prints a warning that it will be removed in the next major release.
  • Nature of Incompatibility: behavioral
  • RFE: 6381698

  • Area: Runtime
  • Synopsis: The SSLv2Hello Handshake Protocol is Now Disabled by Default
  • Description: The SSLv2Hello handshake protocol, which was used by SSLv3 server implementations to communicate with older SSLv2 server implementations that did not understand SSLv3, is now disabled by default. A side effect of this is that the SSL/TLS extensions are no longer stripped from the hello message. In most cases, this is not a problem because an SSL/TLS peer is supposed to ignore any extensions that it does not understand. However, there may be older server implementations that experience problems.
  • Nature of Incompatibility: behavioral

  • Area: Runtime
  • Synopsis: Rebranding System Properties
  • Description: The vendor properties in the Java console that listed "Sun Microsystems, Inc" have been rebranded to Oracle. The values of the following properties have changed from: 
    java.vendor = Sun Microsystems Inc.

java.vendor.url = http://oracle.com/technetwork/java/
java.vm.vendor = Sun Microsystems Inc.
java.specification.vendor = Sun Microsystems Inc.
java.vm.specification.vendor = Sun Microsystems Inc.
    to: 
    java.vendor = Oracle Corporation

java.vendor.url = http://java.oracle.com/
java.vm.vendor = Oracle Corporation
java.specification.vendor = Oracle Corporation
java.vm.specification.vendor = Oracle Corporation
  • Nature of Incompatibility: behavioral

  • Area: JMX
  • Synopsis: New Property for JMX RMI Connector Server
  • Description: The new property, com.sun.management.jmxremote.local.only, when true (the default) indicates that the local JMX RMI connector will only accept connection requests from local interfaces. Setting this property to false restores JDK 6 behavior, but is not recommended because the local JMX RMI connector server will accept connection requests from both local and remote interfaces. For remote management, the remote JMX RMI connector server should be used with authentication and SLL/TLS encyrption enabled.
  • Nature of Incompatibility: behavioral

  • Area: JMX
  • Synopsis: Rebranding Sun References in Source Code
  • Description: The javax.management.Objectname class and javax.management.MBeanServerDelegate.getImplementationVendor and javax.management.MBeanServerDelegate.getSpecificationVendor methods have been modified to return strings that identify Oracle as the default implementation vendor for JMX, rather than "Sun Microsystems."
  • Nature of Incompatibility: behavioral

  • Area: JAXP
  • Synopsis: The XSLTProcessorApplet Class is Removed
  • Description: The XSLTProcessorApplet class is an application-level convenience class that had various problems. It has been removed from the JDK 7 release.
  • Nature of Incompatibility: behavioral

  • Area: JAXP
  • Synopsis: JAX-WS Server Throws a SOAP Fault when it Encounters a DTD
  • Description: The JAX-WS server has been modified to comply with the SOAP 1.2 specification, section 5:
    SOAP Message Construct, the XML infoset of a SOAP message MUST NOT contain a document type declaration (DTD) information item.
  • Nature of Incompatibility: behavioral

  • Area: Sound
  • Synopsis: Java Sound Synthesizer Implementation is Updated to use Open source Implementation
  • Description: The software synthesizer implementation in the Java Sound package has been replaced with an open sourced version. Due to the replacement, the following features were dropped:
    • GM soundbank support
    • RMF file playback support
    • OSS (Open Sound System) support on the Linux platform
    The new synthesizer implementation supports soundbanks in DLS and SoundFont (SF2) formats.
  • Nature of Incompatibility: behavioral
  • RFE: 6702956

  • Area: API: Utilities
  • Synopsis: Updated sort behavior for Arrays and Collections may throw an IllegalArgumentException
  • Description: The sorting algorithm used by java.util.Arrays.sort and (indirectly) by java.util.Collections.sort has been replaced. The new sort implementation may throw an IllegalArgumentException if it detects a Comparable that violates the Comparable contract. The previous implementation silently ignored such a situation. If the previous behavior is desired, you can use the new system property, java.util.Arrays.useLegacyMergeSort, to restore previous mergesort behavior.
  • Nature of Incompatibility: behavioral
  • RFE: 6804124

  • Area: API: Language
  • Synopsis: The ThreadGroup.setMaxPriority Method Now Behaves as Specified
  • Description: Previousy, the ThreadGroup.setMaxPriority did not behave as specified if the passed-in value was less than Thread.MIN_PRIORITY: it reset the input value to Thread.MIN_PRIORITY. The specification states that a value less than Thread.MIN_PRIORITY will be ignored. The method now behaves as specified.
  • Nature of Incompatibility: behavioral
  • RFE: 4708197

  • Area: API: IO
  • Synopsis: java.io.File.setReadOnly and setWriteable Methods Have New Behavior
  • Description: As of JDK 7, on Windows, the java.io.File setReadOnly and setWritable methods no longer set the DOS readonly attribute on directories. This means that these methods will fail, by returning false, if the file is a directory. To preserve the relationship with canWrite, the canWrite method returns true if the file is a directory. Applications that want to set directories on Windows to be read only must use the new API. In particular, the Files.isWritable method takes into account the effective access (as determined by the file's discretionary access control list) and whether the file is located on a writable volume.
  • Nature of Incompatibility: behavioral
  • RFE: 6728842

  • Area: API: Networking
  • Synopsis: Server Connection Shuts Down when Attempting to Read Data When http Response Code is -1
  • Description: As a result of the bug fix for CR 6886436, the HTTP protocol handler will close the connection to a server that sends a response without a valid HTTP status line. When this occurs, any attempt to read data on that connection results in an IOException. For example, the following code is problematic: 
    public static void test () throws Exception {

  .....
  HttpURLConnection urlc = (HttpURLConnection)url.openConnection();
  ....

  System.out.println ("Response code: " + urlc.getResponseCode());

  /** Following line throws java.io.IOException: Invalid Http response
   *  when Response Code returned was -1
   */
  InputStream is = urlc.getInputStream();    // PROBLEMATIC CODE
    To work around this problem, check the return value from the getResponseCode method and deal with a -1 value appropriately; perhaps by opening a new connection, or invoking getErrorStream on the stream.
  • Nature of Incompatibility: behavioral
  • RFE: 7055058

  • Area: API: Swing
  • Synopsis: The javax.swing.text.ParagraphView.Row Package-Private Class is Removed
  • Description: The package-private class, javax.swing.text.ParagraphView.Row class has been removed. This class was intended for internal use only and, in the remote chance that an application uses this class, it will fail.
  • Nature of Incompatibility: behavioral
  • RFE: 6387360

  • Area: API: Text
  • Synopsis: The java.text.BreakIterator.isBoundary(int) Method Now Behaves as Specified
  • Description: The java.text.BreakIterator.isBoundary(int) method now returns false, as specified, when the given offset is out of bounds, rather than throwing an IllegalArgumentException. This affects any existing BreakIterator implementations in the following cases:
    • Any existing BreakIterator implementations that don't override the default isBoundary implementation will see behavior change with the BreakIterator.last+1 value. That is, any applications that include a customized BreakIterator implementation with the default isBoundary will see the behavior change in JDK 7.
    • Any existing BreakIterator.isBoundary implementation that follows the existing spec is no longer compliant with the API spec in JDK 7.
    • Any existing BreakIterator implementation that is pluggable using the Locale Sensitive Services SPI (aka Pluggable Local SPI) needs to be updated to follow the spec change in order to be pluggable in JDK 7.
    • If both existing and future BreakIterator impementations need to be pluggable in both JDK 6 and JDK 7+, the implementations need to change the runtime behavior to follow the different specs.
  • Nature of Incompatibility: behavioral
  • RFE: 6521742

  • Area: API: AWT
  • Synopsis: The Motif-based Implementation of AWT is Removed
  • Description: In the JDK 7 release there are two AWT toolkits that are supported: WToolkit on Windows and XToolkit on Linux/Solaris. The MToolkit implementation on Linux/Solaris is no longer supported.
  • Nature of Incompatibility: behavioral
  • RFE: 6463431

  • Area: API: AWT
  • Synopsis: Various Toolkit methods now throw HeadlessException
  • Description: According to the specification, several methods, for example Toolkit.isFrameStateSupported(int), and Toolkit.loadSystemColors(int[]), should throw a HeadlessException when used in a headless environment. Prior to this release, this was not happening. Several methods in the Toolkit class have been fixed to throw a HeadlessException when invoked in a headless environment.
  • Nature of Incompatibility: behavioral
  • RFE: 6273366

  • Area: API: Internationalization
  • Synopsis: The MSLU Library Has been Removed
  • Description: The Microsoft Layer library (MSLU or Unicows) has been removed. This means that Java applications that use AWT functionality won't run on Windows 98/ME.
  • Nature of Incompatibility: behavioral
  • RFE: 6332635

  • Area: API: Internationalization
  • Synopsis: UTF-8 implementation is upated to conform to Corrigendum to Unicode 3.0.1
  • Description: Previously, there were 5- and 6-byte forms of utf-8 sequences that were allowed. These are now rejected.
  • Nature of Incompatibility: behavioral