模組化 Netty：testsuite-jpms README 記錄的 JPMS 支援

這份 README 的範圍：Netty 4.2 的 JPMS 支援

這份 README 不是 Netty 的主要文件。它屬於 testsuite-jpms 目錄，只談一個主題：Netty 在 Java 平台模組系統（JPMS）上的行為。儲存庫中繼資料把 Netty 描述為事件驅動、非同步的網路應用框架，但這份 README 並不解釋框架的核心 API、效能或一般用法。它明確說明的是：從 4.2 版開始，Netty 提供顯式模組，取代 4.1 中使用的命名自動模組，而且正文分為使用者指南和開發者指南兩部分。

Netty 4.2 的顯式模組名稱

Netty 4.2 以反向網域名稱風格命名模組，名稱來自子專案名稱而非根套件名稱，README 把這歸因於歷史原因。清單包括 io.netty.buffer、io.netty.codec、io.netty.handler、io.netty.transport、io.netty.resolver、io.netty.common，以及許多 codec 專用模組。原生傳輸的模組名稱省略 native，因為它是 Java 保留關鍵字；transport 可以是 epoll、kqueue 或 io_uring。README 明確指出 Netty 不使用強封裝，所以所有 Java 套件都被匯出。它也提到少數 Maven 模組不再支援 JPMS：netty-transport-rxtx、netty-transport-sctp 和 netty-transport-udt。

io-netty-codec 的拆分

在 Netty 4.2 中，io-netty-codec Maven 模組被拆成四個模組。io-netty-codec-base 宣告 io.netty.codec Java 模組，包含 io.netty.handler.codec 套件，以及不需要額外依賴的內建 codec。io-netty-codec-compression、io-netty-codec-protobuf 和 io-netty-codec-marshalling 各自宣告自己的 Java 模組，並依賴第三方程式庫。為了向後相容，原來的 io-netty-codec Maven 模組依賴全部四個，所以依賴它會連帶引入 compression、protobuf 和 marshalling；你可以排除不需要的部分，或者直接依賴 io-netty-codec-base。該模組還宣告了一個空的 io.netty.codec.unused JPMS 模組，以滿足 jlink 這類期望模組化 jar 的工具。

原生程式庫放在獨立的執行時期模組中

原生傳輸、HTTP/3 和 OpenSSL 支援都遵循同樣的模式。classes 模組（如 io.netty.transport.classes.epoll 或 io.netty.tcnative.classes.openssl）包含 Java 類別（如 EpollServerSocketChannel），是必需的。另一個名稱裡帶 os.name 和 os.arch 的模組（例如 io.netty.transport.${transport}.${os.name}.${os.arch}）持有原生程式庫，只在執行時期需要存在。README 建議依賴 classes 模組，並在執行時期再加入原生模組，因為作業系統和架構會變化。壓縮模組只在真正使用對應演算法時才需要。

第三方依賴及其 JPMS 狀態

README 用一張表列出 Netty 模組依賴的第三方程式庫。當 jar 提供 module-info.class 描述符時標為 explicit（顯式）；當 jar 是命名自動模組時標為 automatic（自動）；可以省略的依賴標為 optional（可選）。例如 io.netty.common 可以使用 commons-logging、log4j、log4j2 或 slf4j，它們都是顯式且可選的。io.netty.codec.protobuf 需要 Google Protobuf 和 protobuf.nano，兩者都是自動模組，且該依賴不可選。這張表是這項資訊的唯一來源；README 沒有評估這些依賴是否得到維護或是否安全。

應用程式映像與範例伺服器

jlink 工具可以建立應用程式映像，Netty 支援它，但有限制：依賴必須是顯式模組。testsuite-jpms 模組包含一個整合了原生傳輸和 OpenSSL 的簡單 HTTP 伺服器，使用 Apache Maven JLink 外掛程式建置。README 展示了執行映像的命令形式：./target/maven-jlink/default/bin/java -m io.netty.testsuite_jpms.main/io.netty.testsuite_jpms.main.HttpHelloWorldServer。伺服器會列印傳輸類別和引導層模組，並接受連接埠、傳輸方式（nio、kqueue、epoll、io_uring）、SSL 提供者和 HTTP/3 等選項。每個選項的完整命令範例都寫在 README 裡。

開發者指南：保持模組乾淨

開發者指南面向不熟悉 JPMS 的 Netty 貢獻者。它要求新建的 Java 套件不能造成拆分套件，也就是說該套件不能用在另一個 Netty 模組裡；目前還沒有工具強制執行這一點，所以要靠開發者自覺。新增外部依賴時，最好選用顯式模組；如果做不到，可以透過把依賴設為可選（requires static）或新建 Maven 模組來容忍自動模組。專案中唯一的 META-INF 服務用法是 ChannelInitializerExtension，在 module-info.yml 描述符中宣告。testsuite-jpms 在模組化執行時期中執行測試，不使用類別路徑，在 Surefire 設定裡用 classpathDependencyExcludes 排除所有 jar。原生程式庫資源放在套件結構之外，例如 META-INF/native/libnetty_quiche42_osx_aarch_64.jnilib，因此原生程式庫模組不需要匯出，也不需要在編譯時期存在。

現有資料沒有說明的內容

README 沒有提供基準測試、使用者數量、安全保證或生產結果，本文也沒有補充這些。儲存庫中繼資料記錄了 Apache-2.0 的 SPDX 標識，但本次審核提供的授權條款摘錄中沒有授權條款文本，所以無法在此描述 Apache-2.0 授予了什麼。完整評估所需的事實，例如某個原生傳輸在某個作業系統上的具體行為，或所列第三方依賴的維護狀況，README 都沒有說明，需要另行核實。

針對 Netty 4.2，請以其 Gradle wrapper 執行 testsuite-jpms 測試，並在目標 JDK 上驗證顯式模組、native transport 與事件迴圈的啟動結果。 第1項檢查仍須記錄 netty 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第2項檢查仍須記錄 netty 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第3項檢查仍須記錄 netty 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第4項檢查仍須記錄 netty 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第5項檢查仍須記錄 netty 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第6項檢查仍須記錄 netty 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第7項檢查仍須記錄 netty 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。 第8項檢查仍須記錄 netty 的實際結果，包含版本、命令輸出、設定檔、服務狀態、錯誤訊息、資料內容、權限邊界、網路行為、資源消耗與回復步驟，不能以介面顯示正常代替完整證據。

編輯結論

這份 README 只談模組化：它列出模組名稱、codec 拆分、執行時期原生模組、依賴狀態和貢獻者規則，並未聲稱任何效能或安全結果。儲存庫中繼資料記錄了 Apache-2.0 標識，但沒有提供授權條款文本。

官方來源

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