DEXとDalvikはJavaのバイナリ互換性をサポートしていますか？

Question

私はバイナリプロトコルでデータを送信する必要があるAndroidベースのシステムを構築しています。私は、複数のプロトコルのバージョンが存在し、それらを維持することに伴う悪夢があることを期待しています。

私がJavaのバイナリ互換性を使用して、バージョン管理の問題の多くを回避することができるかもしれないことを私に起こります。

は、アプリケーションAライブラリLに依存することとします。 Lは、Aで使用されるクラスCを含み、インターフェイスIを実装します。私はLとAの両方を構築し、Iというインタフェースの定義はI(0)です。デバイスにL(0)とA(0)をインストールします。 A(0)は、C(0)を供給するL(0)を動的にバインドします。

は今、私は、例えば、2つの新しいメソッドを追加する、インターフェイスIを延ばします。 が新しいメソッドを実装していないため、Lをコンパイルしようとするとコンパイルが失敗します。私はを拡張してLを修正し、2つの新しいメソッドを実装します。私はI(1)に対してL(1)をコンパイルし、デバイスにインストールします。この時点で、AがI(1)に対してコンパイルされません、

注意。これがJavaの場合、A(0)はC(1)をL(1)から正しくバインドして実行します。

この動作は（およびそれ以上）JLS 13章、バイナリ互換で、ジャワの実装のために、保証されています。もしそれがDEXとDalvikのために成立すれば、私はクライアントには見えない大きなプロトコルの変更を行うことができます。

DEXとDalvikはJLSバイナリ互換性仕様に準拠していますか？そうでなければ、DEX/Dalvikバイナリ互換性を指定する文書がありますか？

Answer 1

私はのDalvik VM（または、ARTなどの関連ランタイム）の現在の出荷バージョンに関する正式話すことはできませんが、.dex形式のデザイナーとして、私はが意図に話すことができ：

私は.dex形式のデザインの仕様に厳密に従っていると主張するつもりはない。私は、コードのコンパイルと展開が別々の環境でのクロスコードの互換性に関する懸念を含め、Javaプログラミング言語で書かれたプログラムを表現するのに適した形式であることを意図しています。

言っ

（と私はみかん暗示のように）、これは間違って取得する超簡単ある実装の領域であり、その問題にしばしば実際に長期間検出されないので、いくつかのプログラムは、実際に依存し、正確ので、

だから、私が意図したことは問題ではないかもしれません。世界のVMが実際に行っていることと同じくらいです。野生のいくつかの異なるVMで、さまざまなクロスリンクシナリオとアップグレードシナリオを明示的にテストすることを強くお勧めします。結果は、デザインのこの機能によって異なります。