13.2.1 Verwendung von Paketen
Jede Klasse in Java ist Bestandteil eines Pakets. Der vollständige
Name einer Klasse besteht aus dem Namen des Pakets, gefolgt von einem
Punkt, dem sich der eigentliche Name der Klasse anschließt.
Der Name des Pakets selbst kann ebenfalls einen oder mehrere Punkte
enthalten.
Damit eine Klasse verwendet werden kann, muss angegeben werden, in
welchem Paket sie liegt. Hierzu gibt es zwei unterschiedliche Möglichkeiten:
- Die Klasse wird über ihren vollen (qualifizierten) Namen
angesprochen:
java.util.Date d = new java.util.Date();
- Am Anfang des Programms werden die gewünschten Klassen mit
Hilfe einer import-Anweisung
eingebunden:
import java.util.*;
...
Date d = new Date();
Die Verwendung voll qualifizierter Namen hat den Nachteil, dass die
Klassennamen sehr lang und unhandlich werden. Bequemer ist daher die
Anwendung der zweiten Variante, bei der die benötigten Klassen
mit Hilfe einer import-Anweisung
dem Compiler bekanntgemacht werden.
Die import-Anweisung
gibt es in zwei unterschiedlichen Ausprägungen:
- Mit der Syntax import Paket.Klasse;
wird genau eine Klasse importiert. Alle anderen Klassen des Pakets
bleiben unsichtbar:
import java.util.Date;
...
Date d = new Date();
java.util.Vector v = new java.util.Vector();
- Unter Verwendung der Syntax import Paket.*;
können alle Klassen des angegebenen Pakets auf einmal importiert
werden:
import java.util.*;
...
Date d = new Date();
Vector v = new Vector();
Im Gegensatz zu ähnlichen Konstrukten in anderen Sprachen ist
die Verwendung der zweiten Variante der import-Anweisung
nicht zwangsläufig ineffizienter als die der ersten. In der Sprachspezifikation
wird sie als type import on demand bezeichnet, was bedeutet,
dass die Klasse erst dann in den angegebenen Paketen gesucht wird,
wenn das Programm sie wirklich benötigt. Keinesfalls muss der
Compiler beim Parsen der import-Anweisung
zwangsläufig alle Klassendateien des angegebenen Pakets in den
Hauptspeicher laden oder ähnlich zeit- und speicheraufwändige
Dinge machen. Es schadet also im allgemeinen nichts, die zweite Variante
der import-Anweisung
zu verwenden.
In vielen verschiedenen Beispielen in diesem Buch werden Klassennamen
(wie beispielsweise String,
Thread
oder Object)
verwendet, ohne dass eine zugehörige import-Anweisung
zu erkennen wäre. In diesem Fall entstammen die Klassen dem Paket
java.lang.
Dieses Paket wurde von den Entwicklern der Sprache als so wichtig
angesehen, dass es bei jedem Compilerlauf automatisch importiert wird.
Man kann sich das so vorstellen, als wenn am Anfang jeder Quelldatei
implizit die folgende Anweisung stehen würde:
import java.lang.*;
Ein expliziter Import von java.lang
ist daher niemals nötig. Alle anderen Pakete müssen jedoch
vor ihrer Verwendung importiert werden, wenn auf die Anwendung voll
qualifizierter Klassennamen verzichtet werden soll.
Die vordefinierten Pakete im JDK
Während beim Wechsel der Java-Versionen die Sprachspezifikation
relativ stabil geblieben ist, hat sich der Umfang der Laufzeitbibliothek
um ein Vielfaches erhöht. Dies zeigt sich unter anderem an der
gestiegenen Anzahl an vordefinierten Paketen, die mit dem JDK ausgeliefert
werden (siehe Tabelle 13.1
und Tabelle 13.2).
Sie stieg von 8 Standardpaketen im JDK 1.0 auf 22 im JDK 1.1, 50 im
JDK 1.2, 70 im JDK 1.3, 130 im JDK 1.4 und schließlich knapp
200 seit der Java 5 Standard Edition.
Tabelle 13.1: Wichtige Standard-Pakete des JDK
Tabelle 13.2: Wichtige Standarderweiterungen des JDK
Des weiteren sind einige Pakete im JDK enthalten, deren Inhalt von
Dritten hergestellt wurde. Beispiele dafür sind die diversen
Pakete unterhalb der org.omg-Hierarchie,
mit deren Hilfe CORBA-Support zur Verfügung
gestellt wird. Oder die Paket-Hierarchien org.xml
und org.w3c,
die Unterstützung zum Zugriff auf XML-Dateien
zur Verfügungv stellen.
13.2.2 Die Bedeutung der Paketnamen
Paketnamen bestehen in Java aus mehreren Komponenten, die durch Punkte
voneinander getrennt sind. Neben der Aufgabe, die Paketnamen visuell
zu strukturieren, hat die Unterteilung aber noch eine andere, sehr
viel wichtigere Bedeutung.
Jeder Teil eines mehrstufigen Paketnamens bezeichnet nämlich
ein Unterverzeichnis auf dem Weg zu der gewünschten Klassendatei.
Soll beispielsweise eine Klasse aus dem Paket java.awt.image
eingebunden werden, sucht es der Java-Compiler im Unterverzeichnis
java\awt\image. Soll dagegen eine Klasse
aus dem Paket com.sun.image.codec.jpeg
geladen werden, wird es im Unterverzeichnis com\sun\image\codec\jpeg
gesucht. Interessant ist in diesem Zusammenhang natürlich die
Frage, in welchem Verzeichnis der Compiler mit der Suche beginnt.
Bei der Antwort darauf muss zwischen den JDKs 1.2, 1.3 und 1.4 und
ihren Vorgängerversionen 1.0 und 1.1 unterschieden werden.
Laden von Klassen im JDK 1.0 und 1.1
Wurde keine Umgebungsvariable CLASSPATH
angegeben und der Schalter -classpath
beim Compiler-Aufruf nicht verwendet, so suchen der Java-Compiler
und die übrigen Tools in einem systemspezifischen Installationsverzeichnis
(z.B. c:\java1.1.7\lib beim JDK 1.1.7)
und zusätzlich im aktuellen Verzeichnis nach den Klassendateien.
Anders als im JDK 1.0 ist es bei einer Standardinstallation des JDK
1.1 unter Windows 95 nicht erforderlich, den CLASSPATH
explizit zu setzen. Alle Tools generieren den CLASSPATH
implizit aus der Position des bin-Verzeichnisses
(z.B. c:\java1.1.7\bin) nach folgendem
Schema:
.;[bin]\..\classes;[bin]\..\lib\classes.zip
[bin] steht hier für den
Pfad des bin-Verzeichnisses. Nur wenn
die Klassendateien in einem anderen Verzeichnis liegen oder Klassendateien
in weiteren Verzeichnissen eingebunden werden sollen, muss die CLASSPATH-Variable
manuell geändert werden.
Existiert zum Zeitpunkt des Compiler-Aufrufs die Umgebungsvariable
CLASSPATH,
beginnt der Compiler die Suche nach den eingebundenen Klassen in allen
im CLASSPATH
angegebenen Verzeichnissen. Die einzelnen Verzeichnisse werden durch
ein Semikolon (bzw. einen Doppelpunkt unter UNIX) voneinander getrennt.
Beim Aufruf des Compilers kann der Schalter -classpath,
gefolgt von einer Liste von Verzeichnisnamen, übergeben werden.
Er hat dieselbe Bedeutung wie die Umgebungsvariable CLASSPATH
und definiert die Verzeichnisse, in denen der Compiler nach den .class-Dateien
sucht. Der Compiler-Schalter hat dabei Vorrang gegenüber einer
möglichen Umgebungsvariablen.
Laden von Klassen seit dem JDK 1.2
Die Verwendung der CLASSPATH-Variable
hat immer wieder zu Schwierigkeiten und Missverständnissen geführt.
Es ist insbesondere häufig passiert, dass durch falsches Setzen
der Umgebungsvariable die Systemklassen selbst nicht mehr gefunden
werden konnten und auf diese Weise das gesamte Laufzeitsystem unbenutzbar
wurde.
Seit dem JDK 1.2 wurde daher die Bedeutung der CLASSPATH-Umgebungsvariable
dahingehend verändert, dass sie nur noch zur Suche der benutzerspezifischen
Klassen verwendet wird. Alle Standardpakete und Standarderweiterungen
(beide zusammen werden seit dem JDK 1.2 Bootstrap Classes
genannt) werden dagegen unabhängig vom CLASSPATH
mit Hilfe der auf das Installationsverzeichnis verweisenden Systemeigenschaft
sun.boot.class.path
gefunden. Sie wird bei der JDK-Installation automatisch gesetzt und
sollte später nicht mehr verändert werden. Der CLASSPATH
braucht also nur noch dann explizit gesetzt zu werden, wenn benutzerspezifische
Klassen vorhanden sind, die nicht im aktuellen Verzeichnis liegen
(letzteres wird ebenfalls automatisch durchsucht).
Die Dateien classes.zip und rt.jar
Im Installationsverzeichnis von JDKs der Versionen 1.0 und 1.1 findet
man meist eine Datei classes.zip
anstelle der erwähnten Unterverzeichnisse mit den Klassendateien.
Aus Gründen der Performance beim Übersetzen haben sich die
Entwickler entschlossen, alle Standardklassendateien in diesem Archiv
abzulegen, um einen schnelleren Lesezugriff auf sie zu ermöglichen.
Um dem Compiler diese Art der Speicherung der Klassendateien bekanntzumachen,
muss in der CLASSPATH-Umgebungsvariable
nicht nur das Verzeichnis, sondern auch der Name der .zip-Datei
angegeben werden, z.B.:
CLASSPATH=.;c:\java\LIB\CLASSES.ZIP
Umgekehrte Domain-Namen
Die Entwickler von Java haben sich einen Mechanismus ausgedacht, um
auch bei sehr großen Projekten, an denen möglicherweise
viele Entwickler beteiligt sind, Namenskollisionen zwischen den beteiligten
Klassen und Paketen zu vermeiden. Auch die Verwendung einer großen
Anzahl unterschiedlicher Klassenbibliotheken von verschiedenen Herstellern
sollte möglich sein, ohne dass Namensüberschneidungen dies
schon im Keim ersticken.
Um diese Probleme zu lösen, hat sich das Java-Team eine Vorgehensweise
zur Vergabe von Paketnamen überlegt, die an das Domain-Namen-System
bei Internet-Adressen angelehnt ist. Danach sollte jeder Anbieter
seine Pakete entsprechend dem eigenen Domain-Namen benennen, dabei
allerdings die Namensbestandteile in umgekehrter Reihenfolge verwenden.
So sollten beispielsweise die Klassen der Firma SUN, deren Domain-Name
sun.com ist, in einem Paket
com.sun oder in darunter befindlichen
Subpaketen liegen. Da die Domain-Namen weltweit eindeutig sind, werden
Namenskollisionen zwischen Paketen unterschiedlicher Hersteller auf
diese Weise von vornherein vermieden. Beispiele für derartige
Paketnamen liefert die Standardinstallation gleich mit. So stellt
das JDK 1.2 diverse Pakete com.sun.*
zur Verfügung. Sie gehören nicht zum Standard-Sprachumfang
eines Java-Entwicklungssystems, sondern werden von SUN als eigenständige
Erweiterung mit dem JDK ausgeliefert.
Der Vollständigkeit halber sollte man anmerken, dass sich das
hier beschriebene System in der Praxis noch nicht komplett durchgesetzt
hat und insbesondere die Klassen der java.*-
und javax.*-Hierarchie Ausnahmen
bilden. Es wird mit der zunehmenden Anzahl allgemein verfügbarer
Pakete jedoch an Bedeutung gewinnen. Manche Entwickler verwenden ein
leicht abgewandeltes Schema, bei dem nur die Top-Level-Domain ausgelassen
wird. Die Paketnamen beginnen in diesem Fall nicht mit org
oder com, sondern direkt mit
dem zweiten Teil des Domain-Namens (oder einem ähnlichen herstellerspezifischen
Kürzel). Dadurch werden sie etwas kürzer und sind leichter
zu handhaben.
13.2.3 Einbinden zusätzlicher Pakete
In der Praxis wird man neben der Klassenbibliothek des JDK häufig
zusätzliche Pakete von Drittanbietern verwenden wollen. Um den
Klassenpfad nicht unnötig lang werden zu lassen, empfiehlt es
sich, die Pakete in einem gemeinsamen Verzeichnis abzulegen. Falls
sich alle Entwickler von Libraries an das oben besprochene Schema
zur Vergabe von Paketnamen halten, kann es keine Überschneidungen
geben.
Als Beispiel wollen wir einige Java-Klassen des Autors (zu finden
als Datei gkjava.zip unter http://www.gkrueger.com
oder auf der DVD zum Buch im Verzeichnis \misc)
und die Utilities der »ACME-Labs« von Jef Poskanzer (http://www.acme.com)
installieren:
- Zunächst legen wir ein gemeinsames Unterverzeichnis für
unsere Klassendateien an, beispielsweise c:\classes.
- Nun wird die .zip-Datei mit den Klassen
des Autors geladen und im Verzeichnis c:\classes
ausgepackt. Da alle Paketnamen mit gk
beginnen, landen alle Dateien im Unterverzeichnis gk.
- Auf die gleiche Weise packen wir die Klassendateien von Jef Poskanzer
aus. Alle Klassen liegen im Paket acme
oder in Unterpaketen und landen damit im Unterverzeichnis acme.
- Nun braucht lediglich noch der CLASSPATH
so gesetzt zu werden, dass er das Verzeichnis c:\classes
beinhaltet:
set CLASSPATH=.;c:\classes
Alle Libraries, die sich an diese Konventionen halten, können
in der beschriebenen Weise installiert werden. Probleme gibt es nur,
wenn ein Anbieter seine Klassendateien nicht in Paketen ablegt. In
diesem Fall müssten die Klassendateien in das aktuelle Verzeichnis
oder nach c:\classes kopiert werden.
Das würde bei Klassendateien von mehr als einem Anbieter natürlich
schnell zum Chaos führen, läßt sich aber nicht so
einfach ändern. Es bieten sich zwei Handlungsalternativen an:
- Wenn man die Pakete in unterschiedlichen Unterverzeichnissen ablegt,
benötigen die Programme einen relativ langen und möglicherweise
schwer zu pflegenden Klassenpfad, in dem alle benötigten Verzeichnisse
verzeichnet sind.
- Wenn man die »paketlosen« Dateien verschiedener Anbieter
in unterschiedliche Unterverzeichnisse von c:\classes
legen will, müsste man dazu die Quelldateien um die entsprechenden
package-Anweisungen
(siehe nachfolgenden Abschnitt) ergänzen.
Beide Varianten sind unbefriedigend, und es bleibt zu hoffen, dass
die Anbieter von Java-Klassenbibliotheken sich verstärkt an die
Namenskonventionen des Java-Teams halten werden.
Benannte Pakete
Bisher wurde nur gezeigt, wie man Klassen aus fremden Paketen verwendet,
nicht aber, wie man selbst Pakete erstellt. Glücklicherweise
ist das aber keine Aufgabe für Spezialisten, sondern sehr einfach
mit Bordmitteln realisierbar.
Um eine Klasse einem ganz bestimmten Paket zuzuordnen, muss lediglich
am Anfang des Quelltextes eine geeignete package-Anweisung
verwendet werden. Diese besteht (analog zur import-Anweisung)
aus dem Schlüsselwort package
und dem Namen des Pakets, dem die nachfolgende Klasse zugeordnet werden
soll. Die package-Anweisung
muss als erste Anweisung in einer Quelldatei stehen, so dass der Compiler
sie noch vor den import-Anweisungen
findet.
Der Aufbau und die Bedeutung der Paketnamen in der package-Anweisung
entspricht exakt dem der import-Anweisung.
Der Compiler löst ebenso wie beim import
den dort angegebenen hierarchischen Namen in eine Kette von Unterverzeichnissen
auf, an deren Ende die Quelldatei steht. Neben der Quelldatei wird
auch die Klassendatei in diesem Unterverzeichnis erstellt.
Da der Java-Compiler eingebundene Quelldateien, die noch nicht übersetzt
sind, während der Übersetzung einer anderen Klasse automatisch
mit übersetzt, ist das Erstellen eines neuen Pakets sehr einfach.
Wir wollen uns ein Beispiel ansehen, bei dem zwei Pakete demo
und demo.tools angelegt und
die darin enthaltenen Klassen A,
B und C
in einer Klasse PackageDemo
verwendet werden. Am einfachsten ist es, wie nachfolgend beschrieben
vorzugehen.
Wir gehen davon aus, dass der CLASSPATH
das aktuelle Verzeichnis enthält (also beispielsweise den Inhalt
».;c:\classes« hat), und legen im aktuellen Verzeichnis
die Unterverzeichnisse demo und demo\tools
an.
- Zunächst wird im Unterverzeichnis demo
die Datei A.java angelegt:
001 package demo;
002
003 public class A
004 {
005 public void hello()
006 {
007 System.out.println("Hier ist A");
008 }
009 }
|
demo/A.java |
Listing 13.3: Die Klasse A des Pakets demo
Sie enthält die Anweisung package demo;,
um anzuzeigen, dass die Klasse A
zum Paket demo gehört.
- Im Unterverzeichnis demo wird weiterhin
die Datei B.java angelegt:
001 package demo;
002
003 public class B
004 {
005 public void hello()
006 {
007 System.out.println("Hier ist B");
008 }
009 }
|
demo/B.java |
Listing 13.4: Die Klasse B des Pakets demo
Auch diese Quelldatei enthält die Anweisung package
demo;, um anzuzeigen, dass die Klasse zum Paket demo
gehört.
- Im Unterverzeichnis demo\tools wird
die Datei C.java angelegt:
001 package demo.tools;
002
003 public class C
004 {
005 public void hello()
006 {
007 System.out.println("Hier ist C");
008 }
009 }
|
demo/tools/C.java |
Listing 13.5: Die Klasse C des Pakets demo.tools
Diese Quelldatei enthält die Anweisung package
demo.tools;, um anzuzeigen, dass die Klasse zum Paket
demo.tools gehört.
- Nun wird im Stammverzeichnis die Datei PackageDemo.java
angelegt:
001 import demo.*;
002 import demo.tools.*;
003
004 public class PackageDemo
005 {
006 public static void main(String[] args)
007 {
008 (new A()).hello();
009 (new B()).hello();
010 (new C()).hello();
011 }
012 }
|
PackageDemo.java |
Listing 13.6: Verwendung der Klassen aus selbstdefinierten Paketen
Ohne vorher die Klassen A, B
oder C separat übersetzen
zu müssen, kann nun einfach PackageDemo
kompiliert werden. Der Compiler erkennt die Verwendung von A,
B und C,
findet die Paketverzeichnisse demo und
demo\tools und erkennt, dass die Quellen
noch nicht übersetzt wurden. Er erzeugt dann aus den .java-Dateien
die zugehörigen .class-Dateien
(in demselben Verzeichnis wie die Quelldateien),
bindet sie ein und übersetzt schließlich die Klasse PackageDemo.
Die Ausgabe des Programms ist:
Hier ist A
Hier ist B
Hier ist C
Würde nur dann ein eigenes Paket erzeugt werden, wenn die Quelldatei
eine package-Anweisung
enthält, müsste man sich fragen, zu welchem Paket die Klassen
gehören, in deren Quelldatei die package-Anweisung
fehlt (was ja erlaubt ist). Die Antwort auf diese Frage lautet, dass
es in Java ein Default-Paket gibt, das genau dann verwendet
wird, wenn keine andere Zuordnung getroffen wurde.
Das Default-Paket ist ein Zugeständnis an kleinere Programme
oder einfache Programmierprojekte, bei denen es sich nicht lohnt,
eigene Pakete anzulegen. Ohne Teile des Projektes in Unterverzeichnissen
abzulegen und durch import-
und package-Anweisungen
unnötigen Aufwand zu treiben, ist es auf diese Weise möglich,
Quelldateien einfach im aktuellen Verzeichnis abzulegen, dort zu kompilieren
und automatisch einzubinden. Klassen des Default-Pakets können
ohne explizite import-Anweisung
verwendet werden.
Das public-Attribut
Es gibt noch eine wichtige Besonderheit bei der Deklaration von Klassen,
die von anderen Klassen verwendet werden sollen. Damit eine Klasse
A eine andere Klasse B
einbinden darf, muss nämlich eine der beiden folgenden Bedingungen
erfüllt sein:
- Entweder gehören A
und B zu demselben Paket oder
- die Klasse B wurde als public
deklariert.
