Feststellen, Welche Classes ich aus einem JAR nutze?

[PFEdi]

Hallo,

Ich frage mich gerade, ob es eine einfache Möglichkeit gibt, in einem Java Projekt (Maven, JDK 1.8) für eine JAR fest zu stellen, welche Klassen (oder eigentlich auch andere Ressourcen) ich nutze?

Als Ideen fallen mir dazu ein:

1. Ich entferne die dependency aus meinen POM.xml -> Die IDE informiert mich wenn sie da was nicht auflösen kann -> ich sehe daher was fehlt.
   1. Problem 1: Können IDEs sowas
   2. Problem 2: Funktioniert das dann auch bei Transitiven Abhängigkeiten
2. Ich entferne die dependency aus meinen POM.xml -> Ich baue das Projekt -> der build schlägt fehl, weil nicht alle Abhängigkeiten da sind
   1. Problem 1: geht wohl nur bei build dependencies -> sonst muss ich zur Laufzeit schauen wo es Brösel gibt.
3. Ich entpacke das JAR -> erstelle eine Liste aller resourcen -> durchsuche meinen Code Danach
   1. Problem 1: Ich muss das mim Suchen auf jedenfall automatisieren weil sonst ist das ziemlich aufwändig.
   2. Problem 2: Das klappt wohl auch nur bei direkten Abhängigkeiten, nicht bei Transitiven

Gibt es noch andere Möglichkeiten?
Können das gängige IDEs? wenn ja wie?

Andere Folge Frage -> Kann ich zu einer Klasse im Code feststellen aus welchem JAR sie ist?


Ich hoffe ich habe mich klar ausgedrückt

 

[mihe7]

Andere Folge Frage -> Kann ich zu einer Klasse im Code feststellen aus welchem JAR sie ist?

Du kannst Java mit dem Flag -verbose starten, dann bekommst Du eine Auflistung aller geladenen Klassen. Zusammen mit grep bzw. find kannst Du also relativ einfach feststellen, wo eine Klasse herkommt:
java -verbose ... | grep "Klassenname" (bzw. unter Windows statt grep ggf. find verwenden)

Das Ergebnis sieht dann z. B. so aus:

[0.885s][info][class,load] com.github.mihe7.services.HelloForumGreeter source: file:/C:/Projekte/junk/forum/services/target/services-1.0-SNAPSHOT.jar

Die Klasse com.github.mihe7.services.HelloForumGreeter wurde also aus C:/Projekte/junk/forum/services/target/services-1.0-SNAPSHOT.jar geladen.

 

[Oneixee5]

Ich frage mal: Wozu brauchst du das? Das Risko, dass es zu Laufzeitfehlern kommt ist nicht unerheblich. Es gibt ja auch die Möglichkeit native Images zu erstellen. Dabei wird ja schon komprimiert und optimiert. Ich sehe da für eine eigene Implementierung eig. keinen Bedarf.

 

[KonradN]

Also generell ist das auch in meinen Augen bedenklich.
a) Gute Idee von @mihe7: Du siehst nur, was die aktuelle Ausführung benutzt hat. Aber da gilt dann die 80/20 Regel: 80% der Zeit ist der Code nur in 20% des Codes. Bei einer Ausführung ist also unklar, ob Du wirklich alle Abhängigkeiten auch wirklich benutzt hast. Die Gefahr ist also schon sehr groß, dass dann etwas fehlt.

b) was willst Du erreichen? Du sparst wenige Byte bis KB - mit hohem Risiko, dass etwas nicht geht? Da gibt es die Regel zu Optimierungen: Mach keine Optimierungen! (Und wenn Anforderungen nicht eingehalten werden, dann analysiere erst einmal, woran es liegt, bekomme die Problem-Stellen mit und finde dann saubere Lösungen!). Wenn Platz kritisch ist, dann ist evtl. GraalVM mit Native-Image eine Option, bei der Code native übersetzt wird. Nur um eine Option zu nennen.

c) Bei Ressourcen ist auch immer die Frage, was Du genau erreichen willst. Die Ressourcen weg zu lassen kann schnell Konsequenzen haben, die Du ggf. nicht mitbekommst. Die können ja durchaus optional geladen werden, z.B. nur, wenn eine bestimmte Sprache angezeigt werden soll oder wenn spezielle Datenbank-Updates erforderlich sind oder so.

Hier ist es also sehr wichtig, sich die Kosten und den Nutzen anzusehen. Was willst Du genau erreichen? Und was für Risiken gehst Du dabei ein?

Ansonsten zum Punkt: Feststellen, woher eine Klasse kommt: Entwicklungsumgebungen bieten in der Regel eine "Go to Implementation" Möglichkeit. Dann bekommst Du die Klasse angezeigt. Entweder direkt im Source wenn Du das mit herunter geladen hast oder es wird dekompiliert.

 

[mrBrown]

Auch eine Möglichkeit ist, einen Baum an Referenzierten Klassen aufzubauen, startend mit deinen kompilierten Klassen. Nutzbar ist dafür z.B. Jandex.

Problem aber auch hier: du findest nur statische Referenzen, alles was dynamisch (zB mit Serviceloader oder Reflection) läuft, übersiehst du damit. Je nachdem was man vorhat ist es aber potentiell als Ausgangspunkt nutzbar.

 

[Neumi5694]

Ich frage mal: Wozu brauchst du das? Das Risko, dass es zu Laufzeitfehlern kommt ist nicht unerheblich. Es gibt ja auch die Möglichkeit native Images zu erstellen. Dabei wird ja schon komprimiert und optimiert. Ich sehe da für eine eigene Implementierung eig. keinen Bedarf.

Und dabei werden ungenutzte Abhängigkeiten entfernt? Cool, wusste ich nicht. Muss ich mal probieren. Ich bin mir sicher, dass ich ein paar der früher genutzten Netty-Jars weglassen könnte.

 

[Oneixee5]

Well, one way to check for missing dependencies is to remove the dependency from your POM.xml file and let the IDE inform you if it cannot resolve something. This should work for both direct and transitive dependencies. However, this approach may not be comprehensive, as it only checks for missing dependencies that are directly referenced in your code.
thanks

... extra einen Nutzer für nervige ChatGPT-Antworten angelegt - sinnlos.