Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Objektorientierte Beziehungsfragen
7 Ausnahmen müssen sein
8 Äußere.innere Klassen
9 Besondere Typen der Java SE
10 Generics<T>
11 Lambda-Ausdrücke und funktionale Programmierung
12 Architektur, Design und angewandte Objektorientierung
13 Die Klassenbibliothek
14 Einführung in die nebenläufige Programmierung
15 Einführung in Datenstrukturen und Algorithmen
16 Einführung in grafische Oberflächen
17 Einführung in Dateien und Datenströme
18 Einführung ins Datenbankmanagement mit JDBC
19 Einführung in <XML>
20 Testen mit JUnit
21 Bits und Bytes und Mathematisches
22 Die Werkzeuge des JDK
A Java SE Paketübersicht
Stichwortverzeichnis

Download:
- Beispielprogramme, ca. 20,0 MB
- Übungsaufgaben, ca. 1,8 MB
- Musterlösungen, ca. 0,8 MB

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenbloom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Rheinwerk Computing
1306 Seiten, gebunden, 11. Auflage
49,90 Euro, ISBN 978-3-8362-2873-2
Pfeil 13 Die Klassenbibliothek
Pfeil 13.1 Die Java-Klassenphilosophie
Pfeil 13.1.1 Übersicht über die Pakete der Standardbibliothek
Pfeil 13.1.2 Compact-Profile
Pfeil 13.2 Sprachen der Länder
Pfeil 13.2.1 Sprachen und Regionen über Locale-Objekte
Pfeil 13.3 Die Klasse Date
Pfeil 13.3.1 Objekte erzeugen und Methoden nutzen
Pfeil 13.3.2 Date-Objekte sind nicht immutable
Pfeil 13.4 Calendar und GregorianCalendar
Pfeil 13.4.1 Die abstrakte Klasse Calendar
Pfeil 13.4.2 Calendar nach Date und Millisekunden fragen
Pfeil 13.4.3 Abfragen und Setzen von Datumselementen über Feldbezeichner
Pfeil 13.4.4 Kalender-Exemplare bauen über den Calendar.Builder
Pfeil 13.4.5 Der gregorianische Kalender
Pfeil 13.4.6 Date-Time-API in Java 8
Pfeil 13.5 Klassenlader (Class Loader) und Klassenpfad
Pfeil 13.5.1 Woher die kleinen Klassen kommen
Pfeil 13.5.2 Setzen des Klassenpfades
Pfeil 13.5.3 Die wichtigsten drei Typen von Klassenladern
Pfeil 13.6 Die Utility-Klasse System und Properties
Pfeil 13.6.1 Systemeigenschaften der Java-Umgebung
Pfeil 13.6.2 line.separator
Pfeil 13.6.3 Eigene Properties von der Konsole aus setzen *
Pfeil 13.6.4 Umgebungsvariablen des Betriebssystems *
Pfeil 13.6.5 Einfache Zeitmessung und Profiling *
Pfeil 13.7 Einfache Benutzereingaben
Pfeil 13.7.1 Grafischer Eingabedialog über JOptionPane
Pfeil 13.7.2 Geschützte Passwort-Eingaben mit der Klasse Console *
Pfeil 13.8 Ausführen externer Programme *
Pfeil 13.8.1 ProcessBuilder und Prozesskontrolle mit Process
Pfeil 13.8.2 Einen Browser, E-Mail-Client oder Editor aufrufen
Pfeil 13.9 Benutzereinstellungen *
Pfeil 13.9.1 Benutzereinstellungen mit der Preferences-API
Pfeil 13.9.2 Einträge einfügen, auslesen und löschen
Pfeil 13.9.3 Auslesen der Daten und Schreiben in einem anderen Format
Pfeil 13.9.4 Auf Ereignisse horchen
Pfeil 13.9.5 Zugriff auf die gesamte Windows-Registry
Pfeil 13.10 Zum Weiterlesen
 
Zum Seitenanfang

13.5Klassenlader (Class Loader) und Klassenpfad Zur vorigen ÜberschriftZur nächsten Überschrift

Ein Klassenlader ist dafür verantwortlich, eine Klasse zu laden. Aus der Datenquelle (im Allgemeinen einer Datei) liefert der Klassenlader ein Byte-Feld mit den Informationen, die im zweiten Schritt dazu verwendet werden, die Klasse ins Laufzeitsystem einzubringen; das ist Linking. Es gibt eine Reihe von vordefinierten Klassenladern und die Möglichkeit, eigene Klassenlader zu schreiben, um etwa verschlüsselte und komprimierte .class-Dateien zu laden.

 
Zum Seitenanfang

13.5.1Woher die kleinen Klassen kommen Zur vorigen ÜberschriftZur nächsten Überschrift

Nehmen wir zu Beginn ein einfaches Programm mit zwei Klassen:

class Person {
static String now = new java.util.Date().toString();

public static void main( String[] args ) {
Dog wuffi = new Dog();
}
}

class Dog {
Person master;
}

Wenn die Laufzeitumgebung das Programm Person startet, muss sie eine Reihe von Klassen laden. Sofort wird klar, dass es zumindest Person sein muss. Wenn aber die statische main(String[])-Methode aufgerufen wird, muss auch Dog geladen sein. Und da beim Laden einer Klasse auch die statischen Variablen initialisiert werden, wird auch die Klasse java.util.Date geladen. Zwei weitere Dinge werden nach einiger Überlegung deutlich:

  • Wenn Dog geladen wird, bezieht es sich auf Person. Da Person aber schon geladen ist, muss es nicht noch einmal geladen werden.

  • Unsichtbar stecken noch andere referenzierte Klassen dahinter, die nicht direkt sichtbar sind. So wird zum Beispiel Object geladen, da implizit in der Klassendeklaration von Person steht: class Person extends Object. Auch String muss geladen werden, weil String einmal in der Signatur von main(String[]) vorkommt und es der Typ von now ist. Intern ziehen die Typen viele weitere Typen nach sich. String implementiert Serializable, CharSequence und Comparable, also müssen diese drei Schnittstellen auch geladen werden. Und so geht das weiter, je nach dem, welche Programmpfade abgelaufen werden. Wichtig ist aber zu verstehen, dass diese Klassendateien so spät wie möglich geladen werden.

Im Beispiel mit den Klassen Person und Dog lädt die Laufzeitumgebung selbstständig die Klassen (implizites Klassenladen). Klassen lassen sich auch mit Class.forName(String) über ihren Namen laden (explizites Klassenladen).

[+]Hinweis

Um zu sehen, welche Klassen überhaupt geladen werden, lässt sich der virtuellen Maschine beim Start der Laufzeitumgebung ein Schalter mitgeben -verbose:class. Dann gibt die Maschine beim Lauf alle Klassen aus, die sie lädt.

Die Suchorte

Ein festes, dreistufiges Schema bestimmt die Suche nach den Klassen:

  1. Klassen wie String, Object oder Point stehen in einem ganz speziellen Archiv. Wenn ein eigenes Java-Programm gestartet wird, so sucht die virtuelle Maschine die angeforderten Klassen zuerst in diesem Archiv. Da es elementare Klassen sind, die zum Hochfahren eines Systems gehören, werden sie Bootstrap-Klassen genannt. Das Archiv mit diesen Klassen heißt oft rt.jar (für Runtime). Andere Archive können hinzukommen – wie i18n.jar, das Internationalisierungsdaten beinhaltet. Die Implementierung dieses Bootstrap-Laders ist nicht öffentlich und wird von System zu System unterschiedlich sein.

  2. Findet die Laufzeitumgebung die Klassen nicht bei den Bootstrap-Klassen, so werden alle Archive eines speziellen Verzeichnisses untersucht, das sich Extension-Verzeichnis nennt. Das Verzeichnis gibt es bei jeder Java-Version. Es liegt unter lib/ext. Werden hier Klassen eingelagert, so findet die Laufzeitumgebung diese Klassen ohne weitere Anpassung und Setzen von Pfaden. In sonstige Verzeichnisse einer Java-Installation sollten keine Klassen kopiert werden.

  3. Ist eine Klasse auch im Erweiterungsverzeichnis nicht zu finden, beginnt die Suche im Klassenpfad (Classpath). Diese Pfadangabe besteht aus einer Aufzählung einzelner Verzeichnisse, Klassen oder JAR-Archive, in denen die Laufzeitumgebung nach den Klassendateien sucht. Standardmäßig ist dieser Klassenpfad auf das aktuelle Verzeichnis gesetzt (».«).

[+]Hinweis

Es gibt spezielle Bootstrap-Klassen, die sich überschreiben lassen. Sie werden in das spezielle Verzeichnis endorsed gesetzt.

 
Zum Seitenanfang

13.5.2Setzen des Klassenpfades Zur vorigen ÜberschriftZur nächsten Überschrift

Die Suchorte lassen sich angeben, wobei die Bestimmung des Klassenpfades für die eigenen Klassen die wichtigste ist. Sollen in einem Java-Projekt Dateien aus einem Verzeichnis oder einem externen Java-Archiv geholt werden, so ist der übliche Weg, dieses Verzeichnis oder Archiv im Klassenpfad anzugeben. Dafür gibt es zwei Varianten. Die erste ist, über den Schalter -classpath (kurz -cp) beim Start der virtuellen Maschine die Quellen aufzuführen:

$ java -classpath classpath1;classpath2 MainClass

Der Klassenpfad enthält Wurzelverzeichnisse der Pakete und auch JAR-Dateien, also Archive von Klassendateien und Ressourcen.

Eine Alternative zum Schalter ist das Setzen der Umgebungsvariablen CLASSPATH mit einer Zeichenfolge, die die Klassen spezifiziert:

$ SET CLASSPATH=classpath1;classpath2
$ java MainClass

Um in Eclipse den Klassenpfad zu erweitern, damit etwa die Klassendateien von Java-Archiven berücksichtigt werden, ist Folgendes zu tun: Im Projekt das Kontaktmenü öffnen und Properties aufrufen, dann links unter Java Build Path gehen und anschließend im Reiter Libraries entweder Add JARs… (JARs sind im Projekt) oder Add External JARs… (JAR-Dateien liegen nicht im Projekt, sondern irgendwo anders im Dateisystem) nutzen.

[+]Hinweis

Die so genannten Bootstrap-Klassen aus den Paketen java.* (wie Object, String), com.sun.* usw. stehen nicht im CLASSPATH. Wer den Pfad für die Bootstrap-Klassen ändern möchte, kann dies mit dem Schalter -Xbootclasspath tun.

 
Zum Seitenanfang

13.5.3Die wichtigsten drei Typen von Klassenladern Zur vorigen ÜberschriftZur nächsten Überschrift

Eine Klassendatei kann von der Java-Laufzeitumgebung über verschiedene Klassenlader bezogen werden. Die wichtigsten sind: Bootstrap-, Erweiterungs- und Applikations-Klassenlader. Sie arbeiten insofern zusammen, als dass sie sich gegenseitig Aufgaben zuschieben, wenn eine Klasse nicht gefunden wird:

  • Bootstrap-Klassenlader: für die Bootstrap-Klassen

  • Erweiterungs-Klassenlader: für die Klassen im lib/ext-Verzeichnis

  • Applikations-Klassenlader (auch System-Klassenlader): Der letzte Klassenlader im Bunde berücksichtigt bei der Suche den java.class.path.

Aus Sicherheitsgründen beginnt der Klassenlader bei einer neuen Klasse immer mit dem System-Klassenlader und reicht dann die Anfrage weiter, wenn er selbst die Klasse nicht laden konnte. Dazu sind die Klassenlader miteinander verbunden. Jeder Klassenlader L hat dazu einen Vater-Klassenlader V. Erst darf der Vater versuchen, die Klassen zu laden. Kann er es nicht, gibt er die Arbeit an L ab.

Hinter dem letzten Klassenlader können wir einen eigenen benutzerdefinierten Klassenlader installieren. Auch dieser wird einen Vater haben, den üblicherweise der Applikations-Klassenlader verkörpert.

 


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Zum Katalog
Zum Katalog: Java ist auch eine Insel Java ist auch eine Insel
Jetzt bestellen

 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java SE 8 Standard-Bibliothek
Java SE 8 Standard-Bibliothek


Zum Katalog: Professionell entwickeln mit Java EE 7
Professionell entwickeln mit Java EE 7


Zum Katalog: Schrödinger programmiert Java
Schrödinger programmiert Java


Zum Katalog: Einführung in Java
Einführung in Java


Zum Katalog: Programmieren lernen mit Java
Programmieren lernen mit Java


Zum Katalog: Apps entwickeln für Android 5
Apps entwickeln für Android 5


Zum Katalog: Apps entwickeln mit Android Studio
Apps entwickeln mit Android Studio


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2016
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 
Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de