DEX 和 Dalvik 是否支持 Java 二进制兼容性？

Question

我正在构建一个基于 Android 的系统，该系统需要通过二进制协议发送数据。我预计会有多个版本的多个协议以及维护它们的噩梦。

我突然想到，通过使用 Java 的二进制兼容性，我可能能够避开大部分版本控制问题。

假设应用程序A 依赖于库L。 L 包含一个在A 中使用的类C，它实现了接口I。我构建了L 和A，定义了I(0) 接口I。我在设备上安装了L(0) 和A(0)。 A(0) 动态绑定 L(0) 提供类 C(0)。

现在，我扩展接口I，例如添加两个新方法。当我尝试编译L 时，编译失败，因为C 没有实现新方法。我通过扩展C 修复了L，因此它实现了这两种新方法。我现在针对I(1) 编译L(1) 并将其安装到设备上。

请注意，此时A 不会针对I(1) 进行编译。尽管如此，如果这是 Java，A(0) 将使用来自L(1) 的C(1) 正确绑定和运行。

对于 Java 的实现，JLS 第 13 章，二进制兼容性保证了这种行为（以及更多）。如果它适用于 DEX 和 Dalvik，那么我可以让他们的客户完全看不到一大类协议更改。

那么，问题是，DEX 和 Dalvik 是否遵守 JLS 二进制兼容性规范？如果没有，是否有指定 DEX/Dalvik Binary Compatibility 的文档？

Answer 1

我不能权威地谈论 Dalvik VM 的当前发布版本（或相关运行时，如 ART），但作为.dex 格式的设计者，我可以向意图：

我不会声称我严格遵守.dex 格式设计中的任何规范。我要说的是，我希望该格式成为一个合适的容器，用于表示最初用 Java 编程语言编写的程序，包括在单独的代码编译和演化的环境中对跨代码兼容性的担忧。

也就是说（正如我所暗示的那样）这是一个实施领域，超级容易出错，并且在实践中经常会在很长一段时间内无法发现问题，正是因为这样很少有程序实际上取决于您感兴趣的保证类型。

所以，我的意图可能并不重要，重要的是世界上的虚拟机实际上做了什么。我强烈建议在几个不同的虚拟机上明确地测试各种交叉链接和升级方案。您可能会发现结果与设计中的此功能有关。