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

Question

6

我正在构建一个基于Android的系统，需要通过二进制协议发送数据。我预计将有多个协议的许多版本和与之相关的维护问题。

我想到了一个解决版本问题的方法，就是使用Java的二进制兼容性。

假设应用程序A依赖于库L。L包含一个在A中使用的类C，该类实现接口I。我使用接口I(0)的定义构建L和A。我在设备上安装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二进制兼容性的文档？

- G. Blake Meike

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- danfuzz · Accepted Answer

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

在设计.dex格式时，我不会声称严格遵守任何规范。我要说的是，我希望该格式能够成为一个适合容纳最初使用Java编程语言编写的程序的容器，包括在分离的代码编译和演变环境中跨代码兼容性方面的考虑。

话虽如此（正如我所暗示的那样），这是一个很容易出错的实现领域，在实践中，由于很少有程序实际上依赖于您感兴趣的保证，因此问题通常会长时间未被检测到。

因此，也许重要的不是我想要什么，而是世界上的VM实际上做了什么。我强烈建议在野外测试各种交叉链接和升级方案，以及测试多个不同的VM。您可能会发现结果反对在设计中依赖此功能。