Unterstützen DEX und Dalvik Java-Binärkompatibilität?

Question

Ich baue ein Android-basiertes System, das das Senden von Daten über ein Binärprotokoll erfordert. Ich erwarte, dass es viele Versionen von mehreren Protokollen geben wird und der Alptraum, der mit der Pflege einhergeht.

Es kommt mir vor, dass ich in der Lage sein könnte, einen großen Teil des Problems mit der Versionsverwaltung zu umgehen, indem ich die Binärkompatibilität von Java verwende.

Angenommen, die Anwendung A hängt von der Bibliothek L ab. L enthält eine Klasse C, die in A verwendet wird und die Schnittstelle I implementiert. Ich baue sowohl L als auch A, mit der Definition I(0) der Schnittstelle I. Ich installiere L(0) und A(0) auf einem Gerät. A(0) bindet dynamisch L(0), die die Klasse C(0) liefert.

Jetzt erweitere ich die Schnittstelle I und füge z. B. zwei neue Methoden hinzu. Wenn ich versuche, L zu kompilieren, schlägt die Kompilierung fehl, da C die neuen Methoden nicht implementiert. Ich repariere L, indem ich C verlängere, also implementiert es die zwei neuen Methoden. Ich kompiliere jetzt L(1) gegen I(1) und installiere es auf dem Gerät.

Beachten Sie, dass zu diesem Zeitpunkt A nicht gegen I(1) kompiliert wird. Sollte dies jedoch Java sein, wird A(0) korrekt gebunden und ausgeführt, wobei C(1) von L(1) verwendet wird.

Dieses Verhalten (und mehr) ist für Implementierungen von Java durch JLS Kapitel 13, Binärkompatibilität garantiert. Wenn es für DEX und Dalvik gilt, dann kann ich eine große Klasse von Protokolländerungen für ihre Kunden völlig unsichtbar machen.

Die Frage ist also, ob DEX und Dalvik sich an die JLS Binary Compatibility-Spezifikation halten? Wenn nicht, gibt es dort ein Dokument, das die Binärkompatibilität von DEX/Dalvik angibt?

Answer 1

Ich kann nicht autoritativ über die aktuellen Versand Versionen der Dalvik VM (oder verwandter Runtimes wie ART) sprechen, aber als Designer des .dex Formats, ich kann sprechen mit dem Vorsatz:

Ich werde nicht behaupten, dass ich mich strikt an irgendwelche Spezifikationen im Design des .dex Formats gehalten habe. Was ich sagen will, ist, dass ich das Format als einen geeigneten Container für die Darstellung von Programmen, die ursprünglich in der Java-Programmiersprache geschrieben waren, einschließlich der Bedenken über die codeübergreifende Kompatibilität in einer Umgebung der separaten Code-Kompilierung und -Evolution, beabsichtigte.

sagte, dass (und wie ich impliziert sorta) ist dies die ein Bereich der Umsetzung super einfach ist falsch zu bekommen, und in denen in der Praxis oft Probleme für längere Zeit unentdeckt bleiben genau da eigentlich so wenige Programme abhängen auf die Art von Garantien, die Sie interessiert sind.

Also, es ist egal, was ich beabsichtigte, so viel wie die VMs da draußen auf der Welt tatsächlich tun. Ich empfehle dringend, die verschiedenen Vernetzungs- und Aktualisierungsszenarien explizit auf mehreren verschiedenen VMs in freier Wildbahn zu testen. Sie können feststellen, dass die Ergebnisse in Abhängigkeit von dieser Funktionalität in Ihrem Design sprechen.