Benötigte Klassen herausfinden

[erazor2106]

Hallo Leute,

undzwar binde ich in einem Softwareprojekt eine Reihe von Klassen ein, darunter auch aus anderen für mich neue Projekte. Es ist zwingend notwendig alle benötigten Klassen in einem JAR-File zusammen zu haben, welche nicht im Java Standard enthalten sind. Eine Einbindung über Umgebungsvariablen und ähnliches ist nicht erwünscht.

Binde ich z.b. die die Klasse com.xx.yyy.zzz ein kopiere ich zzz in mein JAR-File, allerdings benötigt zzz wiederum andere Klassen aus com.aaa.bbb usw. Wie kann ich also ermitteln welche Klassen wirklich benötigt werden ohne den ganzen Ordner einbinden zu müssen.

Vielen Dank und viele Grüße erazor

 

[Tomate_Salat]

Ich würde nicht versuchen meine Klassen zu filtern. Wenn du doch mal eine Abhängigkeit übersiehst, dann kracht es.

Mit was arbeitest du? Mit Eclipse kannst du über den Export-Wizard regeln, wie deine jar aussehen soll und welche Projekte mit eingebunden werden. Ansonsten könntest du dir ant anschauen. Mit dem build-script kannst du regeln erstellen, welche Klassen/Ordner in welche jar kommen.

 

[erazor2106]

Ich arbeite an diesem Projekt lediglich mit dem Java-Editor.
Deine Vorschläge klingen gut, aber ich würde es gern erstmal mit dem Filtern probieren.

Womit könnte ich also sehen welche Klassen geladen wurden?

 

[Tomate_Salat]

Naja, zum Java-Editor kann ich dir nicht viel sagen(da nie benutzt und ich werde ihn auch nie nutzen). Nach wie vor: Filtern ist ein gefährlicher und nicht notwendiger Vorgang. Wieso willst du dir den den Aufwand machen, diese Klassen rauszuwerfen? Wenn das nicht mal deine Projekte sind, weißt du vllt nicht einmal welche technologien darin verwendet werden. Sobald ein Classloader seine Informationen aus einem externen config-file bezieht hast du verloren. Liefere einfach die Klassen mit aus, die existieren bestimmt nicht ohne Grund.

 

[Michael...]

Ich arbeite an diesem Projekt lediglich mit dem Java-Editor.
Deine Vorschläge klingen gut, aber ich würde es gern erstmal mit dem Filtern probieren.

Womit könnte ich also sehen welche Klassen geladen wurden?

Ich denke das ist, ganz schön kritisch. Bin zwar nicht der Fan von sowas und sehe auch nicht unbedingt die Notwendigkeit, aber letztendlich würde ich alle Klassen aller eingebunden Bibliotheken mit in das eigene Jar packen. Dir ist hoffentlich bewusst, dass die von Dir genutzten Klassen aus anderen Paketen selbst wiederum weitere Klassen nutzen und kannst Du ausschließen, dass nicht eventuell zur Laufzeit z.B. per Reflection weitere Klassen nachgeladen werden?

 

[erazor2106]

Dir ist hoffentlich bewusst, dass die von Dir genutzten Klassen aus anderen Paketen selbst wiederum weitere Klassen nutzen

genau das ist der Knackpunkt. Das File soll allerdings über ein Netzwerk an mehrere Rechner verteilt werden, mit der Auflage es möglichst klein zu halten. Von den Funktionen der Fremdklassen nutze ich nur einen Bruchteil, welcher sich auch nicht vergrößern wird, daher meine Frage

 

[maki]

Darfst du das denn?

Nicht jede Lizenz erlaubt sowas, ist schliesslich eien Änderung an den Jars wenn man sie zusammenwürfelt, manche Lizenzen mutieren dann zu sog. "Copy Left" Lizenzen wie die LGPL, diese wird dadurch zu GPL, manche Lizenzen verbieten das grundsätzlich.

So einen Aufwand zu betreiben und Risiken einzugehen um ein paar KB/MB zu sparen?
Ist imho nicht durchdacht...

 

[erazor2106]

Darfst du das denn?

Ja, das stellt in diesem Falle kein Problem dar. Ich bin mit der Variante auch nicht zufrieden, aber mir fällt keine andere Möglichkeit ein um die JAR-Datei möglichst klein zu halten

 

[Dow Jones]

Obfuscators wie ProGuard behaupten von sich sie könnten nicht benötigte Klassen herausfiltern. Wie zuverlässig das funktioniert kann ich dir nicht sagen, aber einen Versuch ist's ja allemal wert.

 

[Cola_Colin]

ProGuard ist auf jeden Fall fähig, eine jar deutlich zu verkleinern. Einen Versuch wäre es wert.

 

[Wildcard]

ProGuard ist auf jeden Fall fähig, eine jar deutlich zu verkleinern. Einen Versuch wäre es wert.

Mit dem 'kleinen' Nachteil das danach alle Stacktraces nutzlos sind.
Kein Tool kann deterministisch herausfinden welche Klassen benötigt werden, und welche nicht.
Da stehen Dinge wie Serialisierung und Reflection im Weg.
Jars auf diese Art zu zerpflücken kann eigentlich nur im Chaos enden.

 

[Tomate_Salat]

Jars auf diese Art zu zerpflücken kann eigentlich nur im Chaos enden.

Sehe ich genauso. Um 5 kb zu sparen die Stabilität eines Produktes aufs spiel zu setzen ist imho definitiv der falsche Weg.