Identische Java-Quellen kompilieren zu unterschiedlichen Binärklassen

Question

Kann jemand erklären, wie identische Java-Quellen zu binären unterschiedlichen Klassen-Dateien kompilieren können?

Die Frage stellt sich aus der folgenden Situation:

Wir haben eine ziemlich große Anwendung (800+ Klassen), die verzweigt wurde, neu strukturiert dann zurück in den Kofferraum reintegriert. Vor der Reintegration haben wir den Stamm in den Zweig integriert, was eine Standardprozedur ist.

Das Endergebnis war eine Reihe von Verzeichnissen mit den Zweigquellen und eine Reihe von Verzeichnissen mit den Stammquellen. Mit Beyond Compare konnten wir feststellen, dass beide Quellen identisch waren. Beim Kompilieren (dasselbe JDK unter Verwendung von Maven in IntelliJ v11) stellten wir jedoch fest, dass ungefähr ein Dutzend der Klassendateien unterschiedlich waren.

Als wir die Quelle für jedes Paar scheinbar unterschiedlicher Klassendateien dekompiliert haben, haben wir am Ende die gleiche Java-Quelle gefunden, was das Endergebnis betrifft, scheint es nicht wichtig zu sein. Aber warum sind nur ein paar Dateien unterschiedlich?

Danke.

---

Weitere Gedanken:

Wenn Maven/javac Dateien in einer anderen Reihenfolge kompiliert, dass das Endergebnis beeinflussen könnten?

Answer 1

Unter der Annahme, dass die JDKs und Kompilierungsoptionen identisch sind, kann ich mir vorstellen 5 möglich Quellen Unterschiede:

1. Zeitstempel - jede Klasse Dateikompilierung Zeitstempel enthält. Wenn Sie die Compilations nicht genau zur gleichen Zeit ausführen, haben unterschiedliche Compilations derselben Datei unterschiedliche Zeitstempel.

2. Quell-Dateipfade - jede Klassendatei enthält den Pfadnamen der Quelldatei. Wenn Sie zwei Bäume mit unterschiedlichen Pfadnamen kompilieren, enthalten die Klassendateien unterschiedliche Quellpfadnamen.

3. Werte der eingeführten Kompilierung Zeitkonstanten - wenn eine Klasse A eine Kompilierung Zeitkonstante in einer anderen Klasse B (siehe JLS für die Definition eines „Übersetzen Zeitkonstante“), wird der Wert der Konstante eingebaut definierte verwendet wird in A s Klassendatei. Also, wenn Sie A gegen verschiedene Versionen von B kompilieren (mit unterschiedlichen Werten für die Konstanten), wird der Code von A wahrscheinlich anders sein.

4. Unterschiede in Signaturen externer Klassen/Methoden; z.B. wenn Sie eine Abhängigkeitsversion in einer Ihrer POM-Dateien geändert haben.

5. Unterschiede in den Klassenpfaden können zu Unterschieden in der Reihenfolge führen, in der importierte Klassen gefunden werden, die zu nicht signifikanten Unterschieden in der Reihenfolge der Einträge im Constant Pool der Klassendatei führen können. Dies könnte aufgrund Dinge passieren wie:

   • Dateien in einer anderen Reihenfolge in den Verzeichnissen von externen JAR-Dateien erscheinen,
   • Dateien in unterschiedlicher Reihenfolge auf die Quelle durch kompilierten Dateien in einer anderen Reihenfolge, wenn die Build-Tool zu sein Iteriert sie oder
   • Parallelität im Build (wenn Sie das aktiviert haben).

Beachten Sie, dass Sie normalerweise nicht die tatsächliche Reihenfolge der Dateien in FS-Verzeichnisse sehen, da Tools wie ls und dir Standard die Einträge zum Sortieren bevor sie angezeigt werden.

---

sollte ich hinzufügen, dass der erste Schritt, um die Ursache für die Unterschiede zu identifizieren, genau zu arbeiten, was sie sind. Sie müssen wahrscheinlich (müssen) das auf die harte Tour machen - indem Sie manuell ein Paar Klassendateien dekodieren, um die Orte zu identifizieren, wo sie tatsächlich Unterschiede haben ... und was die Unterschiede tatsächlich bedeuten.

Answer 2

Verschiedene JDK erzeugen verschiedene Binärklassen (Optimierungen, aber auch Klassenversionsnummer). Es gibt auch Kompilierungsoptionen (ein JDK kompiliert möglicherweise in einem älteren Format oder es kann Debuginformationen hinzufügen).

Answer 3

Verschiedene Java-Versionen können verschiedene Metadaten hinzufügen, die von einem Decompiler oft ignoriert werden.

Ich schlage vor, Sie versuchen, javap -c -v für weitere Details in einer Datei verwenden. Wenn dies nicht hilft, können Sie den ASMifierClassVisitor verwenden, der jedes Byte untersucht.

Answer 4

Wenn Sie Vergleichen ohne Vergleich verwenden, wird der Vergleich basierend auf dem Inhalt der Dateien durchgeführt. Aber im Build-Prozess wird nur der Zeitstempel der Quelldateien auf Änderungen überprüft. Wenn sich das Datum der letzten Änderung Ihrer Quelldatei ändert, wird es neu kompiliert.

Answer 5

dasselbe JDK kann auch unterschiedliche Ausgaben haben, abhängig davon, wie Sie kompilieren. können Sie mit oder ohne Debug-Informationen kompilieren, können Sie kompilieren, um in einer älteren Version zu laufen, jede Option führt zu anderen Klassen.