Modularität in Java
Kurz: Modularität bedeutet, ein Programm in klar abgegrenzte, austauschbare Bausteine (Module) zu zerlegen. Java hat dafür seit Version 9 ein eigenes Modulsystem (JPMS, Project Jigsaw).
Genauer: Pakete ordnen Klassen, Module bündeln Pakete. Ein Modul legt in einer Datei module-info.java fest, was es braucht (requires) und was es nach außen anbietet (exports). Alles andere bleibt unsichtbar, selbst wenn es public ist.
Im Detail
// module-info.java
module de.emzett.shop {
requires java.sql; // braucht das JDK-Modul java.sql
requires transitive de.emzett.kern; // gibt diese Abhängigkeit an Nutzer weiter
exports de.emzett.shop.api; // nur dieses Paket ist von außen nutzbar
opens de.emzett.shop.model to com.fasterxml.jackson.databind; // Reflection erlauben
}Ebenen im Überblick: Klasse → Paket → Modul → JAR/Anwendung.
- Starke Kapselung: Auch
publicreicht nicht, wenn das Paket nicht exportiert wird. Das schützt interne Klassen vor Missbrauch. - Verlässliche Konfiguration: Fehlt ein benötigtes Modul, scheitert der Start sofort mit einer klaren Meldung statt später mit
ClassNotFoundException. - JDK modular: Das JDK selbst besteht aus Modulen (
java.base,java.sql,java.net.http…).java.basebraucht jeder und wird automatisch eingebunden. Mitjlinkerstellt man ein verschlankte Laufzeit nur mit den benötigten Modulen. - Klassenpfad vs. Modulpfad: Alte Bibliotheken ohne
module-infolaufen weiter auf dem Klassenpfad oder als „automatische Module”. - Praxis: Viele Projekte nutzen weiterhin nur Maven- oder Gradle-Module (ohne JPMS). Das gliedert den Build in Teilprojekte, erzwingt aber keine Sichtbarkeit zur Laufzeit.
- Warum modular? Übersicht, Austauschbarkeit, getrennte Tests, klare Verantwortung, weniger „Spaghetti”.
- Allgemein: Das Prinzip gilt auch jenseits von Java: Module, Pakete, Microservices und Bibliotheken sind Formen von Modularität.
Siehe auch: Packages/API, Core, Zugriffsmodifikatoren