Modulares Netty: was das testsuite-jpms README über JPMS dokumentiert

Worum es in diesem README geht: JPMS-Unterstützung in Netty 4.2

Dieses README ist nicht die Hauptdokumentation von Netty. Es gehört zum Verzeichnis testsuite-jpms und behandelt ein Thema: das Verhalten von Netty im Java Platform Module System (JPMS). Die Repository-Metadaten beschreiben Netty als ereignisgesteuertes, asynchrones Netzwerk-Anwendungs-Framework, aber dieses README erklärt weder die Kern-APIs noch die Leistung oder die allgemeine Verwendung. Was es feststellt, ist, dass Netty ab Version 4.2 explizite Module statt der in 4.1 verwendeten benannten automatischen Module bereitstellt und dass der Text in einen Benutzerleitfaden und einen Entwicklerleitfaden geteilt ist.

Explizite Modulnamen in Netty 4.2

Netty 4.2 deklariert seine Module mit Namen im Reverse-DNS-Stil, die von den Subprojektnamen und nicht von den Wurzelpaketen abgeleitet sind; das README führt das auf historische Gründe zurück. Die Liste umfasst io.netty.buffer, io.netty.codec, io.netty.handler, io.netty.transport, io.netty.resolver, io.netty.common und viele codec-spezifische Module. Bei nativen Transports wird das Wort native weggelassen, weil es ein reserviertes Schlüsselwort in Java ist; transport kann epoll, kqueue oder io_uring sein. Das README stellt klar, dass Netty keine starke Kapselung verwendet und daher alle Java-Pakete exportiert werden. Es vermerkt auch, dass einige Maven-Module JPMS nicht mehr unterstützen: netty-transport-rxtx, netty-transport-sctp und netty-transport-udt.

Die Aufteilung von io-netty-codec

In Netty 4.2 ist das Maven-Modul io-netty-codec in vier Module aufgeteilt. io-netty-codec-base deklariert das Java-Modul io.netty.codec und enthält das Paket io.netty.handler.codec mit eingebauten Codecs, die keine zusätzlichen Abhängigkeiten brauchen. io-netty-codec-compression, io-netty-codec-protobuf und io-netty-codec-marshalling deklarieren jeweils ein eigenes Java-Modul und hängen von Drittanbieter-Bibliotheken ab. Aus Gründen der Abwärtskompatibilität hängt das alte Maven-Modul io-netty-codec von allen vier ab, sodass eine Abhängigkeit davon compression, protobuf und marshalling mitbringt; man kann nicht benötigte Teile ausschließen oder direkt von io-netty-codec-base abhängen. Das Modul deklariert außerdem ein leeres JPMS-Modul io.netty.codec.unused, um Werkzeuge wie jlink zufriedenzustellen, die modulare Jars erwarten.

Nativebibliotheken liegen in eigenen Laufzeitmodulen

Native Transports, HTTP/3 und OpenSSL folgen demselben Muster. Ein Klassenmodul wie io.netty.transport.classes.epoll oder io.netty.tcnative.classes.openssl enthält die Java-Klassen wie EpollServerSocketChannel und ist erforderlich. Ein zweites Modul mit os.name und os.arch im Namen, zum Beispiel io.netty.transport.${transport}.${os.name}.${os.arch}, enthält die native Bibliothek und muss nur zur Laufzeit vorhanden sein. Das README empfiehlt, vom Klassenmodul abzuhängen und das native Modul zur Laufzeit hinzuzufügen, weil Betriebssystem und Architektur variieren. Kompressionsmodule werden nur benötigt, wenn der Algorithmus tatsächlich verwendet wird.

Drittanbieter-Abhängigkeiten und ihr JPMS-Status

Das README enthält eine Tabelle der Drittanbieter-Abhängigkeiten, die Netty-Module verwenden. Abhängigkeiten werden als explizit markiert, wenn das Jar einen module-info.class-Deskriptor bereitstellt, als automatisch, wenn das Jar ein benanntes automatisches Modul ist, und als optional, wenn die Abhängigkeit weggelassen werden kann. Zum Beispiel kann io.netty.common commons-logging, log4j, log4j2 oder slf4j verwenden, alle explizit und alle optional. io.netty.codec.protobuf benötigt Google Protobuf und protobuf.nano als automatische Module, und diese Abhängigkeit ist nicht optional. Die Tabelle ist die einzige Quelle dieser Information; das README bewertet nicht, ob diese Abhängigkeiten gepflegt oder sicher sind.

Anwendungsimages und der Beispielserver

Das Werkzeug jlink kann Anwendungsimages erzeugen, und Netty unterstützt das mit Einschränkungen, die aus Abhängigkeiten entstehen, welche explizite Module sein müssen. Das testsuite-jpms-Modul enthält einen einfachen HTTP-Server, der native Transports und OpenSSL integriert und mit dem Apache Maven JLink Plugin gebaut wird. Das README zeigt, wie man das erzeugte Image ausführt, mit einem Befehl der Form ./target/maven-jlink/default/bin/java -m io.netty.testsuite_jpms.main/io.netty.testsuite_jpms.main.HttpHelloWorldServer. Der Server gibt die Transportklasse und die Module der Boot-Ebene aus und akzeptiert Optionen für Port, Transport (nio, kqueue, epoll, io_uring), SSL-Anbieter und HTTP/3. Vollständige Befehlsbeispiele für jede Option stehen im README.

Der Entwicklerleitfaden: Module sauber halten

Der Entwicklerleitfaden richtet sich an Netty-Beitragende, die JPMS nicht kennen. Er besagt, dass ein neues Java-Paket kein Split-Paket erzeugen darf, das heißt, das Paket darf in keinem anderen Netty-Modul verwendet werden; bisher gibt es kein Werkzeug, das das erzwingt, also verlässt sich die Prüfung auf die Entwickler. Neue externe Abhängigkeiten sollten möglichst explizite Module sein; automatische Module sind tolerierbar, wenn man die Abhängigkeit optional macht, mit requires static, oder ein neues Maven-Modul einführt. Die einzige META-INF-Service-Nutzung im Projekt ist ChannelInitializerExtension, deklariert im module-info.yml-Deskriptor. testsuite-jpms führt Tests in einer modularen Laufzeit ohne Klassenpfad aus und nutzt classpathDependencyExcludes im Surefire-Abschnitt. Native Bibliotheksressourcen liegen außerhalb der Paketstruktur, zum Beispiel META-INF/native/libnetty_quiche42_osx_aarch_64.jnilib, daher brauchen native Module keine Exports und müssen zur Kompilierzeit nicht vorhanden sein.

Was die bereitgestellten Quellen nicht abdecken

Das README begründet keine Benchmarks, Nutzerzahlen, Sicherheitszusicherungen oder Produktionsergebnisse, und dieser Artikel fügt keine hinzu. Die Repository-Metadaten führen eine Apache-2.0-SPDX-Kennung, aber der für diese Prüfung bereitgestellte Lizenzauszug enthält keinen Lizenztext, sodass hier nicht beschrieben werden kann, was Apache-2.0 gewährt. Tatsachen, die für eine vollständige Bewertung wichtig wären, etwa das Verhalten eines bestimmten nativen Transports auf einem bestimmten Betriebssystem oder der Pflegestatus der genannten Drittanbieter-Abhängigkeiten, stehen nicht im README und müssten gesondert verifiziert werden.

Redaktionelles Fazit

Dieses README beschränkt sich auf Modularität: Es dokumentiert Modulnamen, die Codec-Aufteilung, reine Laufzeit-Nativemodule, den Status von Abhängigkeiten und Regeln für Beitragende und behauptet keine Leistungs- oder Sicherheitsergebnisse. Die Repository-Metadaten führen eine Apache-2.0-SPDX-Kennung, aber der Lizenztext wurde nicht bereitgestellt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes