Ist die Erstellung von Java-Klassendateien deterministisch?

94

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?"

mstrap
quelle
5
@Gamb CORA bedeutet nicht , dass der Bytecode genau gleich ist, wenn er auf verschiedenen Plattformen kompiliert wird. Alles was es bedeutet ist, dass der generierte Bytecode genau dasselbe tut.
Dasblinkenlight
10
Warum kümmert es dich? Das riecht nach einem XY-Problem .
Joachim Sauer
4
@JoachimSauer Überlegen Sie, ob Sie Ihre Binärdateien versionieren möchten. Möglicherweise möchten Sie Änderungen nur erkennen, wenn sich der Quellcode geändert hat. Sie wissen jedoch, dass dies keine sinnvolle Idee ist, wenn das JDK die Ausgabe-Binärdateien willkürlich ändern kann.
RB.
7
@RB.: Der Compiler darf jeden konformen Bytecode erzeugen, der den kompilierten Code darstellt. Tatsächlich beheben einige Compiler-Updates Fehler, die leicht unterschiedlichen Code erzeugen (normalerweise mit demselben Laufzeitverhalten). Mit anderen Worten: wenn Sie wollen erkennen Quelle ändert, überprüfen Quelle ändert.
Joachim Sauer
3
@dasblinkenlight: Sie gehen davon aus, dass die Antwort, die sie angeblich haben, tatsächlich korrekt und aktuell ist (zweifelhaft, da die Frage aus dem Jahr 2003 stammt).
Joachim Sauer

Antworten:

68

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).

Joachim Sauer
quelle
@GaborSch was fehlt es? "Unter welchen Umständen erzeugt dieselbe ausführbare Javac-Datei, wenn sie auf einer anderen Plattform ausgeführt wird, einen anderen Bytecode?" im Grunde abhängig von der Laune der Gruppe, die den Compiler produziert hat
Emory
3
Für mich wäre dies Grund genug, nicht davon abhängig zu sein: Ein aktualisiertes JDK könnte mein Build- / Archivierungssystem beschädigen, wenn ich davon abhängen würde, dass der Compiler immer denselben Code erzeugt.
Joachim Sauer
3
@GaborSch: Sie haben bereits ein perfektes Beispiel für eine solche Situation, daher war eine zusätzliche Sicht auf das Problem angebracht. Es macht keinen Sinn, Ihre Arbeit zu duplizieren.
Joachim Sauer
1
@GaborSch Das Hauptproblem besteht darin, dass wir ein effizientes "Online-Update" unserer Anwendung implementieren möchten, für das Benutzer nur geänderte JARs von der Website abrufen würden. Ich kann identische JARs mit identischen Klassendateien als Eingabe erstellen. Die Frage ist jedoch, ob Klassendateien immer identisch sind, wenn sie aus denselben Quelldateien kompiliert werden. Unser gesamtes Konzept steht und scheitert mit dieser Tatsache.
Mstrap
2
@mstrap: es ist also doch ein XY-Problem. Nun, Sie können sich mit unterschiedlichen Aktualisierungen von Jars befassen (sodass selbst Ein-Byte-Unterschiede nicht dazu führen würden, dass das gesamte JAR erneut heruntergeladen wird), und Sie sollten Ihren Releases ohnehin explizite Versionsnummern geben, damit meiner Meinung nach der ganze Punkt umstritten ist .
Joachim Sauer
38

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.

gaborsch
quelle
1
+1 Es gibt unzählige Unterschiede zwischen dem Eclipse-Compiler und javac, beispielsweise wie synthetische Konstruktoren generiert werden .
Paul Bellora
2
@GaborSch Mich interessiert, ob der Bytecode für dasselbe JDK identisch ist, dh für denselben Javac. Ich werde das klarer machen.
Mstrap
2
@mstrap Ich habe Ihre Frage verstanden, aber die Antwort ist immer noch dieselbe: hängt vom Anbieter ab. Dies javacist nicht dasselbe, da Sie auf jeder Plattform unterschiedliche Binärdateien haben (z. B. Win7, Linux, Solaris, Mac). Für einen Anbieter ist es nicht sinnvoll, unterschiedliche Implementierungen zu haben, aber jedes plattformspezifische Problem kann das Ergebnis beeinflussen (z. B. Flugreihenfolge in einem Verzeichnis (denken Sie an Ihr libVerzeichnis), Endianness usw.).
Gaborsch
1
Normalerweise wird der größte Teil javacin Java implementiert (und javacist nur ein einfacher nativer Launcher), sodass die meisten Plattformunterschiede keine Auswirkungen haben sollten.
Joachim Sauer
2
@mstrap - der Punkt , er macht ist , dass es keine Anforderung für jeden Anbieter ihre Compiler produzieren genau die gleiche Bytecode auf verschiedenen Plattformen zu machen, nur dass die resultierende Bytecode zu denselben Ergebnissen. Da es keinen Standard / keine Spezifikation / Anforderung gibt, lautet die Antwort auf Ihre Frage "Es hängt vom jeweiligen Anbieter, Compiler und der Plattform ab".
Brian Roach
6

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.

mtk
quelle
Können Sie bitte einen detaillierteren Link geben?
Mstrap
Ich denke, mit "Plattform" beziehen sie sich auf die Java-Plattform, nicht auf das Betriebssystem. Wenn Sie javac 1.7 anweisen, 1.6-kompatible Klassendateien zu erstellen, gibt es natürlich einen Unterschied.
Mstrap
@mtk +1, um anzuzeigen, wie viele Eigenschaften für eine einzelne Klasse während der Kompilierung generiert werden.
Gaborsch
3

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.

Donal Fellows
quelle
2

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.

viniciusjssouza
quelle
3
Haben Sie eine Referenz dafür? Wie ich in den Fragenkommentaren sagte, ist dies definitiv nicht der Fall für C # , daher würde ich gerne eine Referenz sehen, die besagt, dass dies für Java der Fall ist. Ich denke insbesondere, dass ein Multithread-Compiler bei verschiedenen Läufen unterschiedliche Bezeichnernamen zuweisen kann.
RB.
1
Dies ist die Antwort auf meine Frage und was ich erwarten würde, aber ich stimme RB zu, dass eine Referenz dafür wichtig wäre.
Mstrap
Ich glaube das gleiche. Ich glaube nicht, dass Sie eine endgültige Referenz finden werden. Wenn es Ihnen wichtig ist, können Sie eine Studie durchführen. Sammeln Sie eine Reihe der führenden und probieren Sie sie auf verschiedenen Plattformen aus, um Open Source-Code zu kompilieren. Vergleichen Sie die Byte-Dateien. Veröffentlichen Sie das Ergebnis. Stellen Sie sicher, dass Sie hier einen Link einfügen.
Emory
1

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.

Kelly S. Französisch
quelle
In diesem Artikel wird erläutert, was passieren kann, wenn wir die Java-Version ändern. Die Frage des OP war, was passieren kann, wenn wir die Plattform innerhalb derselben Java-Version wechseln. Ansonsten ist es ein guter Fang.
Gaborsch
1
Es ist so nah wie ich finden konnte. Es gibt ein merkwürdiges Loch zwischen der Spezifikation der Sprache und der Spezifikation der JVM. Bisher musste ich das OP mit "Es gibt keine Garantie dafür, dass derselbe Java-Compiler denselben Bytecode erzeugt, wenn er auf einer anderen Plattform ausgeführt wird" beantworten.
Kelly S. French
1

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.

rai.skumar
quelle
Die Frage des OP war, ob die Klassendateien gleich oder "technisch gleich" waren.
Bdesham
Mich interessiert, ob sie identisch sind .
Mstrap
und Antwort ist ja. Was ich meine ist, dass sie möglicherweise nicht gleich sind, wenn Sie Byte für Byte vergleichen. Deshalb habe ich das Wort technisch gleich verwendet.
Rai.skumar
@bdesham wollte er wissen, ob sie identisch sind. Sie sind sich nicht sicher, was Sie unter "technisch gleich" verstanden haben ... ist das der Grund für eine Ablehnung?
rai.skumar
@ rai.skumar Ihre Antwort lautet im Wesentlichen: "Zwei Compiler erzeugen immer eine Ausgabe, die sich gleich verhält." Das ist natürlich wahr; Es ist die ganze Motivation der Java-Plattform. Das OP wollte wissen, ob der ausgegebene Code Byte für Byte identisch ist , was Sie in Ihrer Antwort nicht angesprochen haben.
Bdesham
1

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.

PhilipJoseParampettu
quelle
0

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.

Suzan Cioc
quelle
Beachten Sie, dass Java Sie nicht vor allen Plattformunterschieden schützt . Die Reihenfolge der Dateien, die beim Auflisten von Verzeichnisinhalten zurückgegeben werden, ist nicht definiert, und dies könnte möglicherweise Auswirkungen auf einen Compiler haben.
Joachim Sauer
0

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.

Addison überspringen
quelle
0

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!

Augustin Riedinger
quelle