Wie kann ich alle existierenden Java-Klassen anzeigen lassen?

[theuserbl]

Hi!
Gibt es eine Möglichkeit alle existierenden Java-Klassen anzeigen zu lassen?



Um es etwas näher zu beschreiben. Angenommen ich habe ein Programm wie

import javax.swing.*;

public class Test {
  public static void main(String[] args) {
   JFrame f = new JFrame("Mein Fenster");
   JButton b = new JButton("Button");
   f.add(b);
  }
}

dann greift das Programm zur Laufzeit auf alle im Classpath existierenden Verzeichnisse und Jar-Dateien zu (in diesem Fall: rt.jar) und guckt, ob es die Klassen "javax.swing.JFrame" und "javax,swing.JButton" gibt.
Man kann auch prüfen, ob diese Klasse vorhanden ist.

public class Test {

  public static void main(String[] args) {
  
    String s1 = "javax.swing.JButton";
    String s2 = "javax.swing.GibtEsNicht";
    
    System.out.println(existClass(s1));
    System.out.println(existClass(s2));
  
  }

  public static boolean existClass (String name) {
     try {
       Class tmp = Class.forName(name);
       return true;
     } catch (ClassNotFoundException e) {
       return false;
     }
  }

}

Ich will aber alle Klassen im Package javax.swing erhalten, ohne dessen Namen vorher zu wissen. Und generell will ich alle Klassen aufgelistet haben.

Ist das möglich?

Bisher habe ich im Internet immer nur Beispiele gefunden, wo die Klassen ausgegeben wurden, die aktuell geladen wurden. Also die für das aktuelle Programm zum Ausführen nötig sind.
Ich will aber alle Klassen aufgelistet haben, die mir zur Verfügung stehen.


Grüße
theuserbl

 

[theuserbl]

Java Platform SE 7 :bae:

Ich will das schon gerne zur Laufzeit ausgegeben haben.
Daß ich in der Dokumentation alle Klassen finde, weiß ich schon.
Alternativ könnte ich dann auch diue Jar-Dateien entpacken und nachsehen.

Aber ich will es nun mal zur Laufzeit von einem Java-Programm aufgelistet bekommen. (somit auch nicht auf die Idee kjommen, mir irgendwelche JVM-Flags zu nennen, die dann alles auflisten)

Grüße
theuserbl

 

[maki]

Vielleicht hilft ja das hier:
[JavaSpecialists 121] - How Deep is Your Hierarchy?

 

[theuserbl]

Vielleicht hilft ja das hier:
[JavaSpecialists 121] - How Deep is Your Hierarchy?

Auch wenn ich kein griechisch kann, so sieht es danach aus, daß dort einfach nur zu einer beliebigen Klasse die Superclass ausgeben wird. Und von der Superclass wieder die Superclass. Bis man bei java.lang.Object angekommen ist.
ALLE zur Verfügung stehenden Klassen werden jedoch NICHT angezeigt.

 

[maki]

Auch wenn ich kein griechisch kann,

Hehe.. keine Ahnung wie das passiert ist??
Hab den Link korrigiert.

so sieht es danach aus, daß dort einfach nur zu einer beliebigen Klasse die Superclass ausgeben wird. Und von der Superclass wieder die Superclass. Bis man bei java.lang.Object angekommen ist.
ALLE zur Verfügung stehenden Klassen werden jedoch NICHT angezeigt.

Dort wird "einfach nur" nach der tiefsten Klassenhierarchie über den kompletten Classpath gesucht, d.h. Jars werden geladen und alle Klassen geprüft.
Dass du nicht die tiefe der Hierarchie zählen musst ist ja hoffentlich klar

 

[tröööt]

also ich hab gerade mal den ClassLoader.getSystemClassLoader() mit reflections völlig auseinander genommen ... mal von abgesehen das ich irgendwann selbst nicht mehr so wirklich durchgeblickt habe und mir die klassen auch irgendwann nicht mehr genug informationen gaben habe ich es nicht geschafft irgendwo einen bezug zum rt.jar herstellen zu können ...

der SystemClassLoader ist zwar eine sub-klasse von URLClassLoader ... aber auch der gibt irgendwann nichts mehr her ...

ich hab mir jetzt auch nicht die mühe gemacht einen rekursiven alogrithmus zu schreiben der jede klasse bis zu Object oder den primitives auseinander nimmt .. aber wenn irgendwo im SystemClassLoader was versteckt ist dann sehr gut ...

für mich stellt sich eigentlich eher eine gegenfrage

@TO
wozu das ganze überhaupt ?

 

[Gast2]

Moin,

Link 1 - http://www.fantasya-pbem.de/source/Fantasya2/beta/src/de/x8bit/Fantasya/util/PackageLister.java
basierend auf
Link 2 - Get All Classes Within A Package | DZone

wozu das ganze überhaupt ?

Variante 1 - von Hand ständig alle verfügbaren Items etc. in einer Liste führen
Problem 1 - vergessen von Klassen, etc.

Variante 2 - über ein Script die Liste automatisch erstellen lassen
Problem 2 - Vergessen das Script zu starten wenn neue Items, Gebäude etc. hinzukommen

Variante 3 - alles wird zur Laufzeit eingelesen
Problem 3 - Welches??

hand, mogel

 

[ssoul26]

http://www.java-forum.org/allgemeine-java-themen/141893-auto-import-generierte-java-klasse.html

Pass des da weng an, und es läuft

 

[tröööt]

Variante 1 - von Hand ständig alle verfügbaren Items etc. in einer Liste führen
Problem 1 - vergessen von Klassen, etc.

Variante 2 - über ein Script die Liste automatisch erstellen lassen
Problem 2 - Vergessen das Script zu starten wenn neue Items, Gebäude etc. hinzukommen

Variante 3 - alles wird zur Laufzeit eingelesen
Problem 3 - Welches??

hand, mogel

meine frage war darauf bezogen welchen sinn es macht alle klassen der kompletten SE-API ermitteln zu wollen ... von den ganzen nicht-öffentlichen implementierungen mal abgesehen ...

du nimmst hier ein konkretes beispiel um eine handvoll elemente automatisch einer liste hinzuzufügen ... das kann ich auch und da ist mir der sinn auch klar ... aber das hat nur sehr wenig mit der frage von TO zu tun ...

 

[theuserbl]

Danke für Eure Hilfe.
Was ich anhand der Links zu Beispielprogrammen von mogel und ssoul26 sehe ist, daß es keine einfache Möglichkeit gibt, per Reflection alle Klassen aufzulisten. Also muß man ein Programm schreiben, daß in jede eingebundene Jar-Datei guckt, ähnlich dem, wie es in den Beispiel-Programmen beschrieben wurde.

meine frage war darauf bezogen welchen sinn es macht alle klassen der kompletten SE-API ermitteln zu wollen ... von den ganzen nicht-öffentlichen implementierungen mal abgesehen ...

Mein Programm besteht aus einer Jar-Datei. Und alle Klassen eines bestimmten Packages will ich in eine andere, neu erstellte Jar-Datei, kopieren (So eine Art Compiler mit integrierter Runtime).

Desweiteren will ich in einem Editor so etwas wie Code-Completion haben.
Z.B:

Du gibst in den Editor

import

ein. Daraufhin öffnet sich ein rahmenloses Tootip-ähnliches Auswahlfenster, in dem die Packages com, java, javax, org, sun und sunw stehen.
Du wählst "javax" aus, wodrauf im Editor

import javax.

steht und sich erneut ein rahmenloses Fenster öffnet, in dem die Packages accessibility, activation, activity, annotation, imageio, .... , swing, ... etc. zur Verfügunmg stehen.
Du wählst "swing" aus.
Daraufhin steht im Editor

import javax.swing.

und es öffnet sich wieder ein rahmenloses Fenster, in dem die Packages border, colorchooser, event, filechooser, plaf, table, text, tree und undo stehen. Sowie die Klassen AbstractAction, AbstractButton, AbstractCellEditor, ... JButton, ... etc.
Du wählst "JButton" aus, und im Editor steht letztendlich

import javax.swing.JButton;

Klar ist es nicht umständlich, wenn man nur in rt.jar nachgucken muß,
Aber wenn das ext-Verzeichnis Deiner Java-Installation viele Jar-Dateien hat, der Classpath noch einige, sowie zusätzliche Verzeichnisse, dann wird es umständlich.
Packagenamen wie com oder org besitzen viele Jar-Dateien. Und wenn man das auswählt, müssen alle Unterpackages und Klassen aus allen Jar-Dateien und Classpath-Anganben dann angezeigt werden, als befänden sie sich alle am selben Ort.
Daher hatte ich gehofft, nicht den Weg über die einzelnen Jar-Dateien gehen zu müssen, so daß alle Klassen mir bereits so zugänglich sind, als befänden sie sich am gleichen Ort.
Wie ich nun jedoch erfahren hatte, ist dem nicht so. Denn wenn es einen einfachen Weg gäbe, würde in den verlinkten Programmen nicht eine Lösung beschrieben stehen, die den umständlicheren Weg wählt.

Grüße
theuserbl

 

[tröööt]

ja gut ... sowas macht dann schon irgendwo sinn ... (auch wenn ich IDEs grundsätzlich ablehne) ...

wie gesagt : ich hab versucht mit reflections die vm soweit auseinander zu nehmen um da an irgendwas ranzukommen ... aber auch wenn man rekursiv wirklich alles ausgeben lässt kommt man nicht sehr viel weiter ... da halt solche parameter in den system-properties stehen ... also muss man zusätzlich auch diese mit einbeziehen ... dann mag es sein das man mit reflections weiter kommt ...

was die platzierung von "system-libs" in "ext" angeht ... naja ... persönlich halte ich es für ein relikt aus alten zeiten und teilweise faulheit sowie nicht-wissen sowohl von entwicklern als auch usern richtig mit classpath umzugehen und die klassen so zu schreiben das diese sich daraus alle infos holen ... sehe darin irgendwie keinen tieferen sinn ... zu mal java meist im system-ordner "program files" liegt und man somit admin-rechte benötigt um die libs dort reinzupacken ... womit viele ebenfalls schon wieder überfordert sind ...

ob man wirklich alle gerade zur runtime erreichbaren klassen indizieren sollte ... naja ... wie gesagt : man hat dann viel mit den implementierungen zu tun ... ich würde versuchen mich auf public-schnittstellen zu beschränken ... wobei natürlich gerade bei 3rd party libs nicht immer source und/oder doc beiliegen ...

kannst dich ja mal in den source von IDEs umsehen wie die es machen ... oder noch mal versuchen google etwas zu entlocken ... aber dass das hier jemand mal eben so ausm stehgreif weis .. puh ... schwierig ...