Nhật ký thay đổi

6.0.19 2026-08-15

Thông báo rõ ràng hơn về giấy phép dùng thử khi mã hóa mà không có tài khoản

• Khi không cung cấp thông tin đăng nhập tài khoản, cảnh báo của CLI giờ đây nêu rõ rằng ứng dụng được bảo vệ sẽ dùng giấy phép dùng thử và chỉ chạy được trong 7 ngày, đồng thời chỉ dẫn tới https://protector4j.com để mua giấy phép. Trước đây cảnh báo chỉ nhắc đến "giấy phép dùng thử" mà không giải thích điều đó có ý nghĩa gì với ứng dụng.
• Giao diện đồ họa hiển thị cùng thông báo này trong một hộp thoại trước khi bắt đầu mã hóa, với ba lựa chọn: Mua, Tiếp tục tác vụ và Hủy tác vụ. Nút mua mở trang mua hàng của khu vực máy chủ đang được chọn, vì vậy người dùng khu vực .cn sẽ không bị đưa sang trang .com.

Tham số khởi động để mở giao diện đồ họa từ công cụ khác

• Giao diện đồ họa giờ đây chấp nhận tham số khởi động: p4j-ui [--task-file <file>] [<input-file>]. Tệp tác vụ đi qua luồng nhập thông thường và tới thẳng trang xác nhận cuối cùng. Một đường dẫn đầu vào thông thường sẽ được điền sẵn vào tác vụ mới: tệp .war tự động chọn luồng Tomcat, còn tệp .jar dừng ở trang chọn loại ứng dụng, vì một JAR có thể là ứng dụng Java, ứng dụng Spring Boot hoặc thư viện. Đây là giao diện tích hợp dành cho các công cụ bên ngoài như plugin IDE; các tham số gạch ngang không xác định sẽ bị bỏ qua, nên việc mở giao diện đồ họa không kèm tham số hoạt động hoàn toàn như trước.

Mã hóa thư viện độc lập được đánh dấu là đang phát triển

• Mã hóa thư viện độc lập chưa sẵn sàng trong dòng 6.x và giờ đây được đánh dấu rõ ràng: thẻ tương ứng trong giao diện đồ họa bị làm mờ kèm nhãn "Đang phát triển", và lệnh encode của CLI kết thúc với thông báo giải thích thay vì bắt đầu tác vụ. Tính năng này sẽ được cung cấp trong một bản phát hành tương lai.

6.0.18 2026-08-13

Hỗ trợ JAR đa phiên bản trong bố cục p4jx-fat của Spring Boot

• Đã sửa lỗi khiến các phụ thuộc đa phiên bản luôn được nạp từ phiên bản cơ sở trong bố cục p4jx-fat của Spring Boot. Khi giải nén một JAR lồng nhau trong BOOT-INF/lib, trình nạp lớp lưu các mục theo đúng tên nguyên văn, nên những lớp nằm dưới META-INF/versions/ không bao giờ được chọn và luôn quay về phiên bản cơ sở. Một biểu hiện cụ thể: với Spring Framework 7.0.5, VirtualThreadDelegate được phân giải thành bản stub của phiên bản cơ sở, vốn ném UnsupportedOperationException một cách vô điều kiện, nên ứng dụng chạy trên JDK 25 với spring.threads.virtual.enabled=true không khởi động được. Rất nhiều phụ thuộc phổ biến được phát hành dưới dạng JAR đa phiên bản, nên các nhánh mã phụ thuộc phiên bản khác cũng bị ảnh hưởng tương tự.
• Giờ đây trình nạp lớp phân giải các mục đa phiên bản ngay khi nạp, chọn phiên bản cao nhất mà JDK đang chạy hỗ trợ; trình đóng gói áp dụng cùng quy tắc phân giải khi dựng chỉ mục tài nguyên fat, nhờ đó chỉ mục và trình nạp luôn thống nhất về mục nào được dùng. Hai bố cục còn lại, fat và separate, chưa bao giờ bị ảnh hưởng vì chúng giữ các phụ thuộc dưới dạng tệp JAR thông thường do chính JVM mở.

6.0.17 2026-08-13

Sửa lỗi ứng dụng được bảo vệ không khởi động khi đường dẫn Windows chứa ký tự ngoài ASCII

• Đã sửa lỗi khiến ứng dụng được bảo vệ không khởi động được trên Windows khi đường dẫn của nó chứa ký tự ngoài ASCII, ví dụ chữ Hán. Tuỳ theo vị trí đường dẫn bị đọc sai, quá trình khởi động thất bại với lỗi kho lưu trữ E816, hoặc với lỗi giải mã biểu hiện dưới dạng ClassFormatError. Môi trường chạy mở kho lưu trữ và chuẩn hoá đường dẫn theo từng byte, nên một ký tự được mã hoá bằng bảng mã cũ mà byte thứ hai tình cờ là 0x5C — dấu gạch chéo ngược — bị cắt đôi ở giữa, và phần đuôi bị đọc thành dấu phân cách thư mục. Trong GBK, rất nhiều chữ Hán thông dụng được mã hoá đúng như vậy. Những đường dẫn chỉ gồm ký tự ASCII chưa bao giờ bị ảnh hưởng.
• Trên Windows, môi trường chạy giờ đây chuyển đường dẫn sang ký tự rộng thông qua bảng mã ANSI của hệ thống trước khi mở tệp và trước khi tính vân tay môi trường chạy, đúng như cách JDK gốc vẫn luôn mở tệp. Chỉ nhánh mã dành cho Windows thay đổi; Linux và macOS hoạt động y như trước. Cả năm dòng JDK đều đã được dựng lại kèm bản sửa lỗi này: JDK 25, 21 và 17 lên VLX 1.0.22, JDK 11 lên VLX 1.0.20 và JDK 8 lên VLX 1.0.13.

6.0.16 2026-08-10

Sửa lỗi đóng gói trên Windows cho đích Linux và macOS

• Đã sửa lỗi đóng gói trên Windows khi nền tảng đích là Linux hoặc macOS. Việc giải nén runtime kèm theo báo Failed to extract P4JX runtime mặc dù runtime thực tế đã được giải nén đúng. Windows không thể tạo liên kết tượng trưng khi không có quyền nâng cao, còn runtime cho Linux và macOS chứa hơn một trăm liên kết như vậy trong legal/ — đó là các văn bản giấy phép mà jlink trỏ về java.base thay vì nhân bản. Lệnh tar có sẵn trong Windows coi đó là cảnh báo nhưng vẫn trả về mã thoát khác không, và bộ mã hóa hiểu đó là thất bại hoàn toàn rồi xóa runtime vừa giải nén. Việc đóng gói trên Windows cho đích Windows chưa bao giờ bị ảnh hưởng, vì runtime cho Windows không chứa liên kết tượng trưng nào.
• Việc xử lý tệp nén không còn phụ thuộc vào lệnh tar của từng nền tảng. Bộ mã hóa giờ tự đọc và giải nén runtime .tar.gz cùng tài nguyên JavaFX, nhờ đó hành vi giống nhau hoàn toàn trên Windows, Linux và macOS. Quyền tệp, kể cả bit thực thi của trình khởi chạy, được lấy từ chính tệp nén thay vì từ hệ thống tệp của máy chủ. Trên Windows, các liên kết tượng trưng giấy phép được bỏ qua: chúng không có chức năng nào khi chạy và không thuộc dấu vân tay runtime, nên ứng dụng được bảo vệ trên Windows vẫn giải mã hoàn toàn như trước.

6.0.15 2026-08-08

Sửa lỗi hộp thoại cập nhật

• Hộp thoại "Phiên bản mới" giờ mở ở kích thước cố định hợp lý thay vì lấp đầy toàn bộ màn hình khi changelog dài.
• Đã thêm mục "Kiểm tra cập nhật" vào thanh công cụ, để bạn có thể kiểm tra phiên bản mới bất cứ lúc nào, không chỉ khi khởi động.

6.0.14 2026-08-07

Mã hóa nội tuyến hằng chuỗi, nay là mặc định

• Đã thêm chế độ bảo vệ chuỗi nội tuyến, viết lại các lệnh nạp chuỗi ldc thành lời gọi một phương thức giải mã tổng hợp riêng cho từng lớp, loại bỏ hoàn toàn văn bản thuần của hằng chuỗi khỏi nhóm hằng số. Văn bản thuần không còn vào SymbolTable khi nạp lớp, chỉ xuất hiện trên heap khi đoạn mã đó thực sự chạy, và các chuỗi không dùng đến vẫn được mã hóa. Bản mã nằm trong thân lớp và được bảo vệ bởi cơ chế mã hóa theo từng phương thức hiện có. Đây là phép biến đổi bytecode thuần túy ở phía bộ mã hóa: định dạng lưu trữ và runtime không đổi, và nó hoạt động trên mọi dòng JDK được hỗ trợ mà không cần cập nhật runtime.
• Bảo vệ chuỗi giờ là một tùy chọn duy nhất với ba chế độ — Không, Tiêu chuẩn (nhóm hằng số V72) và Nội tuyến — và Nội tuyến là mặc định cho mọi loại ứng dụng, bao gồm cả Tomcat. Nó đã được kiểm thử đầu-cuối trên các servlet thông thường, logic nghiệp vụ dùng switch trên chuỗi, và các lớp servlet JSP được JspC biên dịch trước. Cờ CLI là --encrypt-strings none|constant|inline, và GUI cung cấp cùng lựa chọn.
• Một phương thức không thể viết lại — giao diện ở định dạng tệp lớp cũ, phương thức gần giới hạn 64 KB, hoặc trường hợp biên hiếm gặp khi tuần tự hóa — sẽ quay về lớp V72 tiêu chuẩn, nên kết quả không bao giờ yếu hơn trước.

Khởi động Spring Boot p4jx-fat nhanh hơn

• Bộ nạp lớp Spring Boot ở bố cục pure-fat nay đọc chỉ mục tài nguyên lồng nhau theo nhu cầu thay vì đọc trước toàn bộ, giảm công việc khởi động cho các ứng dụng p4jx-fat lớn.

Thông tin đăng nhập tài khoản từ biến môi trường

• Các lệnh encode, javaapp, springboot và tomcat cùng chế độ tệp tác vụ nay có thể đọc email và mật khẩu tài khoản từ P4JX_ACCOUNT_EMAIL và P4JX_ACCOUNT_PASSWORD (hoặc P4JX_ACCOUNT_PASSWORD_MD5), chỉ dùng khi thiếu tùy chọn dòng lệnh tương ứng, để tệp tác vụ xuất ra không chứa thông tin đăng nhập.

6.0.13 2026-08-05

Sửa lỗi khởi động cho ứng dụng được bảo vệ dùng javax.lang.model

• Đã sửa lỗi NoClassDefFoundError: javax/lang/model/SourceVersion khi khởi động các ứng dụng được bảo vệ mà framework của chúng tham chiếu API javax.lang.model — điển hình là Spring Data JPA, với repository AOT processor truy cập SourceVersion trong lúc khởi tạo container. Module java.compiler trước đây đã bị loại khỏi runtime đóng gói, nay được đưa vào trở lại. Đây là module chỉ chứa API, không có phần triển khai trình biên dịch, nên ToolProvider.getSystemJavaCompiler() vẫn trả về null và jdk.compiler vẫn vắng mặt — bề mặt bảo vệ không thay đổi.
• Runtime cho JDK 17, 21 và 25 được dựng lại lên VLX 1.0.21, còn JDK 11 lên VLX 1.0.19, tất cả đều mang module java.compiler được khôi phục. JDK 8 không bị ảnh hưởng vì không có hệ thống module và vốn đã cung cấp các lớp này.

6.0.12 2026-08-02

Hỗ trợ JxBrowser 9 và sửa lỗi treo ở các ứng dụng được bảo vệ khi ném NullPointerException

• Ứng dụng được bảo vệ giờ có thể nhúng JxBrowser 9. --native-compat jxbrowser chọn một trong chín phiên bản của danh mục tích hợp, từ 9.0.0 đến 9.3.1, trên bảy nền tảng với Java 17, 21 và 25. Môi trường chạy chỉ cấp quyền gắn luồng cho thư viện IPC chính thức có SHA-256 đã đăng ký cho phiên bản được chọn, và kiểm tra lại mô-đun gọi ngay khi một luồng thực sự gắn vào. Đường dẫn, mã băm và tên thư viện không bao giờ được nhận từ dòng lệnh. Trên macOS 26, hãy dùng JxBrowser 9.0.1 trở lên: TeamDev đã sửa lỗi Chromium bị treo khi tạo Engine trong bản đó, và 9.0.0 cũng treo trên hệ điều hành này với JDK thông thường.
• Đã sửa lỗi ClassFormatError ở các ứng dụng được bảo vệ khi ném NullPointerException. Bản sửa ở 6.0.9 chặn thông báo NPE chi tiết của JVM theo từng phương thức, nhưng như vậy là chưa đủ: tính năng đó phân tích thân phương thức theo bytecode chuẩn, và sau khi P4JX đã biến đổi chúng thì không cờ hiệu nào ở mức phương thức có thể chứng minh việc phân tích vẫn hợp lệ. Môi trường chạy nay vô hiệu hóa thông báo chi tiết một cách vô điều kiện. Kiểu ngoại lệ, vết ngăn xếp và mọi thông báo do ứng dụng cung cấp đều không bị ảnh hưởng. Môi trường chạy cho JDK 17, 21 và 25 được dựng lại thành VLX 1.0.20; JDK 11 không bị ảnh hưởng và giữ VLX 1.0.18, JDK 8 giữ VLX 1.0.12.
• java -version nay hiển thị bản dựng của môi trường chạy VLX, nhờ đó có thể nhận biết môi trường đi kèm mà không cần giải nén.
• Hai trường phiên bản của tệp EXE Windows nay được kiểm tra trước khi bắt đầu đóng gói thay vì thất bại giữa chừng. Windows lưu mỗi thành phần dưới dạng số nguyên không dấu 16 bit, nên mỗi số trong nhóm từ một đến bốn số cách nhau bằng dấu chấm phải nằm trong khoảng 0 đến 65535. Để trống các trường này vẫn có nghĩa là 0.0.0.0.

6.0.11 2026-07-27

Trình khởi chạy Windows gốc cho ứng dụng được bảo vệ

• Bổ sung tùy chọn tạo EXE Windows gốc cho gói Java App, cả ba bố cục Spring Boot và gói Tomcat. Có trình khởi chạy dạng console và GUI cho Windows x64, x86 và ARM64, đồng thời các tập lệnh khởi chạy hiện có vẫn được giữ trong mọi gói.
• Bổ sung thiết lập trên CLI và giao diện đồ họa cho tên tệp EXE, chế độ, biểu tượng và siêu dữ liệu phiên bản Windows. Tác vụ đa nền tảng chỉ tạo EXE cho các đích Windows đã chọn, và thiết lập được lưu trong phiên bản 2 của p4j-task.yml; tệp tác vụ phiên bản 1 vẫn đọc được.
• Tích hợp trình khởi chạy JExeKit thuần Win32 với vlxjre đi kèm, classpath chính xác và các đối số JVM. Trước khi khởi động Java, trình khởi chạy từ chối đường dẫn thoát khỏi gói, việc thay thế qua điểm phân tích lại, cũng như tùy chọn agent hoặc boot classpath không an toàn.
• Mẫu JExeKit chỉ được nhúng dưới dạng tài nguyên .jxt mã hóa bằng AES-GCM và chỉ được giải mã trong bộ nhớ khi tạo. Mỗi trình khởi chạy được tạo đều có chữ ký Ed25519 trạng thái production cho khối tham số; mọi thay đổi về biểu tượng, phiên bản, manifest và tham số đều hoàn tất trước chữ ký Authenticode cuối cùng của người dùng.

6.0.10 2026-07-27

Tải phần phụ thuộc Tomcat nhanh hơn mà vẫn giữ nguyên cấu trúc WAR

• Đã khắc phục tình trạng Tomcat khởi động chậm nghiêm trọng do phải đọc lại và tính hash cho toàn bộ JAR lồng nhau được bảo vệ trong WEB-INF/lib mỗi khi tải một lớp. VLX 1.0.17 giờ đây chỉ xác minh mỗi JAR lồng nhau đã niêm phong một lần, lưu nguồn gốc đã xác thực của JAR đó trong bộ nhớ đệm của VM và tiếp tục đối chiếu từng lớp được yêu cầu với chỉ mục lớp đã mã hóa.
• Đã loại bỏ giải pháp tạm thời giải nén và gắn kết web-libs. Các tệp WEB-INF/lib/*.jar vẫn nằm trong kho lưu trữ .p4jx được bảo vệ, nhờ đó giữ nguyên cấu trúc WAR ban đầu và khả năng cách ly ứng dụng. Runtime VLX 1.0.17 cho JDK 11, 17, 21 và 25 đã được phát hành cho 24 tổ hợp nền tảng được hỗ trợ. JDK 8 tiếp tục dùng đường dẫn ZIP overlay hiện có và vẫn ở VLX 1.0.11.
• Đã sửa bước quét tương thích cho module-info.class của ứng dụng. Trình mô tả mô-đun không chứa thân phương thức nên giờ đây được tự động loại khỏi phạm vi mã hóa, đồng thời vẫn có thể được các công cụ đọc trình mô tả truy cập.
• Các lệnh CLI do giao diện đồ họa xuất ra giờ đây có thể đặt --java-version, --target-platform và --create-new-folder sau các đối số của trình đóng gói dưới dạng một hậu tố liền nhau. Dạng tiền tố hiện có vẫn được hỗ trợ.

6.0.9 2026-07-25

Sửa lỗi treo cho ứng dụng đã mã hóa khi hiển thị NullPointerException

• Đã sửa một lỗi treo JVM có thể xảy ra khi một phương thức được bảo vệ ném ra NullPointerException ngầm định và ứng dụng đọc thông báo của nó hoặc in dấu vết ngăn xếp. Tính năng "chi tiết NPE hữu ích" của runtime cố gắng dựng lại đoạn văn bản "because ... is null" từ bytecode đã mã hóa của phương thức, truy cập vào vùng nhớ không hợp lệ và làm treo VM (quan sát thấy ở các ứng dụng JavaFX FXML). Các phương thức được bảo vệ giờ đây bỏ qua thông báo chi tiết và quay về NullPointerException tiêu chuẩn; loại ngoại lệ, dấu vết ngăn xếp và bất kỳ thông báo nào do ứng dụng cung cấp đều không bị ảnh hưởng.
• Runtime cho JDK 17, 21 và 25 được dựng lại thành VLX 1.0.16 với bản sửa lỗi này. JDK 11 không bị ảnh hưởng vì tính năng NPE hữu ích không tồn tại trước JDK 14 và vẫn giữ VLX 1.0.15; JDK 8 vẫn giữ VLX 1.0.11.

6.0.8 2026-07-24

Runtime Tomcat tải theo nhu cầu và giá trị mặc định an toàn cho môi trường sản xuất

• Khắc phục lỗi khiến bộ mã hóa tự bảo vệ đã phát hành không thể đóng gói WAR Tomcat vì các lớp Tomcat bên trong app.p4jx không còn hiển thị như một JAR vật lý trên classpath. Tomcat 9.0.107 và 10.1.53 hiện là các artifact R2/COS bất biến, có phiên bản, được chọn theo namespace Servlet, tải xuống ở lần sử dụng đầu tiên, lưu trong bộ nhớ đệm cục bộ và xác minh bằng SHA-256 chính xác cùng danh sách JAR. Bộ nhớ đệm bị sửa đổi sẽ bị loại bỏ và tải lại.
• Các JAR công khai trong WEB-INF/lib hiện được triển khai thành tài nguyên Web vật lý, tách riêng theo từng ứng dụng và ràng buộc bằng hàm băm. Nhờ đó, Spring không phải đọc và xác minh lặp lại tệp lưu trữ lồng nhau cho từng lớp khi khởi động.
• Các bản dựng mới giờ mặc định dùng endpoint cấp phép sản xuất https://protector4j.com. Endpoint nội bộ http://10.10.10.16:16002 chỉ được dùng khi chọn rõ ràng P4JX_LICENSE_MODE=dev hoặc -PlicenseMode=dev.

6.0.7 2026-07-24

Phụ thuộc Tomcat lồng nhau và lớp động đáng tin cậy

• Khắc phục lỗi khi WAR Tomcat được bảo vệ tải lớp hoặc dịch vụ từ WEB-INF/lib/*.jar. Protector4J hiện niêm phong siêu dữ liệu SHA-256 chính xác của JAR và lớp lồng nhau vào app.p4jx; các phụ thuộc không xác định, bị thay thế hoặc bị sửa đổi vẫn bị từ chối.
• Khắc phục lỗi Spring CGLIB và Hibernate Byte Buddy trên JDK 11 do MethodHandles.Lookup#defineClass sử dụng dấu nguồn dành riêng cho JDK 11. Mức tin cậy động vẫn yêu cầu nguồn gốc lớp gọi hoặc loader đã được VM xác minh; chuỗi dấu, tên lớp, đường dẫn, gói và CodeSource không cấp quyền tin cậy.
• Phát hành runtime VLX 1.0.15 cho JDK 11, 17, 21 và 25 trên 24 tổ hợp nền tảng được hỗ trợ. Tất cả đều vượt qua các cổng L1-L5 nghiêm ngặt, bao gồm FXML thực, Swing/AWT, tải phụ thuộc Tomcat lồng nhau và các trường hợp âm về nguồn gốc cũng như sửa đổi. JDK 8 tiếp tục giữ VLX 1.0.11.

6.0.6 2026-07-22

Nguồn gốc đáng tin cậy khi định nghĩa lớp

• Khắc phục lỗi khởi động của ứng dụng JavaFX FXML được bảo vệ: MethodUtil định nghĩa helper Trampoline, có nguồn gốc đã được VM xác minh, thông qua defineClass(byte[]). Mức tin cậy giờ đây chỉ lan truyền từ nguồn gốc lớp hoặc loader đã được VM xác minh, không từ tên lớp, đường dẫn, gói hoặc chuỗi CodeSource.
• Bổ sung phạm vi kiểm thử FXML thật với fx:controller, phần tử thuộc tính, tiêm Controller và khởi động WebView, cùng các kiểm thử hồi quy cho định nghĩa động đáng tin cậy, lan truyền hai cấp, nguồn không xác định, JAR chưa được phép và thay thế tên protected class.
• Phát hành runtime VLX 1.0.14 cho JDK 11, 17, 21 và 25. JDK 8 tiếp tục giữ VLX 1.0.11.

6.0.5 2026-07-21

Tính toàn vẹn của môi trường chạy native JavaFX

• Khắc phục lỗi khởi động JavaFX WebView trên Windows (Graphics Device initialization failed / No toolkit found) bằng cách đặt các DLL JavaFX đã đóng gói vào vlxjre/bin và điều chỉnh đường tìm kiếm thư viện native của trình khởi động.
• Mở rộng danh sách cho phép đã mã hóa trong app.p4jx để bao gồm các thư viện native bên ngoài. Các tệp native JavaFX phải khớp chính xác với giá trị SHA-256 bất kể đường dẫn, và Glass sẽ kiểm tra lại tệp thực sự được tải; các tệp không được nhận diện hoặc bị sửa đổi sẽ bị từ chối.
• Phát hành các môi trường chạy Protector4J đã cập nhật cho JDK 11, 17, 21 và 25. Các tổ hợp nền tảng JavaFX được hỗ trợ đã vượt qua L5.1-L5.4, bao gồm khởi động WebView và từ chối các mô-đun JAR, jdk.jsobject và thư viện native Glass bị sửa đổi.

6.0.4 2026-07-21

Tính toàn vẹn của mô-đun bên ngoài và khả năng tương thích với môi trường chạy JavaFX

• Đã loại bỏ cơ chế tin cậy dựa trên đường dẫn đối với các mô-đun bên ngoài. Mọi JAR mô-đun bên ngoài giờ đây phải khớp chính xác với một mục SHA-256 trong danh sách cho phép được nhúng vào app.p4jx; các tệp không được nhận diện hoặc bị sửa đổi sẽ bị từ chối bất kể vị trí.
• Đã thêm chức năng tự động phát hiện bao đóng phụ thuộc từ JavaFX module-info.class và kiểm soát việc cho phép các mô-đun JavaFX và JDK đã được cố định, bao gồm javafx.media và jdk.jsobject.
• Đã khắc phục lỗi khởi động JavaFX WebView và lỗi E818 / ClassFormatError sau khi tạo lớp khởi động trên các phiên bản JDK và nền tảng được hỗ trợ bằng các môi trường chạy P4JX mới phát hành.

6.0.3 2026-07-20

Khả năng tương thích của mô-đun JavaFX WebView

• Đã sửa việc phân giải mô-đun tùy chọn jdk.jsobject cho các runtime P4JX được hỗ trợ và xây dựng lại từ cùng phiên bản JDK/VLX. Runtime tương thích không còn bị từ chối chỉ vì ảnh lib/modules hoàn chỉnh có các byte khác nhau.
• Vẫn duy trì việc chọn thành phẩm theo dòng JDK và nền tảng, xác thực chính xác SHA-256 và tên mô-đun, đồng thời kiểm tra lại đầy đủ chuỗi phụ thuộc sau khi cài đặt.

6.0.2 2026-07-20

Khả năng tương thích JavaFX WebView

• Khắc phục lỗi khởi động JavaFX WebView bằng cách đóng gói javafx.media cùng với javafx.web và tự động chọn mô-đun jdk.jsobject khớp chính xác với P4JX khi runtime rút gọn chưa chứa mô-đun đó.
• Bổ sung tải xuống mô-đun tùy chọn từ dịch vụ công khai theo khu vực, được cố định bằng SHA-256 và ràng buộc với phiên bản, nền tảng và runtime. Runtime đã chứa mô-đun sẽ bỏ qua bước tải xuống.

6.0.1 2026-07-20

Khả năng tương thích JavaFX

• Đã sửa lỗi khởi động của các fat JAR có nhúng lớp runtime JavaFX. Tính năng tự động áp dụng quy tắc tương thích hiện giữ nguyên trạng thái không mã hóa cho các không gian tên API, phần triển khai và cầu nối JNI của JavaFX được nhúng, qua đó tránh trùng quyền sở hữu lớp với các mô-đun JavaFX đi kèm.
• Cải thiện chẩn đoán tương thích và hướng dẫn đa ngôn ngữ cho các ứng dụng có runtime JavaFX được nhúng.

6.0.0 2026-07-20

Protector4J 6.0 là một bản phát hành lớn dựa trên kiến trúc bảo vệ được thiết kế lại hoàn toàn, không phải bản cập nhật gia tăng thông thường của dòng 5.x.

Kiến trúc và bảo vệ

• Thiết kế lại kiến trúc nền tảng của Protector4J và giới thiệu cơ chế bảo vệ P4JX mới.
• Bổ sung gần 100 biện pháp bảo vệ trên các lớp tạo tệp lưu trữ, tải lớp, thực thi runtime, chống gỡ lỗi và bảo đảm tính toàn vẹn của thành phẩm.
• Nâng cao đáng kể rào cản đối với kỹ thuật đảo ngược. Kiến trúc mới được thiết kế để khiến việc bẻ khóa trong thời gian ngắn trở nên cực kỳ khó khăn, ngay cả khi sử dụng các công cụ phân tích tiên tiến có AI hỗ trợ.
• Tăng cường bảo mật cho yêu cầu giấy phép, tải xuống runtime, xác minh thành phẩm và bộ cài đa nền tảng.

Trải nghiệm sản phẩm

• Hỗ trợ JDK 8, 11, 17, 21 và 25, cùng quy trình đóng gói trực quan cho các ứng dụng Java, JavaFX, Spring Boot và Tomcat.
• Bổ sung quét tương thích, mã hóa lớp có chọn lọc, bảo vệ JAR phụ thuộc, nhập/xuất tác vụ YAML và xây dựng hàng loạt cho nhiều nền tảng đích.
• Thiết kế lại giao diện máy tính, hỗ trợ 11 ngôn ngữ và lưu tùy chọn ngôn ngữ lâu dài.

Lưu ý khi chuyển đổi

Cách sử dụng Protector4J 6.0 khác biệt đáng kể so với các phiên bản trước. Vui lòng đọc lại tài liệu mới nhất trước khi sử dụng, đồng thời sớm xây dựng lại và chuyển các ứng dụng đã mã hóa sang phiên bản 6.0 để tận dụng khả năng bảo vệ mạnh hơn.

Tải Protector4J 6.0

Các phiên bản trước