我正在构建一个基于 Android 的系统，该系统需要通过二进制协议(protocol)发送数据。我预计会有多个版本的多个协议(protocol)以及维护它们所带来的噩梦。
我突然想到，通过使用 Java 的二进制兼容性，我或许能够回避大部分版本控制问题。
假设应用程序 A 依赖于库 L。 L 包含一个类C，在A 中使用，它实现了接口(interface)I。我构建了 L 和 A，定义了 I(0) 接口(interface) I。我在设备上安装了 L(0) 和 A(0)。 A(0) 动态绑定(bind)提供类 C(0) 的 L(0)。
现在，我扩展了接口(interface) I，例如添加了两个新方法。当我尝试编译 L 时，编译失败，因为 C 没有实现新方法。我通过扩展 C 修复了 L，因此它实现了两个新方法。我现在针对 I(1) 编译 L(1) 并将其安装在设备上。
请注意，此时，A 不会针对I(1) 进行编译。尽管如此，如果这是 Java，A(0) 将使用 L(1) 中的 C(1) 正确地绑定(bind)和运行>.
对于 Java 的实现，JLS 第 13 章二进制兼容性保证了这种行为(以及更多)。如果它适用于 DEX 和 Dalvik，那么我可以让一大类协议(protocol)更改对他们的客户完全不可见。
那么，问题是，DEX 和 Dalvik 是否遵守 JLS 二进制兼容性规范？如果没有，是否有指定 DEX/Dalvik 二进制兼容性的文档？
最佳答案
我不能权威地谈论 Dalvik VM(或相关运行时，如 ART)的当前发布版本，但作为 .dex 格式的设计者，我可以 说出 Intent :
我不会声称我严格遵守 .dex 格式设计中的任何规范。我要说的是，我希望这种格式成为一种合适的容器，用于表示最初用 Java 编程语言编写的程序，包括对独立代码编译和演化环境中的跨代码兼容性的关注。
就是说(正如我暗示的那样)这是一个 super 容易出错的实现领域，并且在实践中经常会在很长一段时间内未被发现的问题正是因为如此很少有程序实际上取决于您感兴趣的保证类型。
因此，我的 Intent 可能并不重要，重要的是世界上的 VM 实际做了什么。我强烈建议在野外的几个不同 VM 上显式测试各种交叉链接和升级方案。根据您设计中的此功能，您可能会发现结果不尽如人意。
关于java - DEX 和 Dalvik 是否支持 Java 二进制兼容性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37057902/