Wie entferne ich den Staub aus einer Bibliothek eines Drittanbieters?

Question

Dies ist möglicherweise keine bewährte Methode, aber es gibt Möglichkeiten, nicht verwendete Klassen aus den JAR-Dateien eines Drittanbieters zu entfernen.Etwas, das untersucht, wie meine Klassen die Bibliothek nutzen, eine Art Abdeckungsanalyse durchführt und dann ein weiteres Glas ausspuckt, in dem alle unberührten Klassen entfernt werden.

Offensichtlich gibt es damit Probleme.Insbesondere das von mir beschriebene Nutzungsszenario verwendet möglicherweise nicht immer alle Klassen.

Aber ist es grundsätzlich möglich, diese Probleme zu vernachlässigen?

Answer 1

Da ist ein Weg.

Das JarJar-Projekt erledigt diese AFAIR.Das erste Ziel des JarJar-Projekts besteht darin, die Einbettung von Bibliotheken von Drittanbietern in das eigene Jar zu ermöglichen und bei Bedarf die Paketstruktur zu ändern.Dadurch können nicht benötigte Klassen entfernt werden.

Schauen Sie es sich an http://code.google.com/p/jarjar/.

Hier ist ein Link zum Schrumpfen von Gläsern: http://sixlegs.com/blog/java/jarjar-keep.html

Answer 2

In Ant gibt es ein Tool namens Classfileset.Sie geben die Liste der Stammklassen an, von denen Sie wissen, dass Sie sie benötigen, und dann analysiert das Klassendateiset rekursiv ihren Code, um alle Abhängigkeiten zu finden.

Alternativ könnten Sie eine gute Testsuite entwickeln, die alle von Ihnen benötigten Funktionen ausführt, und Ihre Tests dann mit einem Testabdeckungstool ausführen.Das Tool zeigt Ihnen an, welche Klassen (und welche Anweisungen darin) tatsächlich verwendet wurden.Dadurch erhalten Sie möglicherweise einen noch kleineren Codesatz als bei der statischen Analyse.

Answer 3

ich benutze ProGuard dafür.Es ist nicht nur ein ausgezeichneter Verschleierer, sondern verfügt auch über eine Code-Verkleinerungsphase, die mehrere JARs kombinieren und dann alle nicht verwendeten Klassen oder Klassenmitglieder entfernen kann.Es macht ein exzellent Job beim Schrumpfen.

Answer 4

Bei einem früheren Job habe ich einen Java-Obfuscator verwendet, der nicht nur den Code verschleierte, sondern auch nicht verwendete Klassen und Methoden entfernte.Wenn Sie „Class.byName“ oder eine andere Art von Reflektionsvorgang ausgeführt haben, mussten Sie dies dem Obfuscator mitteilen, da dieser durch die Überprüfung des Codes nicht erkennen konnte, welche Klassen oder Methoden durch Reflektion aufgerufen wurden.

Das Problem besteht natürlich darin, dass Sie nicht wissen, ob andere Teile der Bibliothek eines Drittanbieters eine Reflexion durchführen. Daher kann das Entfernen einer „nicht verwendeten“ Klasse dazu führen, dass in einem unklaren Fall, den Sie nicht getestet haben, etwas kaputt geht.

Answer 5

jar ist nur eine ZIP-Datei, also denke ich, dass Sie das können.Wenn Sie an die Quelle gelangen könnten, wäre es sauberer.Versuchen Sie vielleicht, die Klasse zu zerlegen?

Answer 6

Kann dies zusätzlich zu dieser Frage die Leistung verbessern?Da die nicht verwendeten Klassen nicht JIT-kompiliert werden würden, was die Startzeit verbessert, oder erkennt Java dies automatisch beim Kompilieren in Bytecode und kümmert sich nicht einmal um den Code, der nicht verwendet wird?

Answer 7

Das wäre ein interessantes Projekt (hat es schon jemand gemacht?)

Ich gehe davon aus, dass Sie dem Tool Ihr(e) Glas(e) als Ausgangspunkt und das Bibliotheksglas zum Aufräumen geben würden.Mithilfe von Reflektion könnte ermittelt werden, auf welche Klassen Ihre JAR(s) direkt verweisen und welche indirekt im Aufrufbaum verwendet werden (dies ist überhaupt nicht trivial, aber machbar).Wenn an einer der beiden Stellen auf Reflexionscode stößt, sollte eine sehr laute Warnung ausgegeben werden.