Ein kleines, oft übersehenes Feature, das mit Java 25 offiziell in den Standard aufgenommen wurde, ist Module Import Declarations (JEP 511). Mit Module Import Declarations kann man jetzt auf die länglichen Listen von imports und static imports verzichten und alle Packages, die aus einem gemeinsamen Java-Modul stammen, mit einer einzigen Zeile zur Verfügung stellen.
Die Syntax
Schauen wir auf ein konstruiertes Beispiel. Bis Java 24 sieht das so aus.
import java.time.LocalDate;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
public class OrderReportService {
public List<String> loadOrderIds(Path file) throws IOException {
return Files.readAllLines(file);
}
public Map<LocalDate, List<String>> groupByDate(List<String> orders) {
return orders.stream()
.collect(Collectors.groupingBy(o -> LocalDate.now()));
}
}
Jetzt Java 25, mit Module Import:
import module java.base;
public class OrderReportService {
public List<String> loadOrderIds(Path file) throws IOException {
return Files.readAllLines(file);
}
public Map<LocalDate, List<String>> groupByDate(List<String> orders) {
return orders.stream()
.collect(Collectors.groupingBy(o -> LocalDate.now()));
}
}
Aus sieben Zeilen für die Imports von Klassen aus verschiedenen Paketen wird nun eine einzige Zeile, mit der alles aus dem Modul java.base importiert wird!
Das ist ein ausgezeichnetes Beispiel, um den Vorteil dieses neuen Features zu zeigen!
Nein, ist es nicht.
Meine IDE macht das doch eh schon
In einer modernen IDE ist das Problem bereits seit langem gelöst. Auto-Import schreibt die Zeilen, eingeklappter import-Block blendet sie aus, und Organize Imports entfernt die, die überflüssig geworden sind. Ob dort zehn Einzelimports stehen oder eine Zeile import module java.base, spielt praktisch keine Rolle.
Die eigentlichen Vorteile zeigen sich außerhalb der IDE.
In der Ausbildung und beim Einstieg in Java zählt die Lesbarkeit des Codes selbst mehr als IDE-Komfort. Einsteiger müssen sich nicht merken, in welchem Package List oder LocalDate liegen. Eine Zeile import module java.base; genügt.
Mit Compact Source Files (ebenfalls mit Java 25 dazugekommen) lassen sich kurze Programme für einfache Aufgaben erstellen, die ohne Klassendeklarationen auskommen. Dort ist import module java.base sogar implizit bereits enthalten, man schreibt also oft gar keine Imports mehr.
Diffs über Zeit
Das ist ein Codeausschnitt aus einer typischen Anwendung:
// Ohne import module
import java.util.List;
import java.util.Map;
public class InvoiceService {
public List<Invoice> findOpen() { ... }
}
Ein halbes Jahr später fügt eine Entwicklerin in einem Commit eine Methode hinzu, die erstmals Optional nutzt.
Das Diff enthält die neue Import-Zeile plus die eigentliche Code-Änderung.
+ import java.util.Optional;
...
+ public Optional<Invoice> findLatest() { ... }
Schauen wir auf dasselbe Szenario, diesmal mit Module Import:
// Mit import module
import module java.base;
public class InvoiceService {
public List<Invoice> findOpen() { ... }
}
Nach der Änderung steht im Diff nur die eine Code-Zeile.
+ public Optional<Invoice> findLatest() { ... }
Es ist kein import-Diff nötig, weil Optional schon über den Modulimport abgedeckt ist.
Der Nutzen zeigt sich also nicht beim einmaligen Schreiben, sondern kumulativ bei jedem späteren Commit, der einen neuen java.base-Typ einführt. Nicht „7 Zeilen werden 1 Zeile beim ersten Schreiben“, sondern „null zusätzliche Import-Diffs über die Lebensdauer der Datei, sooft neue java.base-Typen dazukommen“. Das ist sichtbar in PR-Reviews, git diff, oder GitHub-Weboberfläche ohne Folding.
Der Enterprise-Haken
Es gibt eine wichtige Einschränkung: import module funktioniert nicht für Code auf dem Classpath.
Die Anweisung erwartet einen Modulnamen, Classpath-Code besitzt jedoch keinen und kann daher nicht mit import module importiert werden.
Frameworks wie Spring Boot, Quarkus und die meisten Jakarta-EE-Runtimes leben aber eben genau dort. Die FatJars, UberJars, Extensions liegen alle im Classpath.
Das bedeutet: org.springframework.*, jakarta.persistence.*, io.quarkus.* funktioniert nicht mit import module, diese Imports müssen weiterhin explizit deklariert werden.
import module java.base; // ✅ funktioniert überall
import module org.springframework; // ❌ Compilerfehler, unnamed module
Der praktische Nutzen bleibt auf JDK-eigene Module beschränkt – der interessante Teil (Framework- und Fachcode) profitiert nicht.
Fazit
Module Import Declarations ist kein Game Changer. Es räumt den Quarkus- oder Spring-Boot-Code nicht magisch auf. Der praktische Nutzen beschränkt sich weitgehend auf JDK-eigene APIs wie java.base, java.sql oder java.net.http, und dieses Problem lösen moderne IDEs ohnehin schon seit Jahren.
Wirklich interessant wird es für Compact Source Files, die JShell, Lernmaterial, Code-Reviews und allgemein Situationen außerhalb der IDE.
