Nicht verwendete Klassen aus großem Package löschen

[Agent]

Hallo,

bei der Verwendung von größeren packages kommt es gerne vor, dass man eigentlich nur einen sehr sehr kleinen Anteil dieses packages braucht. Ich frage mich gerade, wie ich die restlichen .java-Dateien am zeitsparendsten löschen kann. Hierbei hätte ich zwei fragen:

1) Wenn ich meine main-Klasse compiliere, werden nur diejenigen .class-Dateien erstellt, die von meiner main-Klasse abhängig sind. Die restlichen .java-Dateien, die keine zugehörige .class Datei haben, kann ich quasi löschen. Hat jemand eine Idee, wie sich dieses Löschen unter Linux (openSUSE 11.1) am einfachsten automatisieren lässt?

2) Mit der oben beschriebenen Methode kann ich nur die Klassen löschen, die von absolut keiner Methode einer verwendeten Klasse abhängig sind. Nun kann aber folgendes passieren, was sich am Besten an einem Beispiel erklären lässt:

Beispiel: Die Hauptklasse verwendet Methode A.b aus Klasse A. Die Methode A.c aus Klasse A wird nicht verwendet. A.c erstellt aber ein Objekt einer Klasse B. Klasse B wird somit compiliert obwohl sie eigentlich gar nicht gebraucht wird.

Hat jemand eine Idee, wie ich in diesem Beispiel am einfachsten herausbekomme, dass Methode A.c und Klasse B nicht verwendet werden? Gibt es eine Möglichkeit, diese automatisch zu löschen?

 

[Noctarius]

Von Anfang an sinnvoll in Packages verteilen. Nachträglich kann man zwar die Class-Files löschen, die Methode finde ich aber absolut unschön.

Wenn du Klassen nicht mehr brauchst schmeiss sie halt komplett weg, wenn es dir darum geht den Zugriff "zu sperren" ist OSGi dein Anlaufpunkt.

 

[Landei]

Es gibt sowas (JBuilder kann das, Eclipse glaub ich auch), aber es ist gefährlich. Angenommen, du brauchst eine Datenbankverbindung mit JDBC. Dann kann man den DB-Treiber z.B. so spezifizieren:

Class.forName("mein.toller.db.Treiber");
//Connection mit dem Treiber aufbauen usw.

Es wird keine Methode an Treiber direkt aufgerufen, du findest ihn nicht über irgendwelche Aufrufketten. Trotzdem darf er nicht aus dem Package entfernt werden, sonst BUMM...

 

[tuxedo]

Die Frage ist viel eher:

Lohnt sich der Aufwand? Wieviele Megabytes sparst du damit ein? Im Zeitalter des DSL Anschlusses kommts nicht so drauf an ob ein Download jetzt 8 oder nur 5MB hat.

Ansonsten kann ich Noctarius nur zustimmen:

Wenn sich's um eigene Klassen handelt: Vorher schon gut sortieren. Eine "Eierlegende Wollmilchsaubibliothek" aus der man dann 85% rauslöscht bringt nix. Dann lieber 5 Bibliotheken daraus machen und nur 2 davon verwenden (jetzt nur so als Beispiel).

Aber um nochmal aufs löschen zurück zu kommen:
Spätestens bei Reflection und Co. wird's mit dem löschen von vermeintlich nicht gebrauchten Klassen "etwas" schwieriger ... Aber ich vermute mal da bist du noch nicht angelangt.

- Alex

 

[Verjigorm]

Das FatJar-Plugin von Eclipse macht übrigends genau sowas.
Es packt nur die Klassen zusammen, die auch wirklich im Programm benötigt werden.
Hat man 20 Jars includet von der man jeweils nur 1% braucht ist der Unterschied schon gewaltig.

Wenn ich mein Projekt normal erstelle sind es alles zusammen ~18mb
Fatjar macht eine Jar mit 2MB

Ist natürlich mit Vorsicht zu geniesen, wegen eventueller Lizensrechte

 

[maki]

Ist natürlich mit Vorsicht zu geniesen, wegen eventueller Lizensrechte

Nicht nur dass, auch bei Reflection/DI funktzioniert das nicht mehr.


Ich bin auch sehr dafür jars so zu verwenden wie sie kommen, alles andere geht auf Dauer nicht gut.

 

[Wildcard]

Das FatJar-Plugin von Eclipse macht übrigends genau sowas.
Es packt nur die Klassen zusammen, die auch wirklich im Programm benötigt werden.
Hat man 20 Jars includet von der man jeweils nur 1% braucht ist der Unterschied schon gewaltig.

In der Doku finde ich keinen Hinweis auf dieses Verhalten und IMO wäre das auch viel zu riskant.
Davon abgesehen ist FatJAR mittlerweile obsolete, da dessen Funktionalität in Eclipse 3.4 als Runnable Jar zur Verfügung steht und mit Eclipse 3.5 ein Jar Export hinzukommt der einen eigenen Jar-in-Jar Classloader ins Archiv injeziert.

 

[Agent]

@Wildcard: Ich finde da auch keinen Hinweis dass FatJar das kann
@tuxedo: Ob sich der Aufwand lohnt oder nicht ist nicht die Frage. Wahrscheinlich tut er das nicht. In meinem Fall geht es hier aber nicht um den Speichergewinn, sondern darum, dass ich dieses fremde package (als Student) für mein assignment nutzen darf, aber aufs Notwendigste kürzen muss.

 

[Verjigorm]

Davon abgesehen ist FatJAR mittlerweile obsolete, da dessen Funktionalität in Eclipse 3.4 als Runnable Jar zur Verfügung steht und mit Eclipse 3.5 ein Jar Export hinzukommt der einen eigenen Jar-in-Jar Classloader ins Archiv injeziert.

Also bei keinem unserer 2 Projekte die wir zurzeit in Betrieb haben funktioniert dieser Jar Exorter so wie FatJar

 

[Wildcard]

Also bei keinem unserer 2 Projekte die wir zurzeit in Betrieb haben funktioniert dieser Jar Exorter so wie FatJar

Das ist auch wirklich nur für kleine Projekte oder Quick'n'Dirty Demos gedacht.