Ist die Erstellung von Java-Klassendateien deterministisch?

Sind bei Verwendung desselben JDK (dh derselben javacausführbaren Datei) die generierten Klassendateien immer identisch? Kann es je nach Betriebssystem oder Hardware einen Unterschied geben ? Könnten außer der JDK-Version noch andere Faktoren zu Unterschieden führen? Gibt es Compileroptionen, um Unterschiede zu vermeiden? Ist ein Unterschied nur theoretisch möglich oder erzeugt Oracle javactatsächlich unterschiedliche Klassendateien für dieselben Eingabe- und Compileroptionen?

Update 1 Ich habe Interesse an der Erzeugung , dh Compiler - Ausgang, nicht , ob eine Klassendatei werden kann laufen auf verschiedenen Plattformen.

Update 2 Mit "Same JDK" meine ich auch die gleiche javacausführbare Datei.

Update 3 Unterscheidung zwischen theoretischem und praktischem Unterschied bei Oracle-Compilern.

[BEARBEITEN, paraphrasierte Frage hinzufügen]
"Unter welchen Umständen erzeugt dieselbe ausführbare Javac-Datei, wenn sie auf einer anderen Plattform ausgeführt wird, einen anderen Bytecode?"

Sagen wir mal so:

Ich kann leicht einen vollständig konformen Java-Compiler .classerstellen, der bei derselben .javaDatei niemals zweimal dieselbe Datei erstellt.

Ich könnte dies tun, indem ich alle Arten von Bytecode-Konstruktionen optimiere oder einfach überflüssige Attribute zu meiner Methode hinzufüge (was erlaubt ist).

Da die Spezifikation nicht erfordert, dass der Compiler byteweise identische Klassendateien erstellt, würde ich es vermeiden , von einem solchen Ergebnis abhängig zu sein.

Jedoch , die wenige Male , dass ich überprüft habe, die gleiche Quelldatei mit dem gleichen Compiler mit den gleichen Schaltern (und den gleichen Bibliotheken!) Kompilieren taten Ergebnis in den gleichen .classDateien.

Update: Ich bin kürzlich über diesen interessanten Blog-Beitrag über die Implementierung von switchon Stringin Java 7 gestolpert . In diesem Blog-Beitrag gibt es einige relevante Teile, die ich hier zitieren werde (Hervorhebung von mir):

Um die Ausgabe des Compilers vorhersehbar und wiederholbar zu machen, sind die in diesen Datenstrukturen verwendeten Karten und Mengen eher LinkedHashMaps und LinkedHashSets als nur HashMapsund HashSets. In Bezug auf die funktionale Korrektheit des Codes, der während einer bestimmten Kompilierung generiert wurde , wäre die Verwendung von HashMapund HashSetin Ordnung . Die Iterationsreihenfolge spielt keine Rolle. Allerdings finden wir es von Vorteil zu haben javac‚s Ausgabe variieren nicht auf Details der Implementierung von Systemklassen .

Dies verdeutlicht das Problem ziemlich deutlich: Der Compiler muss nicht deterministisch handeln, solange er der Spezifikation entspricht. Die Compiler-Entwickler erkennen jedoch, dass es im Allgemeinen eine gute Idee ist, es zu versuchen (vorausgesetzt, es ist wahrscheinlich nicht zu teuer).

Die Compiler sind nicht verpflichtet, auf jeder Plattform denselben Bytecode zu erstellen. Sie sollten das javacDienstprogramm der verschiedenen Anbieter konsultieren , um eine spezifische Antwort zu erhalten.

Ich werde ein praktisches Beispiel dafür mit der Reihenfolge der Dateien zeigen.

Nehmen wir an, wir haben 2 JAR-Dateien: my1.jarund My2.jar. Sie werden libnebeneinander in das Verzeichnis gestellt . Der Compiler liest sie in alphabetischer Reihenfolge (da dies lib), aber die Reihenfolge ist my1.jar, My2.jarwenn das Dateisystem Groß- und Kleinschreibung ist, und My2.jar, my1.jarwenn es Groß- und Kleinschreibung.

Der my1.jarhat eine Klasse A.classmit einer Methode

public class A {
     public static void a(String s) {}
}

Das My2.jarhat das gleiche A.class, aber mit unterschiedlicher Methodensignatur (akzeptiert Object):

public class A {
     public static void a(Object o) {}
}

Es ist klar, dass, wenn Sie einen Anruf haben

String s = "x"; 
A.a(s); 

In verschiedenen Fällen wird ein Methodenaufruf mit unterschiedlicher Signatur kompiliert. Also, je nach Dateisystem Fall Empfindsamkeit, werden Sie andere Klasse als Ergebnis erhalten.

Kurze Antwort - NEIN

Lange Antwort

Sie bytecodemüssen für verschiedene Plattformen nicht gleich sein. Es ist die JRE (Java Runtime Environment), die genau weiß, wie der Bytecode ausgeführt wird.

Wenn Sie die Java VM-Spezifikation durchgehen, werden Sie feststellen, dass dies nicht zutreffen muss, da der Bytecode für verschiedene Plattformen gleich ist.

Beim Durchlaufen des Klassendateiformats wird die Struktur einer Klassendatei als angezeigt

ClassFile {
    u4 magic;
    u2 minor_version;
    u2 major_version;
    u2 constant_pool_count;
    cp_info constant_pool[constant_pool_count-1];
    u2 access_flags;
    u2 this_class;
    u2 super_class;
    u2 interfaces_count;
    u2 interfaces[interfaces_count];
    u2 fields_count;
    field_info fields[fields_count];
    u2 methods_count;
    method_info methods[methods_count];
    u2 attributes_count;
    attribute_info attributes[attributes_count];
}

Überprüfung der Neben- und Hauptversion

minor_version, major_version

Die Werte der Elemente minor_version und major_version sind die Nebenversionsnummern und Hauptversionsnummern dieser Klassendatei. Zusammen bestimmen eine Haupt- und eine Nebenversionsnummer die Version des Klassendateiformats. Wenn eine Klassendatei die Hauptversionsnummer M und die Nebenversionsnummer m hat, bezeichnen wir die Version ihres Klassendateiformats als Mm. Daher können Versionen des Klassendateiformats lexikografisch geordnet werden, z. B. 1,5 <2,0 <2,1. Eine Java Virtual Machine-Implementierung kann ein Klassendateiformat der Version v genau dann unterstützen, wenn v in einem zusammenhängenden Bereich liegt. Mi.0 v Mj.m. Nur Sun kann angeben, welchen Versionsbereich eine Java Virtual Machine-Implementierung, die einem bestimmten Release-Level der Java-Plattform entspricht, unterstützen kann.1

Lesen Sie mehr durch die Fußnoten

1 Die Java Virtual Machine-Implementierung von Suns JDK-Version 1.0.2 unterstützt die Klassendateiformatversionen 45.0 bis einschließlich 45.3. Die JDK-Versionen 1.1.X von Sun unterstützen Klassendateiformate von Versionen im Bereich von 45.0 bis einschließlich 45.65535. Implementierungen von Version 1.2 der Java 2-Plattform können Klassendateiformate von Versionen im Bereich von 45.0 bis einschließlich 46.0 unterstützen.

Die Untersuchung all dessen zeigt also, dass die auf verschiedenen Plattformen generierten Klassendateien nicht identisch sein müssen.

Erstens gibt es in der Spezifikation absolut keine solche Garantie. Ein konformer Compiler könnte den Zeitpunkt der Kompilierung als zusätzliches (benutzerdefiniertes) Attribut in die generierte Klassendatei stempeln, und die Klassendatei wäre weiterhin korrekt. Es würde jedoch trivialerweise bei jedem einzelnen Build eine andere Datei auf Byte-Ebene erzeugen.

Zweitens gibt es auch ohne solch böse Tricks keinen Grund zu erwarten, dass ein Compiler zweimal hintereinander genau dasselbe tut, es sei denn, seine Konfiguration und seine Eingabe sind in beiden Fällen identisch. Die Spezifikation macht die Quelle Dateinamen als eine der Standard - Attribute beschreiben, und das Hinzufügen von Leerzeilen zu der Quelldatei und könnte die Zeilennummer Tabelle ändern.

Drittens habe ich aufgrund der Host-Plattform nie einen Unterschied im Build festgestellt (außer dem, der auf Unterschiede im Klassenpfad zurückzuführen war). Der Code, der je nach Plattform variieren würde (dh native Codebibliotheken), ist nicht Teil der Klassendatei, und die eigentliche Generierung von nativem Code aus dem Bytecode erfolgt nach dem Laden der Klasse.

Viertens (und vor allem) stinkt es nach einem schlechten Prozessgeruch (wie ein Codegeruch, aber wie Sie mit dem Code umgehen), um dies wissen zu wollen. Versionieren Sie die Quelle, wenn möglich, nicht den Build, und wenn Sie den Build versionieren müssen, die Version auf der Ebene der gesamten Komponenten und nicht für einzelne Klassendateien. Verwenden Sie vorzugsweise einen CI-Server (z. B. Jenkins), um den Prozess der Umwandlung der Quelle in ausführbaren Code zu verwalten.

Ich glaube, wenn Sie dasselbe JDK verwenden, wird der generierte Bytecode immer der gleiche sein, ohne Beziehung zu der verwendeten Harware und dem verwendeten Betriebssystem. Die Bytecode-Produktion wird vom Java-Compiler durchgeführt, der einen deterministischen Algorithmus verwendet, um den Quellcode in Bytecode "umzuwandeln". Die Ausgabe bleibt also immer gleich. Unter diesen Bedingungen wirkt sich nur eine Aktualisierung des Quellcodes auf die Ausgabe aus.

Insgesamt muss ich sagen, dass es keine Garantie dafür gibt, dass dieselbe Quelle denselben Bytecode erzeugt, wenn sie von demselben Compiler kompiliert wird, jedoch auf einer anderen Plattform.

Ich würde Szenarien untersuchen, die verschiedene Sprachen (Codepages) betreffen, zum Beispiel Windows mit japanischer Sprachunterstützung. Denken Sie an Multi-Byte-Zeichen. Sofern der Compiler nicht immer davon ausgeht, dass er alle Sprachen unterstützen muss, wird er möglicherweise für 8-Bit-ASCII optimiert.

In der Java-Sprachspezifikation gibt es einen Abschnitt zur Binärkompatibilität .

Im Rahmen der binären Kompatibilität von Release zu Release in SOM (Forman, Conner, Danforth und Raper, Proceedings of OOPSLA '95) sind Java-Programmiersprachen-Binärdateien unter allen relevanten Transformationen, die die Autoren identifizieren (mit einigen Einschränkungen), binärkompatibel in Bezug auf das Hinzufügen von Instanzvariablen). Im Folgenden finden Sie eine Liste einiger wichtiger binärkompatibler Änderungen, die von der Java-Programmiersprache unterstützt werden:

• Neuimplementierung vorhandener Methoden, Konstruktoren und Initialisierer zur Verbesserung der Leistung.

• Ändern von Methoden oder Konstruktoren, um Werte für Eingaben zurückzugeben, für die sie zuvor entweder Ausnahmen ausgelöst haben, die normalerweise nicht auftreten sollten, oder fehlgeschlagen sind, indem sie in eine Endlosschleife gegangen sind oder einen Deadlock verursacht haben.

• Hinzufügen neuer Felder, Methoden oder Konstruktoren zu einer vorhandenen Klasse oder Schnittstelle.

• Löschen privater Felder, Methoden oder Konstruktoren einer Klasse.

• Wenn ein gesamtes Paket aktualisiert wird, löschen Sie Standardzugriffsfelder (nur für Pakete), Methoden oder Konstruktoren von Klassen und Schnittstellen im Paket.

• Neuanordnen der Felder, Methoden oder Konstruktoren in einer vorhandenen Typdeklaration.

• Verschieben einer Methode in der Klassenhierarchie nach oben.

• Neuordnung der Liste der direkten Superschnittstellen einer Klasse oder Schnittstelle.

• Einfügen neuer Klassen- oder Schnittstellentypen in die Typhierarchie.

In diesem Kapitel werden Mindeststandards für die Binärkompatibilität festgelegt, die von allen Implementierungen garantiert werden. Die Programmiersprache Java garantiert Kompatibilität, wenn Binärdateien von Klassen und Schnittstellen gemischt werden, von denen nicht bekannt ist, dass sie aus kompatiblen Quellen stammen, deren Quellen jedoch auf die hier beschriebenen kompatiblen Arten geändert wurden. Beachten Sie, dass wir die Kompatibilität zwischen Releases einer Anwendung diskutieren. Eine Erörterung der Kompatibilität zwischen Versionen der Java SE-Plattform würde den Rahmen dieses Kapitels sprengen.

Java allows you write/compile code on one platform and run on different platform. AFAIK ; Dies ist nur möglich, wenn die auf einer anderen Plattform generierte Klassendatei gleich oder technisch gleich, dh identisch ist.

Bearbeiten

Was ich mit technisch gleichem Kommentar meine, ist das. Sie müssen nicht exakt gleich sein, wenn Sie Byte für Byte vergleichen.

Gemäß der Spezifikation muss die .class-Datei einer Klasse auf verschiedenen Plattformen nicht byteweise übereinstimmen.

Für die Frage:

"Unter welchen Umständen erzeugt dieselbe ausführbare Javac-Datei, wenn sie auf einer anderen Plattform ausgeführt wird, einen anderen Bytecode?"

Das Cross-Compilation-Beispiel zeigt, wie wir die Javac-Option verwenden können: -target version

Dieses Flag generiert Klassendateien, die mit der Java-Version kompatibel sind, die wir beim Aufrufen dieses Befehls angegeben haben. Daher unterscheiden sich die Klassendateien in Abhängigkeit von den Attributen, die wir während der Kompalierung mit dieser Option angeben.

Höchstwahrscheinlich lautet die Antwort "Ja", aber um eine genaue Antwort zu erhalten, muss beim Kompilieren nach einigen Schlüsseln oder Guid-Generierungen gesucht werden.

Ich kann mich nicht an die Situation erinnern, in der dies geschieht. Um beispielsweise eine ID für Serialisierungszwecke zu haben, ist diese fest codiert, dh sie wird vom Programmierer oder der IDE generiert.

PS Auch JNI kann eine Rolle spielen.

PPS Ich fand, dass javacselbst in Java geschrieben ist. Dies bedeutet, dass es auf verschiedenen Plattformen identisch ist. Daher würde es keinen anderen Code ohne Grund generieren. Dies ist also nur bei nativen Anrufen möglich.

Es gibt zwei Fragen.

Can there be a difference depending on the operating system or hardware? 

Dies ist eine theoretische Frage, und die Antwort lautet eindeutig: Ja, das kann es geben. Wie andere gesagt haben, erfordert die Spezifikation nicht, dass der Compiler byteweise identische Klassendateien erzeugt.

Selbst wenn jeder derzeit existierende Compiler unter allen Umständen (unterschiedliche Hardware usw.) denselben Bytecode erzeugt, könnte die Antwort morgen anders sein. Wenn Sie niemals vorhaben, javac oder Ihr Betriebssystem zu aktualisieren, können Sie das Verhalten dieser Version unter Ihren besonderen Umständen testen. Die Ergebnisse können jedoch unterschiedlich sein, wenn Sie beispielsweise von Java 7 Update 11 zu Java 7 Update 15 wechseln.

What are the circumstances where the same javac executable, when run on a different platform, will produce different bytecode?

Das ist nicht zu erkennen.

Ich weiß nicht, ob Konfigurationsmanagement Ihr Grund ist, die Frage zu stellen, aber es ist ein verständlicher Grund, sich darum zu kümmern. Das Vergleichen von Bytecodes ist eine legitime IT-Kontrolle, jedoch nur, um festzustellen, ob sich die Klassendateien geändert haben, und nicht, um festzustellen, ob sich die Quelldateien geändert haben.

Ich würde es anders ausdrücken.

Erstens denke ich, dass es bei der Frage nicht darum geht, deterministisch zu sein:

Natürlich ist es deterministisch: Zufälligkeit ist in der Informatik schwer zu erreichen, und es gibt keinen Grund, warum ein Compiler sie hier aus irgendeinem Grund einführen würde.

Zweitens, wenn Sie es neu zu formulieren , „wie ähnlich sind Bytecode - Dateien für eine gleiche Sourcecode- Datei?“, Dann Nein , man kann nicht verlassen sich auf die Tatsache , dass sie ähnlich sein wird .

Eine gute Möglichkeit, dies sicherzustellen, besteht darin, die .class (oder in meinem Fall .pyc) in Ihrer Git-Phase zu belassen. Sie werden feststellen, dass git zwischen verschiedenen Computern in Ihrem Team Änderungen zwischen .pyc-Dateien bemerkt, wenn keine Änderungen an der .py-Datei vorgenommen wurden (und .pyc trotzdem neu kompiliert wurde).

Zumindest habe ich das beobachtet. Fügen Sie also * .pyc und * .class in Ihren .gitignore ein!