Java Academy · Lektion

Auf Module migrieren

Automatische und unbenannte Module

Auf Module migrieren ist eine kostenlose Java Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Java Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Java Academy-Kurs umfasst insgesamt 4 Lektionen.

Bestehenden Code modularisieren

Nur wenige Projekte führen Module von Anfang an ein. JPMS wurde für eine schrittweise Migration entwickelt, bei der Classpath und Modulpfad nebeneinander bestehen können.

Die entscheidenden Konzepte sind automatische Module und das unbenannte Modul.

Das unbenannte Modul

Alles, was vom Classpath geladen wird, lebt in dem einzigen unbenannten Modul. Es liest jedes andere Modul und exportiert alle seine Pakete.

Das ist die Brücke, die dafür sorgt, dass älterer Classpath-Code weiterhin funktioniert.

Benannte Module können das unbenannte Modul nicht lesen

Eine entscheidende Regel: Ein explizit benanntes Modul kann nicht vom unbenannten Modul abhängen. Sie können für Classpath-Code kein requires schreiben.

Daher migrieren Sie von unten nach oben: Konvertieren Sie zuerst die Darstellung Ihrer Abhängigkeiten.

Automatische Module

Legen Sie ein normales (nicht-modulares) JAR auf den Modulpfad, wird es zu einem automatischen Modul. Es erhält einen automatisch abgeleiteten Namen, liest alle anderen Module und exportiert alle seine Pakete.

So können benannte Module ein JAR, das noch kein module-info besitzt, mit requires anfordern.

Woher der Name stammt

Der Name eines automatischen Moduls wird in dieser Reihenfolge abgeleitet:

Der Eintrag Automatic-Module-Name im JAR-Manifest, sofern vorhanden
Andernfalls aus dem JAR-Dateinamen (Versionsangabe entfernt, Bindestriche werden zu Punkten)

Stabile Namen sind wichtig

Bibliotheksautoren sollten Automatic-Module-Name in ihr Manifest aufnehmen, bevor sie vollständig modularisieren. Dadurch wird ein stabiler Modulname zugesichert, sodass nachgelagerte requires-Klauseln auch nach dem späteren Hinzufügen des echten module-info bestehen bleiben.

Automatic-Module-Name: com.example.json

Top-down-Strategie

Für Ihre eigene Anwendung wird folgende Vorgehensweise empfohlen:

Belassen Sie Abhängigkeiten als automatische Module auf dem Modulpfad
Fügen Sie zuerst Ihrem obersten Modul ein module-info.java hinzu
Deklarieren Sie requires für die Namen dieser automatischen Module

Beispiel für einen Migrationsschritt

Angenommen, guava-32.jar liegt als automatisches Modul com.google.common auf dem Modulpfad. Ihr Anwendungsmodul kann es bereits mit requires anfordern.

module com.example.app {
    requires com.google.common;
    exports com.example.app.api;
}

Problem geteilter Pakete

Das Modulsystem verbietet, dass zwei Module dasselbe Paket enthalten. Ältere Bibliotheken, die ein Paket auf mehrere JARs aufteilen, verursachen Fehler.

Beheben Sie das Problem, indem Sie die JARs zusammenführen, --patch-module verwenden oder auf Versionen aktualisieren, die die Aufteilung beheben.

Probleme mit dem Reflexionszugriff

Frameworks, die tiefe Reflexion ausführen, können nach der Modularisierung mit InaccessibleObjectException fehlschlagen. Fügen Sie opens-Direktiven hinzu oder verwenden Sie als vorübergehende Brücke das Startargument --add-opens.

Das hilfreiche jdeps-Tool

Das Tool jdeps analysiert Ihre JARs, meldet Abhängigkeiten, weist auf die Verwendung interner JDK-APIs hin und kann mit jdeps --generate-module-info sogar einen möglichen Entwurf für module-info.java erzeugen.

Führen Sie es zuerst aus, um Ihre Migration zu planen.

Kurze Überprüfung

Rufen Sie sich in Erinnerung, wie ein normales JAR eine Modulidentität erhält.

Zusammenfassung

Sie haben Migrationstechniken gelernt:

Classpath-Code lebt im unbenannten Modul; benannte Module können es nicht mit requires anfordern
Normale JARs auf dem Modulpfad werden zu automatischen Modulen
Setzen Sie Automatic-Module-Name für stabile Namen
Achten Sie auf geteilte Pakete und Reflexionszugriff; verwenden Sie jdeps zur Planung

Damit ist der JPMS-Kurs abgeschlossen.

Häufig gestellte Fragen

Ist die Lektion „Auf Module migrieren“ kostenlos?

Ja — der vollständige Text von „Auf Module migrieren“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Java Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Java Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Auf Module migrieren“?

Automatische und unbenannte Module Du übst Java Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Java Academy zu starten?

Keine Vorkenntnisse erforderlich. Java Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Auf Module migrieren“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Java Academy-Lektion Code schreiben und ausführen?

Ja. Jede Java Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Java Academy