Java SE 7 和 JDK 7 兼容性

 

Java SE 7 和 JDK 7 兼容性

    兼容性是一个复杂的问题。这篇文档讨论描述Java平台发行的三种可能的不兼容性。

  二进制兼容性

    除了以下列出的以外，Java SE 7 对 Java SE 6 二进制兼容。除了注明的不兼容外，java6编译的class文件可以正确的在Java SE 7中运行。

    由于JSR 292 引入invokedynamic指令，按照JVM规范，Java SE 7的class文件版本为51。由Java SE 7 编译的51版本的class文件不能在Java SE 6中使用。

  源代码兼容

    Java SE 7包含新的语言特性和平台API。如果源代码文件中用到这些新特性，将不能在之前版本的Java平台通过编译。

    通常，源代码兼容性策略是避免引入源代码不兼容性。

    废弃的API将仅仅被用来支持之前的发行。如果使用废弃的API，且不使用 -nowarn 编译参数，javac编译器将生成警告消息。虽然目前上没有尚且没有将废弃的API从系统中删除的计划，但仍然建议修改程序，绕开废弃的API。

    一些sun.*包钟的API被改变。这些API不是用来给开发者使用的。开发者导入sun.*包是错误的行为。更多描述，参阅《为什么开发人员不应该使用sun.*包》（http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html）。

  行为兼容性

    简单地说，行为兼容性是指，在不同版本平台库上相同的输入，程序将执行同样或等价操作。某些方面平台的行为是未明确定义的，底层实现可能发生变化。所以，建议不要写依赖于底层实现的代码，这不是平台的兼容性问题，是程序的bug。

 

 

 

 

Java SE 7 和 Java SE 6 的不兼容

 

 

源代码和二进制：

  API：废除非标准的 com.sun.image.jpeg.codec 包

    详情：JDK 1.2 （1998年12月）中加入的非标准包 com.sun.image.codec.jpeg 负责加载和保存 JPEG 格式图像文件。这个包从未在平台规范中出现，并且从 Java SE 7 发行版中移除。JDK 1.4 中加入了标准的 Java Image I/O API，并替代 com.sun.image.jpeg.codec 包的需求。

 

  API：将2个2D方法标记成final

    详情：在Java SE 6 发行版中，一下三种方法被引入，并且同时应该标记为 final 方法：

    Path2D.Double.getPathIterator(AffineTransform)

    Path2D.Float.getPathIterator(AffineTransform)

    Path2D.getPathIterator(AffineTransform flatness)

    在 Java SE 7 中，这些方法被标记为 final。在 Java SE 7 或将来的版本中，子类将无法重写这些方法。

 

 

 

 

源代码：

  JSR 334：异常处理改进可能导致源代码不兼容

    class Foo extends Exception {}

    class SonOfFoo extends Foo {}

    class DaughterOfFoo extends Foo {}

    ...

    try {

       throw new DaughterOfFoo();

    } catch (final Foo exception) {

       try {

          throw exception; // 1.used to throw Foo, now throws DaughterOfFoo

       } catch (SonOfFoo anotherException) { // 2.Reachable?  }

    }

    第一个不兼容，在1标记处重新抛出异常。但在Java SE 7 中，将抛出DaughterOfFoo异常。

    第二个不兼容是标记2处在Java SE 6中可以编译通过，但在Java SE 7中，将产生编译错误：

    ExceptionIn6And7.java:25: 错误: 在相应的 try 语句主体中不能抛出异常错误SonOfFoo

        } catch (SonOfFoo anotherException) { // 2.Reachable? }

                          ^

    1 个错误

 

  API:MirroredTypeException 现在是 MirroredTypesException 的子类。

    详情：之前，这javax.lang.model.type 包中的 MirroredTypeException 和 MirroredTypesException 两个类型的异常毫不相干，在javac实现中 应该抛出 MirroredTypesException 异常的地方 却抛出了 MirroredTypeException。为了解决这个问题，把 MirroredTypeException 作为 MirroredTypesException 的子类。这个改变是二进制兼容的，而且通常可以保留已有注解处理器的行为。但这个改变仍然可能引发源代码不兼容，改变捕获顺序可以让代码重新通过编译。

 

  API:TypeVisitor接口升级

    详情：新的发行版中语言模型有所修改，一些升级影响到javax.lang.model.*，包括在javax.lang.model.type.TypeVisitor 接口中增加了一个方法。这个扩展对于直接实现这个接口来说是源代码不兼容的。已经预料到这个API和库的增加，应该谨慎的扩展vistors工具，而不是直接使用这个接口。

 

  API：通过新的 RowSetFactory 接口可以创建 RowSetFactory

    详情：新的API引入对Rowet 1.1 的支持，并且明确通过创建一个 Rowetactory 可以使代码更简洁。作为更新的一部分，一些常量的定义会发生变化，但应该不会影响大多数用户。

 

  API：在 JDBC 接口中引入新的方法

    详情：Java SE 7 发行版中，有些新的方法用来支持 JDBC 4.1。包括在 java.sql.Connection, java.sql.Driver, javax.sql.CommonDatasource, 和 java.sql.Statement 接口中增加的方法。因为接口中所有的方法必须实现，所以以前使用这些接口的代码将不能通过Java SE 7编译，除非你增加这些新的方法。更多信息参阅 JDBC 文档。

 

 

 

行为：

  JSR 202：51.0版本class文件的验证

 

  API：java.lang.Float.parseFloat(String) 和 parseDouble(String) 的异常描述文档化。

    详情：从J2SE 1.2开始，当传入参数为null时，java.lang.Float.parseFloat(String) 和 java.lang.Float.parseDouble(String) 方法抛出一个未文档化的 NullPointerException 异常。规范更新，文档化了这个空指针异常。

    {**杜天微注：parseDouble(String)应该是 java.lang.Double 类的，原文写错了。}

 

  API：java.lang.Character.isLowerCase/isUpperCase 方法更新为遵守Unicode规范。

    详情：isLowerCase 和 isUpperCase 的规范和实现都升级位遵守Unicode标准定义，GD=Lu/Ll + Other_UpperCase/LowerCase。另外还增加了java.lang.Character.isAlphabetic(int) 和 java.lang.Character.isIdeographic(int) 两个方法。

 

  API：向TreeMap插入非法项将抛出空指针异常

    详情：由于 java.util.TreeMap 的错误，有可能向空的TreeMap或TreeSet中插入非法的null项，并且没有实现Comparable接口。只有唯一的一个非法值可以插入到空的TreeMap或TreeSet中；再次加入的项可以导致预期的 NullPointerException 或 ClassCastException。在集合上的其他操作也会失败。Java SE 7 中，插入非法值将抛出空指针异常。

 

  API：Formatter.format() 现在抛出 FormatFlagsConversionMismatchException

    详情：现在，如果调用 Formatter.format(String,Object...)方法时，“#”标识描述一个转义字符”s“，并且跟随的参数不是一个Formattable的实例（包括特殊值null），将抛出 FormatFlagsConversionMismatchException 异常。

 

  API：java.nio.channels.DatagramChannel的方法有些改变

    详情：java.nio.channels包中的DatagramChannel 是面向数据报的socket的可选择管道。send、receive 和 connect 方法有所改变。为了保证之前的行为，sun.nio.ch.bugLevel属性可以设值为“1.4”、“15”、“16”。查看DatagramChannel类的描述。

 

  API：更新Socket管道功能

    详情：拥有自己的 provider 实现或 socket/server-socket 模型，或 java.nio.channels 包中的数据报socket管道类的开发者，在Java SE 7 发行版中可能会遇到源代码不兼容。参见API描述。

 

  API：java.awt.Color 文档描述潜在异常

    详情： 之前的发行版中，java.awt.color.ICC_Profile.setData(int, byte[])方法可能抛出异常，但是异常和出发条件没有文档化。这个描述已经被更新。

 

  API：MouseEvent.getButton() 方法可能返回0-3以外的值

    详情：在此之前，当用户点击鼠标案件或滚轮，MouseEvent.getButton()方法返回0-3之间的值。为了包容新的鼠标类型，如2个滚轮，四个或五个按键，这个方法可能的返回的值在0到按键数之间。

 

  API：调用 Windows.setBackground 可能抛出 UnsupportedOperationException 异常

    详情：支持按像素透明窗体作为新的API的一部分，被合并到现有的 Windows.setBackground() 方法。向设值背景设值一个有透明度的颜色，将使窗体按像素透明。但是，有些系统可能不支持这种视觉效果，并且使用透明度颜色调用 Windows.setBackground() 方法将抛出 UnsupportedOperationException 异常。

        这并不影响谨慎设值透明度颜色的新的应用程序，因为代码应该先调用 GraphicsDevice.isWindowTranslucencySupported 方法，验证是否支持这种效果。遗留的程序在不支持按像素透明的系统上使用透明度颜色调用这个方法将失败。我们希望这种改变不会影响太多遗留程序，因为 a) 只有少数遗留程序使用带有透明度的颜色设值他们的窗体 b) 大多数流行的系统支持透明效果。

 

  API：现在 Toolkit.getPrintJob(Frame, String, Properties) 可能抛出 NullPointerException

    详情：在之前的发行版中，当在headless环境下调用 Toolkit.getPrintJob(Frame, String, Properties) 方法时，不是抛出指定的 NullPointerException ， 而是 HeadlessException。从 Java SE 7 开始，这种情况将抛出 NullPointerException。

 

  API：sun.awt.exception.handler 系统属性被官方API替代

    详情：之前任何依赖 sun.awt.execption.handler系统属性的代码应该用标准异常处理机制重写。参阅 Thread.UncaughtExecptionHandler 类。

 

  API：可选地处理确定的色彩空间，如 JPEG 中表明的色彩空间

    详情：更新 ImageIO JPEG 元数据格式规范，支持可选地处理 PhotoYCC, PhotoYCCA, RGBA, 和 YCbCrA 色彩空间。更多信息，参见《JPEG 元数据格式规范和使用指南》（http://download.java.net/jdk7/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html）

 

  API：分离用户地点和用户界面

    详情：默认的Local可以分开设值2种使用类型：格式化设值控制资源的格式化，显示设值用于菜单和对话框。新的 Locale.getDefault(Locale.Category) 方法需要一个 Locale.Category 参数。设值 sun.local.formatasdefault 为 true 可还原之前的行为。

 

  API:JMX API 中加入了可信赖的事件处理

    详情：作为 JSR 255的一部分，事件处理 API 被加入到 JMX 包。新的 API 再某些方面改变了提醒处理的语义，可能影响到覆盖或者建立在标准 RMI 客户端之上的代码。设值系统属性或建立链接服务器时设值一个环境Map，可以还原以前的行为。参见 javax.management.event 包文档。

 

  API：即开即用的 JMX Management 有意个新的关键字用于读写权限

    详情：JDK 6 中，即开即用管理权限控制有2个级别：只读和读写。读写权限控制现在有了一个新的 create 关键字，可以列出可以创建的 MBean 类。即开即用管理的权限也可以由应用程序通过 传递给 JMXConnectorServerFactory.newJMXConnectorServer 的参数 Map 配置项 jmx.remote.x.access.file 控制。偶尔有用户需要简单的权限管理，并从远程建立MBean，应用不需要重新编译：只需要改变权限管理文件的内容即可。

 

 

 

JDK 7 不兼容列表（javac,HotSpot,Java SE API）

 

行为和源代码：

  工具：方法类型推断和重载决议

    详情：:方法类型推断是表现在两个步骤:在第一步我们使用类型的实际参数提供给通用的方法推断方法的类型参数(这是Java语言规范中描述(JLS),Java SE 7版,15.12.2.7部分);在第二步,我们使用范围和约束声明任务上下文推断出其他未推断的类型参数(这是JLS中的描述,Java SE 7版,15.12.2.8部分)。在个别情况下,第二个推理的步骤的结果将使方法的适用性无效。

    例如：

    class Test {

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

      void test(List<String> ls) {

List<Integer> i = m(ls);

      }

    }

    这个程序可以在 JDK 6 上编译——推断类型变量Z为Integer。现在，如果改变 m 中 Z 的声明为Integer 【 m(List<? super Integer>)】，就很容易发现，这个方法不适用，因为我们将传递一个 List<? super String> 到一个需要 List<? super Integer> 的位置上。这违反了类型系统的规则，并最终将导致堆污染(见JLS,Java SE 7版,4.12.2.1部分)——这就是为什么 JDK 7 拒绝编译这段代码。

 

  工具：递归中的无约束类型变量推断

    详情：由于一个同时出现在 Java 编译器和 Java 语言规范中的问题，某些递归中的无约束的情况下变量类型推断未能处理 (见JLS,Java SE 7版,15.12.2.8部分) 。这个问题在 JDK 7 和编译器中都已经得到解决。

    例如，下面的程序在 JDK 6 中将出现一下错误：

    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

    这个程序现在可以被 JDK 7 正确地接受。

    而且，一个利用尖括号的变种操作（JDK 7 加入）

    class Test<x extends Test<X>>{

      Test<?> t = new Test<>();

    }

    以上这个程序在早期的 JDK 7 中被拒绝 —— 但是现在被认为是应该接受的。换句话说，这个推倒的改变是 JDK 7 特性中提升可用性的关键。

 

  工具：正确处理嵌套类名和类型变量的映射

    详情：JLS 描述，程序员可以从整个类体内引用在 C 类声明的类型变量。这意味着，如果 C 包含一个拥有相同名字类型变量的嵌套类，那么这个类型变量应该被“映射”——意味着，这个变量类型的引用也应该被解析到其内部类的名字中。这可能导致如下极端情况下的不兼容：

    class X<Y extends Integer> {

      class Y {}

      class Y1<T extends X<Y>> {  }

    }

    问题是 Y1 声明中的 Y 应该被解析为 X.Y ， 因为 X.Y 不是 Integer 的子类，JDK 7 的 javac 编译器会报错。

 

  工具：一个类不能包含两个擦除后签名相同的方法，但使用不同返回值

    详情：一个类不能包含两个擦除后签名相同的方法，无论返回值是否相同。这遵守了 JSL，Java SE 7版，.8.4.8.3部分。 JDK 6 编译器允许方法使用相同的擦除后签名而返回值不同；这个行为是错误的，并在 JDK 7 中修复。例如：

    class A {

       int m(List<String> ls) { return 0; }

       long m(List<Integer> ls) { return 1; }

    }

    这段代码在 JDK 5.0 和 JDK 6 下编译通过，在 JDK 7 中被拒绝。

 

  工具：编译器不允许非过载方法使用相同的擦除后签名

    详情：在 JDK 7 中，javac 已经修复为正确的实现 JLS Java SE 7版 8.4.8 和 9.4.1 中描述的检查。这个检查阐明了一个类不能够包含两个擦除后签名相同的方法，无论这些方法是否过载。由于 javac 使用的类型擦除技术的限制，泛型翻译的这个约束没有被 javac 适当地实现。结果导致，有些情况 javac 可以发现这个问题， 而有些情况不能。修复的结果是，正确地实现了在 8.4.8 和 9.4.1 部分描述的检查，而 javac 的行为更严禁了一些。

    例如，如下代码在 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;

       }

    }

    现在这个代码将被 javac 拒绝，虽然 B 包括2个方法，compareTo(X)(间接被 Comparable<B>.compareTo(B) 过载)和compareTo(Object)(从 A 继承)不是过载等价的，但他们的擦除后签名是相同的。

 

  工具：多数特定的可变参数方法选择的改变

    详情：javac 编译器的重载决议算法，在一个以上可变参数方法都适用于给定参数时如何选择最具体的可变参数方法问题的修复（参见 JLS ,Java SE 7版，15.12.2.5部分）。因为这个bug， JDK 5 和 JDK 6 编译器将拒绝下面合法的代码：

    class Test {

        void foo(int... i) {}

        void foo(double... d) {}

 

        void test() {

           foo(1,2,3);

        }

    }

    上面的例子中，两个方法都适用（因为你向需要 double 的地方传递一个 int）。因为两个方法都适用，编译器必须选择所谓的最合适的方法，这两者都是最合适的候选对象。这就要看两个方法的签名了；这时候，因为 foo(double...) 方法比 foo(int ...) 接受更广泛的参数，答案很明显：最适合的方法是 foo(int ...)。

    当 javac 编译器接受比 JDK 7 之前接受更多代码的同时，这个修复也在以下情况引发了源代码冲突：

    class Test {

        void foo(int... i) {}

        void foo(Object... o) {}

 

        void test() {

           foo(1,2,3);

        }

    }

    这个代码在 JDK 6 中编译通过（最合适的方法是 foo(int ...)）。这个代码在 JDK 7中不能编译。根据 15.12.2.5 ， 由于 int 不是 Object 的子类，Object 也不是 int 的子类，不可能从这两个方法中选择。不应该允许这样的程序（事实上，从一开始就不应该被允许）。

 

  工具：编译器不再接受一个接口的多次参数化

    详情：之前，编译器会接受两次参数化接口。例如：

    public abstract class Test implements Iterable<Class>, Iterable<Class>; {}

    或

    public interface Test extends Iterable<Class>, Iterable<Class> {}

    或

    public abstract class Test<T extends Iterable<Class> & Iterable<Class>> {}

    这个bug已经被修复。如果源代码包括一次以上参数化接口，则必须清理。

 

  工具：编译器不再允许读取类型变量的私有成员

    详情：在 JDK 5.0  和 JDK 6 中，javac 错误地允许读取类型变量的私有变成员。这是错误的，因为 JLS , Java SE 7 版，4.4部分描述，类型变量的成员是以类型变量边界为组件的交叉类型的成员（交叉类型在 4.9 部分中定义）—— 交叉类型不从组件继承私有成员。因此，下面的程序会得到编译错误：

    class A {

       private int val = 42;

    }

 

    class Test<X extends A> {

        void test(X x) {

    int i = x.val; //error in JDK 7

        }

    }

    上面的程序在 JDK 6 上编译。注意，接受这个程序本来就是不可靠的；不能保证 X 能够从父类继承 val。例如，我们在类型 Test<B> 上调用 test()，B 是 A 的子类，val 在这里就是不可见的。由于 javac 不能保证对于所有 X 实例来说这个程序都是合适的，这个程序必须被拒绝编译。

 

  工具：编译器拒绝读取参数类型的静态成员

    详情：在一个泛型类中地暖以一个非泛型的嵌套类是可能的，如：

    class Outer<X> {

    static class Inner {}

    }

    由于内部类是静态的，没有读取外部类的类型变量的权限。所以，它无法用以下有效的标识读取读取内部类的类型：

    Outer<String>.Inner

    这已经在 JLS，Java SE 7版，6.5.5.2 部分中明确。

 

 

 

 

 

行为：

  HotSpot:Class.getMethods 方法返回值顺序可能改变

    详情：JDK 7 build 129 开始，以下 java.lang.Class 类的反射操作，在返回方法或构造方法时改变了顺序：

    getMethods

    getDeclareMethods

    getDeclareConstructors

    这会引起依赖于方法或构造方法特殊排序方式的程序出现问题。

 

 

  工具：废除 apt 工具

    详情：apt功能被标准的 JSR 269 注解处理替代。在 JDK 7 中运行 apt 工具将打印一条下一个主要版本中将移除的警告。

 

  运行时：SSLv2Hello 握手协议默认禁用

    详情：SSLv2Hello 握手协议用来实现SSLv3服务器与不支持SSLv3的SSLv2服务器连接，现在默认被禁用。这种做法的另一个作用是，SSL/TLS扩展将不能从hello消息中剔除。这在多数情况下没有问题，因为SSL/TLS节点将被认为会忽略它不理接的扩展。可是，老的服务器实现会遇到问题。设值系统属性 sun.security.ssl.allowUnsafeRenegotiation 为 true 来启用以前的行为，但不建议这样做。

 

  运行时：重写系统属性

    详情：Java控制台的经销商属性“Sun Microsystems, Inc”被 Oracle 重写。下面的属性：java.vendor = Sun Microsystems Inc.

    java.vendor.url = http://java.sun.com/

    java.vm.vendor = Sun Microsystems Inc.

    java.specification.vendor = Sun Microsystems Inc.

    java.vm.specification.vendor = Sun Microsystems Inc.

 

    改为

 

    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

 

  运行时：支持系统列表改变

    详情：JDK 7 支持的系统配置相对于 JDK 6有所改变。详情参见 Oracle JDK 7 and JRE 7 Certified System Configurations (http://www.oracle.com/technetwork/java/javase/config-417990.html)。

 

  JMX：JMX远程接口调用连接服务器的新属性

    详情：新的属性 com.sun.management.jmxremote.local.only 为 true（默认值）时，标识本机 JMX RMI 连接器只接受本地接口请求。设值这个属性为 false 恢复 JDK 6 行为，但不推荐这么做，因为本机 JMX RMI 连接器服务将接受来自本地和远程接口的连接。如果用于远程管理，远程 JMX RMI 连接器服务应启用认证和 SLL/TLS 加密。

 

  JMX：重写源代码中 Sun 的引用

    详情：javax.management.Objectname 类， javax.management.MBeanServerDelegate.getImplementationVendor 和 javax.management.MBeanServerDelegate.getSpecificationVendor 方法的默认实现修改为返回标识 Oracle 的字符串作为 JMX 的发行商，而不是“Sun Microsystems.”。

 

  JAXP：JAX-WS 服务遇到 DTD 时抛出 SOAP 失败

    详情：JAX-WS 服务修改为符合 SOAP 1.2 规范，第5部分：

    SOAP 消息构造，SOAP 消息的 XML 信息不能包含文档类型描述（DTD）信息项。

 

  声音：更新 Java 声音合成器使用开源实现

    详情：Java Sound 包的软合成器的实现替换为开源版本。所以，以下特性被抛弃：

    GM soundbank support

    RMF file playback support

    OSS (Open Sound System) support on the Linux platform

    新的合成器实现支持 DLS 的 soundbank 和 Soundont （SF2） 格式。

 

  API：更新 Arrays 和 Collections 排序行为抛出 IllegalArgumentException

    详情：java.util.Arrays.sort 和 java.util.Collections.sort（间接地）使用的算法被替换。如果发现 Comparable 违背约定，新的排序实现可能抛出 IllegalArgumentException。

    之前的实现中，这种情况被静默地忽略。

    如果期望之前的行为，你可以使用新的系统属性 java.util.Arrays.useLegacyMergeSort 恢复之前的归并行为。

 

  API：ThreadGroup.setMaxPriority 方法行为遵守规范

    详情：之前，如果传入的变量小于 Thread.MIN_PRIORITY ， ThreadGroup.setMaxPriority 未能像声明的那样表现：它重置输入值为 Thread.MIN_PRIORITY。规范描述一个小于 Thread.MIN_PRIORITY 的值应该被忽略。现在这个方法的行为遵守这个规范。

 

  API：java.io.File.setReadOnly 和 setWriteable 方法拥有新的行为

    详情：在 windows 上，JDK 7中，java.io.File 类的 setReadOnly 和 setWriteable 方法不再为文件夹设置 DOS 只读属性。这意味着如果文件是一个目录，这些方法将返回 false ，并失败。

    希望在 windows 上设值文件夹只读属性的程序，必须使用新的 API。特别是 File.isWriteable 方法综合考虑有效访问（由文件的自主访问控制列表）和文件是否位于一个可写的卷。

 

  API：如果 http 应答代码是-1，当尝试读取数据时，服务器链接关闭

    详情：为了修复 CR 6886436 bug （http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6886436），如果应答没有合法的 HTTP 状态行，HTTP 协议处理器将关闭到服务器的连接。如果这样，任何在这个连接上读取数据的企图都将得到 IOException。例如，下面的代码是有问题的：

    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

    检查 getResponseCode 方法的返回值是否为 -1 以解决这个问题；也许打开一个新的连接，或者在流上调用 getErrorStream。

 

  API：javax.swing.text.ParagraphView.Row 包私有的类被移除

    详情：包私有的类 javax.swing.text.ParagraphView.Row 被移除。这个类本打算被用于内部，极端情况下使用这个类的应用程序将失败。

 

  API：java.text.BreakIterator.isBoundary(int) 方法行为遵守规范

    详情：按照规范，当给予的偏移超出范围 java.text.BreakIterator.isBoundary(int) 方法返回 false，而不是抛出 IllegalArgumentException 。

    这将影响以下情况中任何已有的 BreakIterator 实现：

    1.没有重写默认的 isBoundary 方法的已有的 BreakIterator 实现，参数为 BreakIterator.last+1 的值的行为将改变。因此，任何使用默认 isBoundary 的自定义 BreakIterator 实现在 JDK 7 中的行为将发生改变。

    2.遵守已有规范的 BreakIterator.isBoundary 实现不再符合 JDK 7 的 API 规范。

    3.使用 Locale Sensitive Services SPI (即 Pluggable Local SPI) 的可插入的 BreakIterator 实现需要更新遵守修改的规范才能在 JDK 7 插入。

    4.如果都存在，并且将来 BreakIterator 实现需要在 JDK 6 和 JDK 7+ 上可插入，实现必须遵守两种不同的规范。

 

  API：基于 Motif 的 AWT 实现被移除

    详情：在 JDK 7 发行版中，有两个 AWT 工具包被支持： 在 Windows 上的 WToolkit 和在 Linux/Solaris 上的 XToolkit。Linux/Solaris 的 MToolkit 实现不再支持。

 

  API：现在各种 Toolkit 方法抛出 HeadlessException

    详情：依照规范，一些方法，例如 Toolkit.isFrameStateSupported(int) 和 Toolkit.loadSystemColors(int[]) 在 headless 环境下将抛出 HeadlessException。之前的发行版没有这样做。Toolkit 类里面的一些方法已经修复，在 headless 环境下调用将抛出 HeadlessException 。

 

  API：MSLU 库被移除

    详情：Microsoft Layer library (MSLU 或 Unicows) 被移除。意味着使用 AWT 的 Java 应用程序将不能在 Windows 98/ME 上运行。

 

  API：UTF-8 实现更新以遵守 Unicode 3.0.1 纠正

    详情：此前，有些 5-6 字节长的形式的 utf-8序列被允许，现在被拒绝。

 

评论

2 楼 duzc2 2012-07-02  

fhzdzq 写道

API：更新 Arrays 和 Collections 排序行为抛出 IllegalArgumentException

    详情：java.util.Arrays.sort 和 java.util.Collections.sort（间接地）使用的算法被替换。如果发现 Comparable 违背约定，新的排序实现可能抛出 IllegalArgumentException。

    之前的实现中，这种情况被静默地忽略。

    如果期望之前的行为，你可以使用新的系统属性 java.util.Arrays.useLegacyMergeSort 恢复之前的归并行为。

==================================================
请教：
1、如果发现 Comparable 违背约定，这个约定是什么？是否说进行Arrays.sort的对象必须实现其接口方法呢？
2、具体应该如何设置上述新的系统属性呢？

====================================================

具体的约定内容，请参考 java.lang.Comparable 的文档。
Arrays.sort(Object[] a) 这个方法的文档中明确：数组中的所有元素都必须实现 Comparable 接口。此外，数组中的所有元素都必须是可相互比较的（也就是说，对于数组中的任何 e1 和 e2 元素而言，e1.compareTo(e2) 不得抛出 ClassCastException）。

设值系统属性使用java的-DX=x 属性，例如：
在Elipse的VM arguments 里面加入 -DTestProperty=123
则 System.out.println(System.getProperty("TestProperty")); 会打印 123。

同理，需要使用 -Djava.util.Arrays.useLegacyMergeSort=true

1 楼 fhzdzq 2012-07-01  

API：更新 Arrays 和 Collections 排序行为抛出 IllegalArgumentException

    详情：java.util.Arrays.sort 和 java.util.Collections.sort（间接地）使用的算法被替换。如果发现 Comparable 违背约定，新的排序实现可能抛出 IllegalArgumentException。

    之前的实现中，这种情况被静默地忽略。

    如果期望之前的行为，你可以使用新的系统属性 java.util.Arrays.useLegacyMergeSort 恢复之前的归并行为。

==================================================
请教：
1、如果发现 Comparable 违背约定，这个约定是什么？是否说进行Arrays.sort的对象必须实现其接口方法呢？
2、具体应该如何设置上述新的系统属性呢？