Ich möchte meine 20-jar-Anwendung als pack200-Dateien verteilen, aber ich muss auch Dateiprüfsummen zur Validierung bereitstellen.
Da ich paranoid bin (danke, JWS), hätte ich gerne auch Prüfsummen auf dekomprimierten Dateien.
Ist die Dekomprimierung von pack200 deterministisch und liefert identische Ergebnisse auf allen Plattformen (Win / Mac / Linux über Kreuz 32/64 Bit)?
Mit anderen Worten, kann ich die Dateien auf einem Computer dekomprimieren, ihre Prüfsummen berechnen und erwarten, dass sie immer identisch sind, wenn sie auf anderen Computern dekomprimiert werden?
BEARBEITEN : Danke für die Kommentare. Ich suche nach einer harten Spezifikation, um dies zu bestätigen oder zu leugnen.
Die Annahme von Annahmen (selbst auf der Grundlage von Tests an einigen wenigen Maschinen) bedeutet Risiko.
Implementierungen können zwischen Plattformen und Java-Versionen variieren. Selbst die gleiche Implementierung kann zu unterschiedlichen Ergebnissen führen (Denken Sie an die Reihenfolge der Elemente im ZIP-Verzeichnis?). Deshalb frage ich, ob es für alle Plattformen und Java-Versionen gleich ist AND deterministisch .
Wenn dies nicht bestätigt oder abgelehnt werden kann, wie wäre es mit dieser Nachfolgefrage? Wie kann ich überprüfen, ob nach der Dekomprimierung ein Jar gültig ist? Wenn man an halbfertige Dateien denkt, korrumpieren Gammastrahlen einzelne Bits in der Datei und so weiter.
Ich suche nach einer harten Spezifikation, um dies zu bestätigen oder zu leugnen.
@ Travis 'Antwort besagt, dass die rekonstruierten Klassendateien nicht Byte für Byte identisch mit den ursprünglichen Klassendateien sind, was (offensichtlich) bedeutet, dass die JAR-Dateien auch nicht identisch sind.
Außerdem heißt es in keiner Dokumentation, dass unpack200 auf allen Plattformen identische JAR-Dateien erzeugt, was ich nicht erwarten würde. (Zu Beginn werden auf verschiedenen Plattformen verschiedene Versionen von unpack200 ...) laufen.
Wenn dies nicht bestätigt oder abgelehnt werden kann, wie wäre es mit dieser Nachfolgefrage? Wie kann ich überprüfen, ob nach der Dekomprimierung ein Jar gültig ist? Wenn man an halbfertige Dateien denkt, korrumpieren Gammastrahlen einzelne Bits in der Datei und so weiter.
Ich denke nicht, dass es auch einen Weg gibt, dies zu tun. Wenn wir davon ausgehen, dass regenerierte JAR-Dateien plattformabhängig sein können, haben wir keine Basislinie, aus der eine Prüfsumme generiert werden könnte.
Ich denke, Ihre beste Wette besteht darin, eine qualitativ hochwertige Prüfsumme der pack200-Datei zu senden und darauf zu vertrauen, dass das entpacken200 entweder korrekt funktioniert oder einen Nicht-Null-Exit-Code setzt, wenn es fehlschlägt ... wie jedes korrekt geschriebene Dienstprogramm mach das.
Übrigens, wenn Sie sich Sorgen wegen zufälliger Fehler machen, wie werden Sie "kosmische Strahlen" -Effekte erkennen, wenn die JVM Code aus den JAR-Dateien lädt? Der vernünftige Ansatz besteht darin, ECC-Speicher usw. zu verwenden und dies der Hardware zu überlassen.
Denken Sie das ist , was Sie suchen.
... Für jedes Pack200-Archiv muss jedoch jeder Dekomprimierer für jede übertragene Klassendatei ein bestimmtes Byte-Bild erzeugen. Diese Anforderung wird an Dekomprimierer gestellt, um es Kompressoren zu ermöglichen, Informationen zu übertragen, wie z. B. Nachrichtenauszüge, die sich auf den eventuellen byteweisen Inhalt übertragener Klassendateien beziehen. Dieser Abschnitt beschreibt die Einschränkungen, die für jeden Dekomprimierer gelten, der den byteweisen Inhalt seiner Ausgabedateien zu einer wohldefinierten Funktion seiner Eingabe macht.
Dies bedeutet, dass Sie tun können, was Sie hier tun möchten. JNF / Pack200 verwendet Konstanten, die von mehreren Klassen gemeinsam genutzt werden, und komprimiert die .class-Dateien intelligent. Dieser Teil des Standards besagt jedoch, dass es zwar möglich wäre, Klassendateien auf verschiedene Arten zu rekonstruieren, dies jedoch zu keiner Verifizierung führen würde diese Dateien mit Digests. Um dieses Problem zu vermeiden, legt Pack200 explizit fest, wie die Dekodierung funktionieren soll. Wenn also die .class-Ausgabedateien nicht mit den .class-Eingabedateien identisch sind, stimmen die ausgegebenen .class-Dateien jedes Pack200-Dekompressors mit allen anderen .class-Dateien des Pack200-Dekomprimierers überein / p>
Am besten packen Sie sie mit Pack200, entpacken sie, machen dann MD5 oder einen vergleichbaren Digest-Algorithmus und überprüfen damit die entpackten Dateien.
Ich hoffe, das beantwortet Ihre Frage!
Tags und Links java