Wichtigste Klassen der JRE.

[Volvagia]

Ich denke, das Größte Problem für schöne Java-Codes ist, dass man viele der Klassen aus der JRE nicht kennt. Deshalb baut man sich Konstrukte, die eigendlich in der Funktion schon vorhanden und im großen und ganzen oft nicht so gut wie die von Sun/Oracle sind. Beispielweiße habe ich von der LinkedBlockingQueue nur durch reinen Zufall hier im Forum erfahren. Darum wollte ich einige Klassen daraus auflisten. Es sind derzeit nur die, die mir jetzt eingefallen sind, aber wäre natürlich nett, wenn ihr selbst welche nennt, ich kenne auch nur einen Bruchteil des JRE.

Allgemein:

Toolkit: Einige Servicefunktionen, wie z. B. das Erkennen der Bildschirmauflösung.
StringBuffer: Um mehrere Strings zusammenzuführen. (Leistungsstärker als concat und "+" bei mehr als 2 Verkettungen.)
StringBuilder: Ähnlich zu StringBuffer, aber nicht syncronisiert. (Schneller aber Probleme bei multiblen Zugriff.)
Math: Sammlung von mathematischen Funktionen (Sinus, Cosinus, min, max..) und Konstanten. (PI, eulerische Zahl.)
Thread: Native Threadklass für paralelle Abläufe.
Executors: Factory für ExecutorService.
ExecutorService: Zum starten von Threads oder Callables. (Threads mit Rückgabewert.)
Socket: Um eine TCP-IP-Verbindung zu einem Server herzustellen.
ServerSocket: Um eine Socket-Verbindung serverseitig anzunehmen.
DatagramSocket: Um über UDP mit einem Rechner zu kommunizieren. (Schneller als TCP, Reihenfolge und Ankommen der Datenpackete nicht sichergestellt.)
MulticastSocket: Um ein Datenpacket an mehrere Rechner gleichzeitig zu addressieren.


Bilder:

Toolkit: Zum einfachen laden von Bildern.
ImageIO: Um BufferedImage zu laden oder Bildobjekte abzuspeichern.
ImageIcon: Wrappler für Images, direktes laden über Konstruktor. Für Swing-Komponenten wie JLabel Pflicht.
Image: Abstrakte Klasse für Bilddateien.
BufferedImage: Erweiterte Klasse von Image mit mehr Funktionen. (z. B. Bildausschnitte zurückliefern.)
Graphics: Um Bilder zu bearbeiten, z. B. darauf zeichnen oder transformieren.


Collections:

(Syncronisiert)
Queue: Collection für Abwärtskompatiblität mit älteren JRE, FIFO.
Stack: Collection für Abwärtskompatiblität mit älteren JRE, LIFO.
LinkedBlockingQueue: Wie LinkedList mit Wartefunktion, falls sie leer ist.

(Unsyncronisiert)
ArrayList: Wrappler für Array, das automatisch mit Größeren ersetzt wird.
LinkedList: Doppelt verkettete Liste, schnellere Add/Remove-Operationen als ArrayList, aber langsamerer Feldzugriff. FIFO- und LIFO-Queues möglich.
HashMap: Zum verknüpfen eines Key-Objektes mit einen Wert.
HashSet: Set, also Sammlung von Objekten die nur einmal vorkommen dürfen, unsortiert.
TreeSet: Set, langsamer als HashSet, sortiert.

 

[Runtime]

Wenn man so etwas tut, macht man das meinstens, weil man für eine altere Version programmiert hat, in der es die Klasse noch nicht gab.

 

[Volvagia]

Wie meinst du das?
Es gibt laut API 3279 Klassen bzw. Interface in der JRE.
Da ist es ja fast unmöglich, eine passende Klasse für seine Aufgabe zu finden. Ich z. B. hätte eine LinkedList statt der BlockingQueue verwendet, und einfach eine Schleife die so lange durchrennt, wärend size == 0 ist. Ist aber sicher nicht so schön wie eine LBQ, da wäre eine Auflistung für die meisten User doch von Vorteil, oder?

 

[XHelp]

Also ja, generell kann so eine Auflistung jmnd. Helfen, aber:
(ganz davon abgesehen, dass eine Liste eine Liste ist, und eine Queue eine Queue ist):
Wenn du z.B. irgendwas mit einer Queue haben willst, gehst du eben in die Javadocs rein und suchst dir den Anfang raus. In diesem Fall wird es wohl das Interface Queue (Java 2 Platform SE 5.0) sein. Da steht auch "All Known Implementing Classes". Da kannst du auch nachlesen was es so alles gibt.

 

[fastjack]

Ich habe deshalb mit Javamak eine Art Klassensuchmaschine geschrieben. Man gibt einen bestimmten Klassennamen durch Lucene-Syntax ein und erhält dann Suchergebnisse, die auf Javadoc-Seiten verzweigen. Es werden speziell eingestellte Javadocs indiziert. Das ganze ist noch in der Entwicklung, es exisitiert aber bereits eine erste Version. Mein Problem war und ist es meistens, nicht zu wissen, welche Klassen bereits in z.B. Apache-Commons oder anderen 3rd party Libs existieren, natürlich kann man nachlesen und recherchieren, aber das dauert meistens.

Hier der Link:

http://www.java-forum.org/codeschnipsel-u-projekte/104086-javamak-generische-java-suchmaschine.html

Aber wie gesagt, es ist in stetiger Weiterentwicklung.

 

[jDennis79]

Nette Idee, dieser Thread, aber: Wenn hier nur zehn User jeweils genau so viele Klassen auflisten wie du, stehen hier auch schon 250 Klassen. Und ob ich dann hier stöbere, um durch Zufall etwas nettes zu finden, oder direkt in der API, macht eher wenig Unterschied...

 

[SlaterB]

mit Auftrennung nach Kategorien wie Bilder, Collections usw. wären auch 250 Klassen beherrschbar, aber das braucht es gar nicht,
wenn man so ein Thema hat, dann sucht man ein Lehrbuch/ Tutorial oder einfach bei google danach,
auf Grundbegriffe wie List oder Queue muss man dabei zwangsläufig stoßen, wenn noch nicht direkt das benötigte dabei dann weiter bei google schauen,
nach den neu gelernen Grundbegriffen + benötigten Eigenschaften suchen, bzw. die bekannten Klassen und deren packages in der API anschauen

z.B. steht in der API von java.util.AbstractQueue

Direct Known Subclasses:
ArrayBlockingQueue, ConcurrentLinkedQueue, DelayQueue, LinkedBlockingQueue, PriorityBlockingQueue, PriorityQueue, SynchronousQueue

Spezialitäten wie LinkedBlockingQueue findet man so vielleicht auch mal nicht,
aber dann wären sie auch viel zu selten für die Top 250 oder auch Top 1000 Klassen die man auflisten könnte