Java 6 Source向后兼容和SQL
我的理解是，为了维护源代码兼容性，Java从未将新方法引入公共接口，因为这破坏了实现接口的现有客户端。
Java发行说明说明
通常，该政策如下，但以下列出的不兼容之处除外：
维护版本（例如1.4.1、1.4.2）未引入任何新的语言功能或API。他们将保持彼此之间的源兼容性。
功能版本和主要版本（例如1.3.0、1.4.0、5.0）保持向上但不向下的源兼容性。
然而，包java.sql和javax.sql继续发展，并介绍了许多不兼容的改变。例如，我注意到以下不兼容的更改（在Java 6中引入）：
java.sql.Statement扩展java.sql.Wrapper，需要新的两种新方法。java.sql.Statement介绍3种新方法java.sql.PreparedStatement介绍19种新方法！java.sql.ResultSet介绍48种新方法！
您知道添加这些方法的方式和原因吗？是否java.sql正在从平台的其余部分区别对待？您是否知道围绕这些补充的讨论/ JSR？
问题答案：
我从Sun开发人员处收到以下答复
对于JDK 7等功能版本，JDK中API的一般演变策略是
- 不要破坏二进制兼容性（如JLSv3第13章所定义）
- 避免引入源不兼容性
- 管理行为兼容性更改
（有关更多种类的兼容性的更多信息，请参阅
“种类的兼容性：源，二进制和行为”
和
“兼容发展的BigDecimal”
向接口添加方法是二进制 兼容的， 但与 源
不兼容，因此通常不这样做。通常，接口实现越广泛，我们向其添加方法的可能性就越小。JDBC区域是此策略的例外，并且使用较宽松的升级规则，但是当人们想要升级到新的JDK版本时，确实会引起实际问题。
-
ngrok承诺有关其接口的兼容性和稳定性，以便您可以自信地构建集成顶部，知道在升级到较新版本时期望的更改。 兼容性承诺 Point Release (2.0.0 -> 2.0.1) - ngrok承诺在点发布之间没有突破性的变化 Minor Version Change (2.0 -> 2.1) - ngrok可能会进行小的更改，打破兼容性的次要版本更改。 ngrok承诺，任何破坏性更改将由一个版
-
Google正在弃用Google Cloud消息传递，转而采用Firebase Cloud消息传递： Firebase云消息传递（FCM）是GCM的新版本。它继承了可靠和可扩展的GCM架构体系，加上新功能！查看常见问题解答了解更多信息。如果要在新应用中集成消息，请从FCM开始。强烈建议GCM用户升级到FCM，以便在今天和将来受益于新的FCM功能。 根据我在服务器上进行的一些测试，FCM URL(h
-
问题内容： 我在一个应用程序中工作，我们需要将对象保存为XML格式，并在以后需要时加载它们。为此，我使用JAXB将XML编组和解编回Java类。 我的问题是我必须在某个时候更改Java模型（通过添加，重命名或删除属性），结果，我将拥有不兼容的保存XML，无法将其绑定回新的类形式。 为了解决这个问题，每次必须进行更改时，我都会在一个新程序包（以其版本命名）下复制所有类的副本，并应用所请求的更改。并且
-
我正在我的项目中尝试Java8，我被困在与我的构建过程相关的错误中。 我正在使用ANT脚本，在某个时刻，我正在使用一些javascript（嵌入到ANT中）来执行一些特定于构建的操作。导致错误的脚本部分如下所示： 该项目使用Java 7或Java 6构建得很好，但在使用Java 8时，它会给我带来一些错误。这些错误与JS引擎的升级有关。 特别是我得到了以下例外： javax。剧本ScriptExc
-
确保您可以轻松顺利地升级您的应用程序，这对我们是很重要的。这就是为什么我们只在主 要版本里程碑才会打破兼容性。你可能熟悉 语义版本控制 ，这 就是我们在所有的 CakePHP 项目中使用的通用准则。总之，语义版本控制意味着只有主要版 本(比如2.0，3.0，4.0)可以打破向后兼容性。次要版本(比如2.1，3.1，3.2)可能会引入新 的功能，但不能破坏兼容性。错误修复版本(比如2.1.2，3.0
-
查看v3规范，新消息似乎是有效的，难道旧的提供程序库(v3.2.13)不支持它吗？我查看了代码，发现了这个commit，在我看来，这似乎是引入更改的地方。 从我的测试来看，新的提供程序库(3.5.12)可以处理新旧格式，但如果类路径中同时存在新的提供程序库和旧的使用者库，http契约测试将失败，并出现运行时错误。 问题：