Packages/API

Kurz: Packages gruppieren zusammengehörige Java-Klassen in einem Namensraum (z. B. java.util); die API ist die Gesamtheit der öffentlich nutzbaren Klassen/Methoden, die Java bzw. eine Bibliothek bereitstellt.

Genauer: Ein Package entspricht meist einer Ordnerstruktur (java.util.ArrayList liegt z. B. im Ordner java/util/). Um Klassen aus einem anderen Package zu nutzen, braucht es ein import-Statement am Dateianfang. Die Java Standard Library selbst ist eine riesige, mitgelieferte API mit fertigen Packages für Collections, I/O, Networking und mehr.

Im Detail

package de.emzett.beispiel; // erste Zeile der Datei - deklariert das eigene Package
 
import java.util.ArrayList; // eine einzelne Klasse importieren
import java.util.*;          // ALLE Klassen des Packages importieren (meist unüblich/vermieden)
 
// java.lang wird automatisch importiert, KEIN import nötig für String, Math, System, ...
public class Beispiel {
    ArrayList<String> liste = new ArrayList<>();
}

Packages dienen zwei Zwecken gleichzeitig: sie strukturieren große Codebasen logisch (üblich ist eine umgekehrte Domain-Notation wie com.firma.projekt.modul) und verhindern Namenskonflikte — zwei Klassen dürfen denselben einfachen Namen tragen, solange sie in unterschiedlichen Packages liegen (java.util.List vs. eine eigene Klasse meinprojekt.List). Der Stern-Import (import java.util.*;) importiert zwar alle Klassen eines Packages auf einmal, gilt aber in den meisten Styleguides als schlechte Praxis, weil er unklar macht, welche Klasse tatsächlich woher kommt, und bei Namenskollisionen zwischen zwei Sterngeimporteten Packages sogar zu Compile-Fehlern führen kann. Das Package java.lang (mit String, Math, System, den Wrapper-Klassen usw.) ist die einzige Ausnahme, die automatisch ohne import verfügbar ist.

Zugriffsmodifizierer und Package-Grenzen

Packages sind nicht nur Organisation, sondern auch eine echte Sichtbarkeitsgrenze: Ohne expliziten Modifier (also “package-private”) ist eine Klasse/Methode NUR innerhalb desselben Packages sichtbar, selbst wenn eine andere Klasse sie importieren wollte. Das macht Packages zu einem eingebauten Werkzeug für Kapselung auf Modulebene — interne Hilfsklassen, die nur innerhalb eines Packages gebraucht werden, müssen nicht public sein und bleiben so für Code außerhalb unsichtbar.

JAR-Dateien und externe Bibliotheken

Fremde Bibliotheken (z. B. von Maven Central heruntergeladen) liefern ihre Packages meist als JAR-Datei aus — ein gezipptes Archiv aus .class-Dateien in genau der Ordnerstruktur, die ihren Package-Namen entspricht. Ein import com.google.gson.Gson; funktioniert nur, wenn das entsprechende JAR im Classpath des Projekts liegt; Build-Tools wie Maven oder Gradle übernehmen dabei automatisch das Herunterladen und Einbinden der richtigen JAR-Dateien anhand einer Abhängigkeitsliste.

javadoc — die API selbst dokumentieren

Die “API” eines Packages wird in der Praxis meist über Javadoc-Kommentare (/** ... */) direkt über Klassen/Methoden beschrieben und lässt sich damit automatisiert zu durchsuchbaren HTML-Seiten generieren (javadoc-Tool) — genau in diesem Format liegt auch die offizielle Dokumentation der Java Standard Library selbst vor.

Siehe auch: Classes, Collections, Modifiers