3.8 Eigene Pakete schnüren 

Ein Java-Paket ist eine logische Gruppierung von Klassen. Klassen, die zu einem Paket gehören, befinden sich normalerweise¹  im gleichen Verzeichnis. Der Name des Pakets ist dann gleich dem Namen des Verzeichnisses (und natürlich umgekehrt). Nehmen wir folgende Verzeichnisstruktur an:

suessigkeiten/
suessigkeiten/Zucker.java
suessigkeiten/Schokolade.java

Hier ist der Paketname (und somit Verzeichnisname) suessigkeiten. Umlaute sollten vermieden werden, da sie auf dem Dateisystem immer wieder für Ärger sorgen.

3.8.1 Die package-Anweisung 

Um die Klasse Zucker in das Paket suessigkeiten zu setzen, enthält der Quellcode als oberstes eine package-Anweisung. Die package-Anweisung muss die erste Anweisung sein, sonst gibt es einen Übersetzungsfehler. Da Kommentare keine Anweisungen sind, lassen sich selbstverständlich Kommentare vor die package-Anweisung setzen,

package suessigkeiten;

public class Zucker
{
 ...
}

Das Gleiche gilt auch für die Schokolade im gleichen Paket.

package suessigkeiten;

public class Schokolade extends Zucker
{
 ...
}

Um Klassen innerhalb von Paketen nutzen zu können, müssen sie dem Compiler präzise beschrieben werden. Die erste Möglichkeit war die volle Qualifizierung.

suessigkeiten.Schokolade s = new suessigkeiten.Schokolade();

3.8.2 Importieren von Klassen mit import 

Eine alternative und praktischere Möglichkeit ist, den Compiler in einer Klassendefinition mit import auf die Klassen im Paket aufmerksam zu machen.

import suessigkeiten.Schokolade;

class Weihnachtsmann
{
  Schokolade s;    // sonst suessigkeiten.Schokolade
}

Da die Klassen Schokolade und Zucker im gleichen Paket liegen, muss bei der Verwendung in der Vererbung die Klasse Zucker nicht extra bekannt gemacht werden.

Damit nicht alle Klassen eines Pakets einzeln aufgeführt werden müssen, lässt sich mit dem Sternchen als einer Art Wildcard auf alle sichtbaren Klassen zugreifen.

3.8.3 Paketnamen 

Prinzipiell kann ein Paketname beliebig sein, doch Hierarchien bestehen in der Regel aus umgedrehten Domänennamen. Aus der Domäne zur Webseite http://javatutor.de wird also de.javatutor. Diese Namensgebung gewährleistet, dass Klassen auch weltweit eindeutig bleiben. Ein Paketname wird in aller Regel komplett kleingeschrieben.

Die Paketnamen java, javax und sun

Sun hat für sich selbst einige Paketnamen reserviert, die von eigenen Klassen nicht genutzt werden sollen. So liegt unser java.awt.Point in einem Sun-Paket und das ist leicht durch den Teil java zu erkennen. Wenn jemand eigene Klassen in Pakete mit dem Präfix java setzen würde, etwa java.gui, der erzeugt damit Verwirrung, denn es ist nicht mehr erkennbar, ob das Paket bei jeder Distribution dabei ist – wie dies für die Sun-Klassen der Fall ist.

3.8.4 Hierarchische Strukturen und das Default-Package 

Pakete lassen sich in Hierarchien ordnen, so dass in einem Paket wieder ein anderes Paket liegen kann; das ist genauso wie bei der Verzeichnisstruktur des Dateisystems. Sun definiert das Paket java für einen Hauptzweig, aber auch javax. Unter dem Paket java liegen dann zum Beispiel awt, util und weitere. Es werden durch import java.* nicht automatisch alle Klassen der Unterpakete mit eingebunden. Die import-Anweisung bezieht sich nur auf ein Verzeichnis und schließt die Unterverzeichnisse nicht mit ein.

Unbekannte Pakete (Default package)

Falls eine Klasse ohne Paket-Definition implementiert wird, so befindet sie sich standardmäßig im umbenannten Paket (engl. unnamed package), oder Default-Paket. Es ist eine gute Idee, eigene Klassen immer in Paketen zu organisieren. Das erlaubt auch feinere Sichtbarkeiten.

Hier klicken, um das Bild zu Vergrößern

Abbildung 3.5   Eclipse sieht für das unbekannte Paket ein »virtuelles« Verzeichnis vor. Es nennt sich default package.

3.8.5 Klassen mit gleiche Namen in unterschiedlichen Paketen 

Ein Problem gibt es bei mehreren gleich benannten Klassen in verschiedenen Paketen. Hier ist eine volle Qualifizierung nötig. Ab dem SDK 1.2 gibt es im Paket java.awt und java.util eine Liste. Ein einfaches import java.awt.* und java.util.* hilft da nicht, denn der Compiler weiß nicht, ob die GUI-Komponente oder die Datenstruktur gemeint ist. Auch sagt ein import nichts darüber aus, ob die Klassen in der importierenden Datei jemals gebraucht werden. Das Gleiche gilt für die Klasse Date, die einmal in java.util und einmal in java.sql zu finden ist. Lustigerweise erweitert java.sql.Date die Klasse java.util.Date. Dass der Compiler hier nicht durcheinander kommt, ist ganz einfach dadurch zu erklären, dass er die Klassen nicht nur durch ihren Namen unterscheidet, sondern viel mehr auch durch ihre Pakete. Der Compiler betrachtet intern immer eine volle Qualifizierung.

3.8.6 Statische Imports 

Das import hat in Java die Bedeutung, den Compiler über die Pakete zu informieren, so dass eine Klasse nicht mehr voll qualifiziert werden muss, wenn sie im import-Teil explizit genannt ist, oder das Paket der Klasse genannt ist.

Falls eine Klasse statische Funktionen oder Konstanten vorschreibt, so werden ihre Eigenschaften immer über den Klassennamen angesprochen. Es gibt nun mit den statischen Imports die Möglichkeit, die statischen Eigenschaften wie eigene Funktionen oder Variablen ohne Klassenamen sofort zu nutzen. Nehmen wir an, wir wollten das Maximum dreier Ganzzahlen a, b, c bestimmen. Wir würden das etwa so lösen können:

static int max( int a, int b, int c )
{
  return Math.max( a, Math.max(b, c) );
}

Über die statischen Imports kann die Funktion max aus Math nun »importiert" werden, so dass der Klassenname entfallen kann.

import static java.lang.Math.max;

class StatischesImport
{
  static int max( int a, int b, int c )
  {
    return max( a, max(b, c) );
  }
}

Das statische Import bindet jetzt aber nur die max()-Funktion ein. Besteht Bedarf für die min()-Funktion, gibt es zwei Möglichkeiten: Zum einen lässt sich ein zweites statisches Import nachschieben oder gleich alles aus der Math-Klasse statisch importieren:

import static java.lang.Math.*;

Auch wenn Java seit Version 5 diese Möglichkeit bietet, sollte der Einsatz gemäßigt erfolgen. Die Möglichkeit der statischen Importe wird dann nützlicher, wenn Klassen Konstanten nutzen wollen. Später dazu noch mehr.

3.8.7 Eine Verzeichnisstruktur für eigene Projekte 

Neben der Einteilung in Pakete für das eigene Programm, ist es auch sinnvoll, die gesamte Applikation in verschiedenen Verzeichnissen aufzubauen. Im Allgemeinen finden sich drei wichtige Hauptverzeichnisse: src für die Quellen, lib für externe Bibliotheken auf die das Programm aufbaut und bin (oder build) für die erzeugen Klassen-Dateien. Das Verzeichnis src lässt sich noch weiter unterteilen, etwa für Quellen, die Testfälle implementieren oder Beispiele.

src/
  core/
  examples/
  test/
lib/
bin/

¹   Ich schreibe »normalerweise«, da die Paketstruktur nicht zwingend auf Verzeichnisse abgebildet werden muss. Pakete könnten beispielsweise vom Klassenlader aus einer Datenbank gelesen werden. Im Folgenden wollen wir aber immer von Verzeichnissen ausgehen.