Java 6 源代码向后兼容和 SQL答案

【问题标题】：Java 6 Source backward-compatibility and SQLJava 6 源代码向后兼容和 SQL
【发布时间】：2009-08-11 16:27:38
【问题描述】：

我的理解是，为了保持源代码兼容性，Java 从不向公共接口引入新方法，因为这会破坏实现接口的现有客户端。 Java Release notes 状态

总的来说，政策如下，除了任何不兼容下面进一步列出：

维护版本（例如 1.4.1、 1.4.2) 不引入任何新的语言特性或 API。他们将保持源兼容性彼此。

功能版本和主要发布（例如 1.3.0、1.4.0、5.0）保持向上但不向下源兼容性。

然而，包java.sql 和javax.sql 继续发展并引入了许多不兼容的更改。例如，我注意到以下不兼容的更改（在 Java 6 中引入）：

您知道这些方法是如何以及为什么被添加的吗？ java.sql 的处理方式是否与平台的其他部分不同？你知道围绕这些添加的讨论/JSR 吗？

【问题讨论】：

【解决方案1】：

我收到了来自 Sun 开发人员的以下回复

JDK 7 等功能版本的 JDK 中 API 的一般演进策略是

（有关不同类型兼容性的更多信息，请参阅

向接口添加方法是二进制兼容，但source不兼容，所以不常用。一般来说，一个接口实现得越广泛，我们就越不可能向它添加方法。 JDBC 区域是此策略的一个例外，它使用更宽松的升级规则，但是当人们想要升级到新的 JDK 版本时，这确实会导致真正的问题。

【讨论】：

【解决方案2】：

请注意，添加新方法只会破坏源代码兼容性，在 JDBC 驱动程序中已编译的 Statement 或 ResultSet 实现将继续在更新的 JDK 上运行。只有当您尝试调用新方法时，您才会得到NoSuchMethodError。

【讨论】：

【解决方案3】：

他们可能认为实现这些方法的数据库驱动程序供应商正在与新的 Java 运行时保持同步，因此最好引入有用的新方法并暂时破坏兼容性。

当然，他们本可以设计得更好，这样就不需要破坏兼容性……

【讨论】：

【解决方案4】：

Sun 从不保证版本之间的源代码兼容性，只保证二进制兼容性。最常见的示例是包含“assert”或“enum”标识符的源代码在 JDK 1.4（用于断言）或 1.5+（用于枚举）下无法编译，但现有的 .class 文件仍将在那些较新的 JVM 下运行。

您可以尝试使用 -source 标志在较新的 JVM 下编译较旧的 .java 文件，但如果您依赖已更改的 jvm 类，您仍然可能会遇到问题。

【讨论】：

不完全正确。我在问题中附上了源兼容性政策。它们在破坏源代码兼容性方面比二进制兼容性更宽松；但他们通常会记录这些变化。 java.sql 更改未记录在发行说明中。