Java 什么会使向后兼容性变得不可能？

我们有一个平台组件（用Java编写），现在应该在一定时期内向后兼容，例如3年。 是否有可能实现新功能或修复bug必须在平台中更改接口

一个具体的例子是，假设平台中定义了某种侦听器接口，客户端代码将实现侦听器。后来，监听器中似乎需要一个新方法来引入一个新特性，但我们不能这样做，因为它会破坏接口，使一些客户机无法编译

用新方法创建一个扩展原有接口的新接口是一个好主意吗？需要此新功能的客户机现在将实现新接口，并且不需要更改其他客户机代码。当然，平台中的调用现在应该检查监听器的类型，如果它是具有新方法的新接口，那么将调用新方法，或者不执行任何操作

这种更改可能会使代码看起来不那么简单，但我想它仍然可以工作。是否存在必须在平台中更改接口的情况

是否有可能实现新功能或修复bug必须在平台中更改接口

是的，如果此错误是向后兼容性的意外中断，并且在检测到此中断之前您已经发布了产品的多个版本（X+1…X+N）。所以，一部分客户端依赖于旧版本X，但另一部分客户端依赖于X+1。。。X+N损坏的版本。如果你要修复这个bug，那么新的客户端（X+1…X+N）就会被破坏

用新方法创建一个扩展原有接口的新接口是一个好主意吗

可能的，但是您可能会在这些接口的命名和文档编译方面遇到问题。我建议您每3年延迟一次此类功能并中断一次API，并提供关于如何更改旧客户机的详细说明

当然，平台中的调用现在应该检查监听器的类型，如果它是具有新方法的新接口，那么将调用新方法，或者不执行任何操作

有三种向后兼容性：二进制（运行旧客户端）、源（重新编译旧客户端）和行为。如果需要向接口添加新方法，则只能通过检查已使用的接口版本（final String version=“N”）并仅为兼容版本调用新方法来中断源兼容性，但保持二进制兼容性。因此，如果某个旧客户端需要一个新特性，那么应该对其进行更改和重新编译