Programmiergrundlagen4Lerneinheiten20minStand30.05.2026

Pakete & Imports.

Fachliche Qualität

Noch nicht klassifiziertNoch nicht geprüft.

Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.

Klausur-ÜbersichtKomplette Übersicht: alle Tabs als linearer Text zum Lernen

Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).

Teil 1·Erklärung

Erklärung

Zur KategorieProgrammiergrundlagen.Mehr Themen entdeckenZum Themen-Hub.

Pakete & Imports, Programmiergrundlagen · UniProMax

Stell dir vor du baust ein größeres Programm. Hunderte Klassen. Manche heißen Util, List, Logger. Wie verhinderst du, dass deine User mit der User aus der Library kollidiert? Pakete sind Javas Antwort: Klassen werden in Namensräumen organisiert, ähnlich wie Ordnerstrukturen.

Klausur-Vorkommnis in 9/13 WInf-Prog-1-Klausuren — typische Fragen: "Wie sieht der Import-Pfad aus?", "Was ist der Unterschied package vs. import?".

Paket (package): Eine Gruppe zusammengehöriger Klassen mit eindeutigem Namensraum, organisiert wie Ordner. Import: Mache Klassen aus anderen Paketen ohne vollen Pfad nutzbar.

package de.unihamburg.studi;  // erste Code-Zeile in der Datei!

public class Student {
    private String name;
    // ...
}

Konvention: Pakete sind kleingeschrieben, durch Punkte getrennt, oft mit umgekehrtem Domain-Namen als Präfix (com.firma.projekt, de.uni.fachbereich). Damit garantierst du weltweit eindeutige Namen.

Datei-Struktur muss zum Paket passen:

src/
└── de/
    └── unihamburg/
        └── studi/
            └── Student.java   ← package de.unihamburg.studi;

Ohne Import musst du den voll qualifizierten Namen schreiben:

java.util.ArrayList<String> liste = new java.util.ArrayList<>();

Mit Import wird das kurz:

import java.util.ArrayList;

ArrayList<String> liste = new ArrayList<>();

Import-Varianten:

import java.util.ArrayList;    // Einzelimport
import java.util.*;             // Alles aus java.util (Wildcard)
import static java.lang.Math.PI; // Statische Member direkt nutzbar

Nach import static java.lang.Math.PI kannst du PI statt Math.PI schreiben — nützlich aber kann unklar werden, wenn du nicht weißt woher das Symbol kommt.

Klassen aus java.lang (String, System, Math, Integer, Object ...) sind automatisch importiert. Du musst sie NIE explizit importieren. Deshalb funktioniert System.out.println ohne import.

Erinnerung aus dem Sichtbarkeits-Topic: ohne Modifier ist eine Klasse / ein Feld / eine Methode package-private — nur im selben Paket zugreifbar.

package de.unihamburg.studi;

class InternalHelper {  // package-private!
    void log(String msg) { /* ... */ }
}

Diese Klasse ist NICHT von außerhalb de.unihamburg.studi zugreifbar. Praktisch für interne Helper-Klassen, die nicht Teil der öffentlichen API sein sollen.

Du hast zwei Klassen mit gleichem Namen aus unterschiedlichen Paketen:

import java.util.Date;
// import java.sql.Date;  // Geht NICHT — Konflikt mit oberer Zeile

java.util.Date heute = new java.util.Date();
java.sql.Date dbDatum = new java.sql.Date(0);

Lösung: Eine importieren, die andere voll qualifiziert nutzen.

Modifier	Eigene Klasse	Selbes Paket	Subklasse (anderes Paket)	Anderes Paket
`public`	✅	✅	✅	✅
`protected`	✅	✅	✅	❌
(kein)	✅	✅	❌	❌
`private`	✅	❌	❌	❌

Bei Klausur-Fragen "Hat Klasse Z in Paket P Zugriff auf Feld f in Klasse X in Paket Q?" → diese Tabelle ist deine Antwort.

src/
├── de/uni/main/
│   └── App.java               // package de.uni.main; public class App { ... }
├── de/uni/model/
│   ├── Student.java           // package de.uni.model; public class Student { ... }
│   └── Kurs.java
└── de/uni/util/
    └── Logger.java            // package de.uni.util; public class Logger { ... }

In App.java:

package de.uni.main;

import de.uni.model.Student;
import de.uni.model.Kurs;
import de.uni.util.Logger;

public class App {
    public static void main(String[] args) {
        Student s = new Student("Anna");
        Kurs k = new Kurs("Java");
        Logger.log("App gestartet");
    }
}

1. package muss erste Code-Zeile sein. Davor nur Kommentare. Sonst Compile-Error.

2. Dateipfad muss zum Paket passen. package de.uni.test; → Datei muss unter <source>/de/uni/test/ liegen.

3. import kommt zwischen package und Klasse. Reihenfolge: package → imports → class.

4. java.lang ist auto-importiert. String, System, Math, Object brauchen kein import.

5. Wildcard-Import vs. Einzelimport: java.util.* ist okay aber unscharf. IDE-Standard ist Einzelimport für bessere Lesbarkeit.

1. Falsche package-Zeile. Wenn die Datei unter src/de/uni/Student.java liegt aber package com.firma; deklariert, gibt's Compile-Error.

2. import * macht Wildcard-Member NICHT zugreifbar. import java.util.* lädt nur Klassen, nicht statische Member. Für PI brauchst du import static java.lang.Math.PI.

3. Inneres Paket nicht implizit importiert. import java.util.* importiert NICHT java.util.concurrent.*. Du musst jede Unterebene separat importieren.

4. package-private vs. public verwechselt. Ohne public ist die Klasse nur im selben Paket nutzbar. Für eine wirklich öffentliche Klasse: public class.

5. protected ≠ "geschützt vor anderen Paketen". Genau das Gegenteil: protected ERLAUBT Zugriff aus anderen Paketen für SUBKLASSEN. package-private wäre stricter.

Eine Mini-Projekt-Struktur mit 3 Paketen. Klick auf eine Klasse: du siehst, welche Imports sie braucht und welche Sichtbarkeits-Beziehungen zu anderen Klassen existieren.

So entwickelst du ein Gefühl, wie Pakete und Imports in einem realen Projekt zusammenspielen.

Lade Visualisierung...

Klausur-Tipp: Bei Klausurfragen zur Sichtbarkeit zwischen Paketen — zeichne dir die Paket-Baum-Struktur kurz auf, markiere die Modifier (public/protected/private/package-private) und gehe die Tabelle durch. Spart Fehler.

Anmelden, um den Fortschritt zu speichern.

Nächster Schritt

Wenn du fertig bist: jetzt üben.

Aktives Abrufen festigt Wissen schneller als nochmal lesen.

Klausur-Vorkommnis in 9/13 WInf-Prog-1-Klausuren — typische Fragen: "Wie sieht der Import-Pfad aus?", "Was ist der Unterschied package vs. import?".

Die Idee in einem Satz

Paket (package): Eine Gruppe zusammengehöriger Klassen mit eindeutigem Namensraum, organisiert wie Ordner. Import: Mache Klassen aus anderen Paketen ohne vollen Pfad nutzbar.

Package-Deklaration

package de.unihamburg.studi;  // erste Code-Zeile in der Datei!

public class Student {
    private String name;
    // ...
}

Datei-Struktur muss zum Paket passen:

src/
└── de/
    └── unihamburg/
        └── studi/
            └── Student.java   ← package de.unihamburg.studi;

Import: Klassen nutzen

Ohne Import musst du den voll qualifizierten Namen schreiben:

java.util.ArrayList<String> liste = new java.util.ArrayList<>();

Mit Import wird das kurz:

import java.util.ArrayList;

ArrayList<String> liste = new ArrayList<>();

Import-Varianten:

import java.util.ArrayList;    // Einzelimport
import java.util.*;             // Alles aus java.util (Wildcard)
import static java.lang.Math.PI; // Statische Member direkt nutzbar

Nach import static java.lang.Math.PI kannst du PI statt Math.PI schreiben — nützlich aber kann unklar werden, wenn du nicht weißt woher das Symbol kommt.

java.lang ist auto-importiert

Klassen aus java.lang (String, System, Math, Integer, Object ...) sind automatisch importiert. Du musst sie NIE explizit importieren. Deshalb funktioniert System.out.println ohne import.

Sichtbarkeit auf Paket-Ebene

Erinnerung aus dem Sichtbarkeits-Topic: ohne Modifier ist eine Klasse / ein Feld / eine Methode package-private — nur im selben Paket zugreifbar.

package de.unihamburg.studi;

class InternalHelper {  // package-private!
    void log(String msg) { /* ... */ }
}

Diese Klasse ist NICHT von außerhalb de.unihamburg.studi zugreifbar. Praktisch für interne Helper-Klassen, die nicht Teil der öffentlichen API sein sollen.

Namens-Konflikte lösen

Du hast zwei Klassen mit gleichem Namen aus unterschiedlichen Paketen:

import java.util.Date;
// import java.sql.Date;  // Geht NICHT — Konflikt mit oberer Zeile

java.util.Date heute = new java.util.Date();
java.sql.Date dbDatum = new java.sql.Date(0);

Lösung: Eine importieren, die andere voll qualifiziert nutzen.

Sichtbarkeits-Übersicht mit Paketen

Modifier	Eigene Klasse	Selbes Paket	Subklasse (anderes Paket)	Anderes Paket
`public`	✅	✅	✅	✅
`protected`	✅	✅	✅	❌
(kein)	✅	✅	❌	❌
`private`	✅	❌	❌	❌

Bei Klausur-Fragen "Hat Klasse Z in Paket P Zugriff auf Feld f in Klasse X in Paket Q?" → diese Tabelle ist deine Antwort.

Beispiel: Mini-Projekt-Struktur

src/
├── de/uni/main/
│   └── App.java               // package de.uni.main; public class App { ... }
├── de/uni/model/
│   ├── Student.java           // package de.uni.model; public class Student { ... }
│   └── Kurs.java
└── de/uni/util/
    └── Logger.java            // package de.uni.util; public class Logger { ... }

In App.java:

package de.uni.main;

import de.uni.model.Student;
import de.uni.model.Kurs;
import de.uni.util.Logger;

public class App {
    public static void main(String[] args) {
        Student s = new Student("Anna");
        Kurs k = new Kurs("Java");
        Logger.log("App gestartet");
    }
}

Klausur-Faustregeln

1. package muss erste Code-Zeile sein. Davor nur Kommentare. Sonst Compile-Error.

2. Dateipfad muss zum Paket passen. package de.uni.test; → Datei muss unter <source>/de/uni/test/ liegen.

3. import kommt zwischen package und Klasse. Reihenfolge: package → imports → class.

4. java.lang ist auto-importiert. String, System, Math, Object brauchen kein import.

5. Wildcard-Import vs. Einzelimport: java.util.* ist okay aber unscharf. IDE-Standard ist Einzelimport für bessere Lesbarkeit.

Häufige Stolpersteine

1. Falsche package-Zeile. Wenn die Datei unter src/de/uni/Student.java liegt aber package com.firma; deklariert, gibt's Compile-Error.

2. import * macht Wildcard-Member NICHT zugreifbar. import java.util.* lädt nur Klassen, nicht statische Member. Für PI brauchst du import static java.lang.Math.PI.

3. Inneres Paket nicht implizit importiert. import java.util.* importiert NICHT java.util.concurrent.*. Du musst jede Unterebene separat importieren.

4. package-private vs. public verwechselt. Ohne public ist die Klasse nur im selben Paket nutzbar. Für eine wirklich öffentliche Klasse: public class.

5. protected ≠ "geschützt vor anderen Paketen". Genau das Gegenteil: protected ERLAUBT Zugriff aus anderen Paketen für SUBKLASSEN. package-private wäre stricter.

Teil 3·Quiz / Klausurfragen

Praxis-Übung

Pakete & Imports — Praxis-Übung

6 Aufgaben zu Paket-Deklaration, Imports, Sichtbarkeits-Regeln.

Klausurfragen mit Lösungen (6)

F1.Welche Zeile muss in einer Java-Datei ZUERST stehen (nach Kommentaren)?

Antwort: Die package-Deklaration

Erklärung: Reihenfolge ist FEST: package → imports → class. Wenn package falsch oder fehlt, gibt's Compile-Error. import kommt danach, dann erst die Klassen-Deklaration.

F2.Aus welchem Paket sind Klassen wie String, System, Math, Object IMMER ohne import nutzbar?

Antwort: java.lang

Erklärung: java.lang ist auto-importiert. Deshalb funktioniert System.out.println ohne import. Alle anderen Pakete (java.util, java.io, java.nio) brauchen explizite Imports.

F3.Eine Klasse OHNE Modifier (z.B. class Helper { ... }) ist von überall im selben Paket zugreifbar.

Antwort: Wahr

Erklärung: RICHTIG. Ohne Modifier ist die Sichtbarkeit package-private (auch 'default'). Im selben Paket erreichbar, in anderen Paketen NICHT (auch nicht via import).

Typ: Wahr/Falsch

F4.Welcher Import erlaubt direkten Zugriff auf PI (statt Math.PI)?

Antwort: import static java.lang.Math.PI;

Erklärung: import static erlaubt direkten Zugriff auf statische Member. Mit `import static java.lang.Math.PI` schreibst du `double u = 2 * PI * r;` statt `Math.PI`. Wildcard ginge: `import static java.lang.Math.*;`

F5.Welche Aussagen über Pakete sind RICHTIG?

Richtige Antworten: Paket-Namen sind kleingeschrieben (Konvention); package-Deklaration muss vor allen imports stehen; Die Datei-Position im Verzeichnis muss zum Paket passen; java.lang ist auto-importiert

Erklärung: Richtig: lowercase, package vor import, Verzeichnis = Paket, java.lang ist auto. Falsch: Wildcard-Import importiert KEINE Unter-Pakete (java.util.concurrent muss separat); für statische Member braucht's `import static`.

Typ: Multi-Select

F6.Ordne den Sichtbarkeits-Modifier dem Zugriff zwischen Paketen zu:

Zuordnungen:

public → Überall, auch in anderen Paketen
protected → Selbes Paket + Subklassen (auch in anderen Paketen)
(kein Modifier) → Nur im selben Paket
private → Nur in der eigenen Klasse

Erklärung: Klassische Sichtbarkeits-Matrix. Bei Klausurfragen 'kann Z von Paket P auf X.f zugreifen?' diese Tabelle anlegen.

Typ: Zuordnung

Teil 4·Quiz / Klausurfragen

Klausur-Quiz

Klausurfragen mit Lösungen (6)

F1.Datei unter src/de/uni/test/A.java. Welche package-Deklaration ist korrekt?

Antwort: package de.uni.test;

Erklärung: Der Source-Root (`src/`) zählt NICHT zum Paket-Namen. Paket = Verzeichnis-Pfad RELATIV zum Source-Root, mit Punkten statt Schrägstrichen.

F2.Klasse A in Paket p1, Klasse B extends A in Paket p2. Welcher Modifier in A erlaubt B, das Feld f zu nutzen?

Antwort: protected

Erklärung: protected: erlaubt Zugriff aus Subklassen, auch wenn sie in anderen Paketen sind. package-private wäre zu strikt (nur selbes Paket). private wäre sowieso nur in A selbst. public ist erlaubt, aber NICHT nötig.

F3.Du kannst in einer Java-Datei mehrere package-Deklarationen haben.

Antwort: Falsch

Erklärung: FALSCH. Genau EINE package-Deklaration pro Datei (oder gar keine = default-Paket). Mehrere imports sind erlaubt, aber package ist einmalig.

Typ: Wahr/Falsch

F4.Du importierst java.util.Date und java.sql.Date in derselben Datei. Was passiert?

Antwort: Compile-Fehler — Namens-Konflikt

Erklärung: Compile-Fehler: zwei Imports mit gleichem Klassennamen sind nicht erlaubt. Lösung: einen importieren, den anderen voll qualifiziert nutzen (`java.sql.Date dbDate = ...`).

F5.Pakete sind {{1}} geschrieben. Die {{2}}-Deklaration muss die ERSTE Code-Zeile sein. Klassen aus {{3}} sind automatisch importiert. Ohne Modifier ist eine Klasse {{4}} (auch default genannt).

Lösungen pro Lücke:

{{1}}: klein / kleingeschrieben / lowercase
{{2}}: package
{{3}}: java.lang
{{4}}: package-private / package private

Erklärung: Standard-Pflichtwissen über Pakete. lowercase-Konvention, package zuerst, java.lang auto, package-private als Default.

Typ: Lückentext

F6.Sortiere die Reihenfolge in einer Java-Datei:

Richtige Reihenfolge:

Kommentar / Lizenz-Header
package de.uni.test;
import java.util.ArrayList; (und weitere)
public class MyClass { ... }

Erklärung: Reihenfolge ist FEST in Java: optionale Kommentare → package (genau 1) → imports (beliebig viele) → Klassen. Tauschen → Compile-Error.

Typ: Reihenfolge

Pakete & Imports.

Erklärung

Pakete & Imports.

Erklärung

Die Idee in einem Satz

Package-Deklaration

Import: Klassen nutzen

java.lang ist auto-importiert

Sichtbarkeit auf Paket-Ebene

Namens-Konflikte lösen

Sichtbarkeits-Übersicht mit Paketen

Beispiel: Mini-Projekt-Struktur

Klausur-Faustregeln

Häufige Stolpersteine

Paket-Baum-Visualizer

Wenn du fertig bist: jetzt üben.

Die Idee in einem Satz

Package-Deklaration

Import: Klassen nutzen

java.lang ist auto-importiert

Sichtbarkeit auf Paket-Ebene

Namens-Konflikte lösen

Sichtbarkeits-Übersicht mit Paketen

Beispiel: Mini-Projekt-Struktur

Klausur-Faustregeln

Häufige Stolpersteine

Interaktiv verstehen

Paket-Baum-Visualizer

Praxis-Übung

Pakete & Imports — Praxis-Übung

Klausur-Quiz