更新日誌

6.0.19 2026-08-15

未登入帳號加密時明確提示試用版有效期

• 未提供帳號憑證時，CLI 的警告現在會明確說明：產生的受保護應用使用試用授權，僅能執行 7 天，並附上購買授權的網址 https://protector4j.com。先前的警告只提到「試用授權」，沒有說明這對應用意味著什麼。
• GUI 在開始加密前會以對話方塊顯示同樣的提示，提供三個選擇：購買、繼續任務、取消任務。購買按鈕開啟的是目前所選伺服器區域對應的購買頁面，選擇 .cn 區域的使用者不會被帶到 .com 網站。

支援從其它工具帶參數啟動 GUI

• GUI 現在接受啟動參數：p4j-ui [--task-file <file>] [<input-file>]。傳入任務檔案會走正常的匯入流程，直達最終確認頁。傳入一般輸入路徑則預先填入新任務：.war 自動進入 Tomcat 流程，.jar 停在應用類型選擇頁，因為一個 JAR 可能是 Java 應用、Spring Boot 應用或類別庫。這是為 IDE 外掛等外部工具準備的整合入口；未知的橫線參數會被忽略，不帶參數啟動 GUI 的行為與先前完全一致。

獨立類別庫加密標記為開發中

• 獨立類別庫加密在 6.x 線尚未就緒，現在明確標記出來：GUI 中對應的選擇卡片變灰並帶「開發中」標記，CLI 的 encode 指令會輸出說明訊息後結束，不再開始任務。該功能會在後續版本提供。

6.0.18 2026-08-13

Spring Boot p4jx-fat 版面配置支援多版本 JAR

• 修正了 Spring Boot p4jx-fat 版面配置下多版本相依套件只會載入基礎版本的問題。類別載入器解開巢狀的 BOOT-INF/lib 相依套件時，是依字面路徑存放項目的，因此 META-INF/versions/ 下的類別永遠選不到，總是回退到基礎版本。一個具體症狀是：搭配 Spring Framework 7.0.5 時，VirtualThreadDelegate 解析到的是基礎版本的樁實作，而它會無條件擲出 UnsupportedOperationException，因此在 JDK 25 上啟用 spring.threads.virtual.enabled=true 的應用程式無法啟動。許多常用相依套件都以多版本 JAR 形式發布，其他與版本相關的程式碼路徑同樣受影響。
• 現在類別載入器會在載入時解析多版本項目，依執行中的 JDK 選出適用的最高版本；封裝器建立 fat 資源索引時套用同一套規則，確保索引與載入器對「哪一份生效」的判斷始終一致。另外兩種版面配置 fat 與 separate 從未受影響，它們把相依套件保留為一般 JAR 檔案，由 JVM 自行開啟。

6.0.17 2026-08-13

修正 Windows 上路徑含非 ASCII 字元時加密應用程式無法啟動

• 修正了在 Windows 上應用程式路徑含有中文等非 ASCII 字元時，加密後的應用程式無法啟動的問題。視路徑在哪裡被讀錯，啟動會回報封存錯誤 E816，或是表現為解密失敗的 ClassFormatError。執行環境開啟封存檔與正規化路徑都是逐位元組處理的，因此傳統字碼頁中第二個位元組恰好是 0x5C（反斜線）的字元會被從中間切開，後半個位元組被當成目錄分隔符號。GBK 裡有大量常用漢字正好是這種編碼。完全由 ASCII 字元組成的路徑從未受影響。
• Windows 上執行環境現在會先依系統 ANSI 字碼頁將路徑轉為寬字元，再開啟檔案並計算執行環境指紋——原廠 JDK 一直都是這樣開啟檔案的。只變更了 Windows 分支，Linux 與 macOS 的行為與先前完全相同。五條 JDK 線都已帶此修正重新建置：JDK 25、21、17 升至 VLX 1.0.22，JDK 11 升至 VLX 1.0.20，JDK 8 升至 VLX 1.0.13。

6.0.16 2026-08-10

修正 Windows 上打包 Linux 與 macOS 目標失敗

• 修正在 Windows 上、目標平台為 Linux 或 macOS 時打包失敗的問題。解壓隨附執行環境時會回報 Failed to extract P4JX runtime，但實際上執行環境已經正確解壓完成。Windows 上建立符號連結需要提升權限，而 Linux 與 macOS 的執行環境在 legal/ 底下有一百多個符號連結——那些是 jlink 為了避免重複存放而指向 java.base 的授權文字。Windows 內建的 tar 命令把建不了連結視為警告，卻仍然回傳非零結束碼，編碼器據此判定為徹底失敗，並把已經解壓好的執行環境刪掉了。在 Windows 上打包 Windows 目標從未受影響，因為 Windows 執行環境裡根本沒有符號連結。
• 封存處理不再依賴各平台的 tar 命令。編碼器現在自己讀取並解壓 .tar.gz 執行環境與 JavaFX 素材，因此在 Windows、Linux、macOS 上行為完全一致。檔案權限（包括啟動器的可執行位元）取自封存本身，而非宿主檔案系統。Windows 上會略過那些授權符號連結：它們對執行環境沒有任何功能作用，也不參與執行環境指紋，因此在 Windows 上加密的應用程式解密行為與以往完全相同。

6.0.15 2026-08-08

更新對話框修正

• 「有新版本」對話框現在以固定的合理尺寸開啟，變更記錄較長時不再佔滿整個螢幕。
• 工具列新增「檢查更新」項目，隨時都能檢查新版本，不再只在啟動時檢查。

6.0.14 2026-08-07

字串常數內聯加密，現為預設

• 新增內聯字串保護模式：將載入字串的 ldc 指令改寫成對本類別合成解密方法的呼叫，字串常數的明文被徹底從常數池移除。明文在類別載入時不再進入 SymbolTable，只有真正執行到那行程式碼時才出現在堆積上，未使用的字串始終保持密文。密文隨類別本體一同攜帶，並受既有的逐方法加密保護——這是純編碼器側的位元組碼變換：歸檔格式與執行階段都不變，在所有支援的 JDK 線上都無需更新執行階段即可生效。
• 字串保護現整合為一個選項、三種模式——無、普通加密（常數池 V72）、內聯，且內聯是所有應用類型（含 Tomcat）的預設值。已在普通 servlet、字串 switch 商業邏輯、以及 JspC 預先編譯的 JSP servlet 類別上端到端驗證。命令列開關為 --encrypt-strings none|constant|inline，GUI 提供相同選項。
• 無法改寫的方法——舊類別檔格式的介面、逼近 64 KB 上限的方法、或罕見的序列化邊界情形——會回退到普通的 V72 層，因此結果絕不弱於以往。

Spring Boot p4jx-fat 啟動更快

• 純 fat 佈局的 Spring Boot 類別載入器現在按需讀取其巢狀資源索引，而非預先全部載入，減少大型 p4jx-fat 應用的啟動開銷。

從環境變數讀取帳號憑證

• encode、javaapp、springboot、tomcat 命令及任務檔模式現在可以從 P4JX_ACCOUNT_EMAIL 和 P4JX_ACCOUNT_PASSWORD（或 P4JX_ACCOUNT_PASSWORD_MD5）讀取帳號信箱與密碼，僅在對應命令列選項缺席時使用，因此匯出的任務檔不含憑證。

6.0.13 2026-08-05

修復使用 javax.lang.model 的受保護應用啟動失敗

• 修復受保護應用啟動時拋出 NoClassDefFoundError: javax/lang/model/SourceVersion 的問題——這類應用的框架會引用 javax.lang.model API，最典型的是 Spring Data JPA，它的儲存庫 AOT processor 在容器初始化時會用到 SourceVersion。先前從裁剪執行時移除的 java.compiler 模組現已重新納入。它是純 API 模組，不含編譯器實作，因此 ToolProvider.getSystemJavaCompiler() 仍回傳 null、jdk.compiler 仍然缺席——防護面沒有任何變化。
• JDK 17、21、25 的執行時重建為 VLX 1.0.21，JDK 11 重建為 VLX 1.0.19，都帶上了恢復的 java.compiler 模組。JDK 8 不受影響，因為它沒有模組系統、本就自帶這些類別。

6.0.12 2026-08-02

支援 JxBrowser 9，並修正受保護應用拋出 NullPointerException 時的當機

• 受保護應用現在可以內嵌 JxBrowser 9。--native-compat jxbrowser 會從內建目錄的九個版本（9.0.0 至 9.3.1）中選擇一個，涵蓋 Java 17、21、25 上的七個平台。執行階段只會把執行緒 attach 權限授予所選版本已登記 SHA-256 的官方 IPC 程式庫，並在執行緒真正 attach 時重新核對呼叫模組；命令列不接受路徑、雜湊或程式庫名稱。在 macOS 26 上請使用 JxBrowser 9.0.1 或更新版本：TeamDev 在該版本修正了建立 Engine 時的 Chromium 當機，9.0.0 在一般 JDK 上同樣會當機。
• 修正受保護應用拋出 NullPointerException 時出現 ClassFormatError 的問題。6.0.9 的修正逐一方法抑制 JVM 的擴充 NPE 訊息，事實證明並不徹底：該功能會依標準位元組碼文法解析方法主體，而 P4JX 變換過位元組碼之後，沒有任何以方法為單位的旗標能證明這次解析仍然有效。執行階段現在無條件停用擴充訊息。例外型別、呼叫堆疊以及應用自己提供的訊息都不受影響。JDK 17、21、25 的執行階段重建為 VLX 1.0.20；JDK 11 不受此問題影響，維持 VLX 1.0.18，JDK 8 維持 VLX 1.0.12。
• java -version 現在會顯示 VLX 執行階段版本，不必解壓縮就能識別交付包內的執行階段。
• Windows EXE 的兩個版本欄位改為在打包開始前驗證，不再跑到一半才失敗。Windows 會把每一段版本號存成不帶正負號的 16 位元整數，因此以點分隔的一到四個數字每個都必須介於 0 到 65535 之間；欄位留空仍然表示 0.0.0.0。

6.0.11 2026-07-27

受保護應用程式的原生 Windows 啟動器

• Java App 封裝、三種 Spring Boot 配置和 Tomcat 封裝現在都能選擇產生原生 Windows EXE。Windows x64、x86 與 ARM64 均提供主控台及 GUI 啟動器，原有啟動指令碼也會繼續保留在每個封裝中。
• CLI 與 GUI 新增 EXE 檔名、模式、圖示及 Windows 版本中繼資料設定。多平台任務只會為選取的 Windows 目標產生 EXE；設定會保存在版本 2 的 p4j-task.yml 中，版本 1 的任務檔案仍可讀取。
• 純 Win32 的 JExeKit 啟動器已與封裝內的 vlxjre、精確 classpath 及 JVM 參數整合。啟動 Java 前，啟動器會拒絕逸出封裝範圍的路徑、透過重新解析點進行的替換，以及不安全的 agent 或 boot classpath 選項。
• JExeKit 範本只會以 AES-GCM 加密的 .jxt 資源嵌入，產生啟動器時僅在記憶體中解密。每個產生的啟動器都會為參數區塊加入 production 狀態的 Ed25519 簽章；圖示、版本、manifest 與參數變更會在使用者最後套用 Authenticode 簽章前全部完成。

6.0.10 2026-07-27

更快且保留原始結構的 Tomcat 相依套件載入

• 修復 Tomcat 啟動嚴重變慢的問題：先前每載入一個類別，都會重新讀取受保護的整個 WEB-INF/lib 巢狀 JAR 並計算雜湊。VLX 1.0.17 現在對每個已密封的巢狀 JAR 只驗證一次，在 VM 內快取其已驗證來源，並繼續依據加密類別索引逐一驗證每個要求載入的類別。
• 移除暫時的 web-libs 解壓縮與掛載權宜方案。WEB-INF/lib/*.jar 會繼續保留在受保護的 .p4jx 封存檔內，維持原始 WAR 結構與應用程式隔離。JDK 11、17、21 與 25 的 VLX 1.0.17 執行環境已涵蓋 24 個受支援的平台組合；JDK 8 保留原有 ZIP overlay 路徑並繼續使用 VLX 1.0.11。
• 修復應用程式 module-info.class 的相容性掃描。模組描述元不含方法主體，現在會自動排除在加密範圍之外，同時仍可由描述元工具正常讀取。
• GUI 匯出的 CLI 命令現在可以把 --java-version、--target-platform 與 --create-new-folder 當作連續後綴放在封裝器參數之後；原有的前綴寫法仍然受到支援。

6.0.9 2026-07-25

加密應用列印空指標例外時的崩潰修復

• 修復了一個 JVM 崩潰問題：當受保護方法拋出隱式 NullPointerException、且應用讀取其訊息或列印堆疊時可能觸發。執行環境的「友善 NPE 提示」功能會嘗試從該方法的加密位元組碼中還原 "because ... is null" 說明文字，進而解參考非法記憶體、導致 VM 崩潰（在 JavaFX FXML 應用中觀察到）。受保護方法現在會略過該說明文字，退回為標準的 NullPointerException；例外型別、堆疊以及應用自行提供的訊息均不受影響。
• JDK 17、21 和 25 的執行環境隨本次修復重建為 VLX 1.0.16。JDK 11 不受影響，因為「友善 NPE 提示」功能在 JDK 14 之前並不存在，繼續保持 VLX 1.0.15；JDK 8 繼續保持 VLX 1.0.11。

6.0.8 2026-07-24

隨用下載的 Tomcat 執行環境與生產安全預設值

• 修復已發布的自我保護編碼器無法封裝 Tomcat WAR 的問題：app.p4jx 中的 Tomcat 類別不再以實體 classpath JAR 的形式可見。Tomcat 9.0.107 與 10.1.53 現在作為不可變且帶版本號的 R2/COS 成品，依 Servlet 命名空間自動選擇，首次使用時下載並快取於本機，同時核對精確的 SHA-256 與 JAR 清單。遭竄改的快取會被捨棄並重新下載。
• 公開的 WEB-INF/lib JAR 現在會作為依應用程式隔離、受雜湊綁定的實體 Web 資源寫入磁碟，避免 Spring 啟動期間為每個類別重複讀取及驗證巢狀封存檔。
• 新建置現在預設使用生產許可端點 https://protector4j.com。只有明確設定 P4JX_LICENSE_MODE=dev 或 -PlicenseMode=dev 時，才會使用內部端點 http://10.10.10.16:16002。

6.0.7 2026-07-24

Tomcat 巢狀相依套件與可信動態類別

• 修復受保護的 Tomcat WAR 從 WEB-INF/lib/*.jar 載入類別或服務時的失敗。Protector4J 現在會將巢狀 JAR 和類別的精確 SHA-256 中繼資料密封到 app.p4jx 中；未知、遭替換或遭竄改的相依套件仍會被拒絕。
• 修復 JDK 11 的 MethodHandles.Lookup#defineClass 使用 JDK 11 特有來源標記而導致的 Spring CGLIB 和 Hibernate Byte Buddy 失敗。動態信任仍必須來自 VM 已驗證的呼叫類別或載入器來源；標記字串、類別名稱、路徑、套件名稱和 CodeSource 均不能授予信任。
• 為 JDK 11、17、21 和 25 發布 VLX 1.0.15 執行環境，涵蓋 24 個受支援平台組合。全部通過嚴格的 L1-L5 門禁，包括真實 FXML、Swing/AWT、Tomcat 巢狀相依套件載入，以及來源與竄改的負向場景。JDK 8 繼續保持 VLX 1.0.11。

6.0.6 2026-07-22

可信類別定義來源傳播

• 修復受保護 JavaFX FXML 應用程式啟動失敗的問題：MethodUtil 會透過 defineClass(byte[]) 定義已由 VM 驗證來源的 Trampoline 輔助類別。現在信任只會從 VM 已驗證的類別或載入器來源傳播，不再來自類別名稱、路徑、套件名稱或 CodeSource 字串。
• 新增真實 FXML 覆蓋，包括 fx:controller、屬性元素、Controller 注入和 WebView 啟動，並加入可信動態定義、兩級傳播、未知來源、未授權 JAR，以及替換 protected class 名稱的回歸測試。
• 發布 JDK 11、17、21 和 25 的 VLX 1.0.14 執行環境。JDK 8 繼續保持 VLX 1.0.11。

6.0.5 2026-07-21

JavaFX 原生執行環境完整性

• 透過將封裝好的 JavaFX DLL 檔案放置於 vlxjre/bin，並調整啟動程式的原生函式庫搜尋路徑，修復了 Windows 環境下 JavaFX WebView 啟動失敗的問題（Graphics Device initialization failed / No toolkit found）。
• 將已加密的 app.p4jx 允許清單擴展至外部原生函式庫。無論路徑如何，JavaFX 原生檔案都必須與精確的 SHA-256 值相符，且 Glass 會重新驗證實際載入的檔案；無法辨識或經過竄改的檔案將會被拒絕。
• 為 JDK 11、17、21 和 25 發布了更新後的 Protector4J 執行環境。所支援的 JavaFX 平台組合已通過 L5.1-L5.4，涵蓋 WebView 啟動，以及對模組 JAR、jdk.jsobject 和 Glass 原生函式庫的竄改拒絕。

6.0.4 2026-07-21

外部模組完整性與 JavaFX 執行時相容性

• 已移除對外部模組的路徑信任機制。現在，每個外部模組 JAR 都必須與嵌入 app.p4jx 的精確 SHA-256 允許清單項目相符；無論位於何處，未識別或遭篡改的檔案都會被拒絕。
• 新增從 JavaFX module-info.class 自動偵測依賴關係閉包的功能，並控制已固定 JavaFX 與 JDK 模組的引入，包括 javafx.media 與 jdk.jsobject。
• 透過新發布的 P4JX 執行時，修復所有受支援 JDK 版本及平台上的 JavaFX WebView 啟動問題，以及建立啟動層後的 E818 / ClassFormatError 錯誤。

6.0.3 2026-07-20

JavaFX WebView 模組相容性

• 修正由相同 JDK/VLX 版本重新建置的受支援 P4JX 執行環境之可選 jdk.jsobject 解析問題。封裝不再僅因完整 lib/modules 映像的位元組不同而拒絕相容的執行環境。
• 保留依訓練線與平台選擇製品、模組精確 SHA-256 與模組名稱驗證，並在安裝後重新驗證相依性閉包。

6.0.2 2026-07-20

JavaFX WebView 相容性

• 修正 JavaFX WebView 啟動失敗：將 javafx.media 與 javafx.web 一起封裝，並在精簡執行環境未包含模組時，自動解析與 P4JX 精確匹配的 jdk.jsobject。
• 新增從區域公開下載服務取得可選模組的功能；製品固定 SHA-256，並綁定版本、平台與執行環境。已包含該模組的執行環境會略過下載。

6.0.1 2026-07-20

JavaFX 相容性

• 修復內嵌 JavaFX 執行階段類別的 fat JAR 啟動失敗問題。相容性自動套用現在會讓內嵌的 JavaFX API、實作及 JNI 橋接命名空間保持未加密，避免與隨附的 JavaFX 模組產生重複歸屬衝突。
• 改善使用 shaded JavaFX 執行階段之應用程式的相容性診斷及多語言指引。

6.0.0 2026-07-20

Protector4J 6.0 是建立在全新防護架構上的重大版本，並非 5.x 系列的一般增量更新。

架構與防護

• 重新設計 Protector4J 的基礎架構，並引入全新的 P4JX 防護引擎。
• 在封存檔產生、類別載入、執行階段、反偵錯及成品完整性等層面新增接近 100 道防護措施。
• 大幅提高逆向分析門檻。新架構的目標是在使用先進 AI 輔助分析工具的情況下，也讓短期破解變得極其困難。
• 強化授權請求、執行階段下載、成品驗證及跨平台安裝套件的安全性。

產品體驗

• 支援 JDK 8、11、17、21 和 25，並為 Java、JavaFX、Spring Boot 和 Tomcat 應用程式提供圖形化封裝流程。
• 新增相容性掃描、選擇性類別加密、相依 JAR 防護、YAML 工作匯入/匯出及多目標平台批次建置。
• 重新設計桌面介面，支援 11 種語言並可持續儲存語言偏好。

遷移說明

Protector4J 6.0 與之前版本在使用方式上有較大差異。使用前請重新閱讀最新文件，並儘快使用 6.0 重新建置及遷移現有的加密應用程式，以獲得更強大的防護。

下載 Protector4J 6.0

早期版本