Nhật ký thay đổi

6.0.22 2026-08-26

Đóng gói ứng dụng Tomcat có JSP hiện đã hoạt động

• Đã sửa lỗi đóng gói thất bại với ClassFormatError: Incompatible class format khi tệp WAR của Tomcat chứa trang JSP. Protector4J biên dịch trước JSP thành servlet ở bước đóng gói; việc này cần một trình biên dịch Java và cũng cần nạp các lớp xử lý thẻ của chính ứng dụng. Trước đây cả hai việc đều diễn ra bên trong tiến trình của Protector4J — nơi môi trường chạy đi kèm (chỉ có JRE) không có trình biên dịch, và quy tắc kiểm soát nạp lớp của cơ chế bảo vệ cũng không cho phép nạp lớp của ứng dụng. Hiện cả hai bước đều chạy trong một JDK tiêu chuẩn mà Protector4J tải về khi cần và lưu vào bộ nhớ đệm cục bộ, nên đóng gói ứng dụng JSP không còn đòi hỏi máy phải cài sẵn JDK. Lần đóng gói đầu tiên sẽ tải bộ công cụ một lần (khoảng 200 MB); các lần sau dùng lại bản đã lưu.

Chỉnh sửa cấu hình bảo mật của môi trường chạy đi kèm không còn làm hỏng ứng dụng được bảo vệ

• Đã sửa: một ứng dụng được bảo vệ không khởi động được sau khi tệp conf/security/java.security của môi trường chạy đi kèm bị chỉnh sửa — ví dụ để đăng ký một provider bảo mật (PKCS#11/HSM hoặc BouncyCastle), tắt các thuật toán TLS yếu, bật chế độ FIPS, hoặc đổi securerandom.source. Môi trường chạy trước đây ràng buộc việc giải mã vào đúng nội dung của tệp này, nên mọi chỉnh sửa đều khiến tệp lưu trữ được bảo vệ không mở được và báo một lỗi khởi động khó hiểu. Tệp này là một cấu hình mà JDK thiết kế để cho người vận hành chỉnh sửa, và thay đổi nó chưa bao giờ giúp ai vượt qua lớp bảo vệ, nên ràng buộc nó không tăng an toàn mà chỉ tạo ra một cái bẫy.
• Danh tính môi trường chạy giờ chỉ ràng buộc vào các tệp nhị phân bảo vệ — trình khởi chạy và các thư viện native cốt lõi —, đó mới là thứ thực sự ngăn một ứng dụng được bảo vệ chạy trên một JVM đã bị can thiệp; tệp chính sách bảo mật và một dấu năng lực nội bộ không còn thuộc về nó nữa. Chỉnh sửa chính sách bảo mật của môi trường chạy theo cách thông thường giờ đã hoạt động. Vì danh tính môi trường chạy đã thay đổi, một ứng dụng được bảo vệ hiện có phải được mã hóa lại bằng bản phát hành này.

Tài nguyên lớn bên trong JAR phụ thuộc không còn làm mã hóa thất bại

• Đã sửa: việc mã hóa thất bại khi một JAR phụ thuộc trong gói Tomcat được bảo vệ chứa một tài nguyên lớn hơn 16 MB — thường gặp nhất là icu4j, với tệp dữ liệu icudt*.dat khoảng 25–30 MB và được nhiều thư viện doanh nghiệp kéo theo gián tiếp. Trình đóng gói đọc mọi mục của mỗi JAR lồng nhau vào bộ nhớ dưới giới hạn 16 MB, dù chỉ các tệp lớp mới tham gia kiểm tra cho phép, nên một tệp dữ liệu lớn duy nhất làm hỏng toàn bộ quá trình dựng. Trình đóng gói giờ chỉ đọc các tệp lớp và manifest và để nguyên các tài nguyên khác, nhờ đó các ứng dụng này mã hóa bình thường và dùng ít bộ nhớ hơn khi làm việc đó.

Ứng dụng desktop đóng gói thành fat JAR shade với JxBrowser giờ đã mã hóa được

• Đã sửa: --native-compat jxbrowser thất bại với "no artifacts detected" khi một ứng dụng desktop JavaFX/JxBrowser được đóng gói thành một fat JAR shade hoặc assembly duy nhất. Trình quét trước đây chỉ nhận diện JxBrowser qua tên tệp các JAR phụ thuộc độc lập của nó, mà bản dựng shade hoặc assembly làm phẳng và xóa mất. Giờ nó còn nhận diện môi trường chạy qua hash nội dung của kho lưu trữ Chromium nhúng — thứ mà bản dựng shade sao chép nguyên từng byte — nên vẫn cùng các thư viện native đáng tin được cấp phép, và dữ liệu cho phép ghi trên đĩa giống hệt từng byte với đường dẫn JAR độc lập.

Ứng dụng có hơn khoảng 1300 lớp được bảo vệ giờ đã mã hóa được

• Đã sửa: việc mã hóa thất bại với lỗi khó hiểu "UTF8 string too large" khi một ứng dụng có hơn khoảng 1300 lớp được bảo vệ. Danh sách chính xác các tên lớp được bảo vệ trước đây bị nướng vào trình khởi chạy được sinh ra dưới dạng một hằng chuỗi tệp lớp duy nhất, vốn giới hạn ở 65535 byte. Danh sách giờ được đóng gói như một tài nguyên bên trong gói và đọc lại lúc chạy, nên số lớp được bảo vệ không còn bị chặn bởi giới hạn đó nữa; trình đóng gói cũng báo một lỗi rõ ràng, có thể xử lý nếu bất kỳ giá trị sinh ra nào tiến gần tới ngưỡng.

6.0.21 2026-08-25

Ứng dụng Tomcat lớn và ứng dụng có nhiều phụ thuộc không mã hóa hoặc không khởi động được

• Đã nâng dung lượng của danh sách cho phép classpath. Một gói Tomcat được bảo vệ ghi lại một mục cho phép cho mỗi lớp trong mỗi JAR ở WEB-INF/lib, và toàn bộ metadata này bị giới hạn ở 4 MB — khoảng 21.000 lớp. Ứng dụng web lớn hơn chạm giới hạn này và dừng lại với nested classpath metadata is too large. Giới hạn giờ là 64 MB, và các giới hạn tương ứng theo từng JAR và từng lớp cũng được nâng theo cùng tỷ lệ, nên một ứng dụng doanh nghiệp điển hình với hàng chục nghìn lớp vẫn mã hóa bình thường.
• Trình mã hóa giờ đây từ chối một gói vượt dung lượng ngay khi mã hóa, kèm thông báo cho biết đã vượt bao nhiêu, thay vì tạo ra một tệp lưu trữ chỉ hỏng về sau khi khởi động. Số lượng JAR classpath thông thường và số lượng tệp lưu trữ được bảo vệ trước đây chỉ được môi trường chạy kiểm tra, nên một gói Spring Boot bố cục separate với nhiều phụ thuộc, hoặc một nền Tomcat chứa nhiều ứng dụng web, có thể mã hóa trót lọt rồi lại không khởi động được.
• Đã làm lại cách môi trường chạy nạp một danh sách cho phép lớn để việc khởi động vẫn nhanh. Logic trước đây tăng theo bình phương số lớp và có thể khiến việc khởi động một ứng dụng web lớn treo trong nhiều phút. Cả năm dòng JDK đều được dựng lại với bản sửa: JDK 25, 21 và 17 lên VLX 1.0.24, JDK 11 lên VLX 1.0.22, và JDK 8 lên VLX 1.0.15.
• Bản sửa bao gồm cả trình mã hóa lẫn môi trường chạy đi kèm, nên một ứng dụng được bảo vệ hiện có phải được mã hóa lại bằng bản phát hành này mới nhận được.

Ứng dụng Spring Boot có toàn bộ mã nghiệp vụ nằm trong JAR phụ thuộc không phản hồi sau khi mã hóa

• Đã sửa: ở bố cục mặc định p4jx-fat, một ứng dụng Spring Boot đã mã hóa không cung cấp endpoint nào khi các lớp nghiệp vụ — controller, cấu hình, bảo mật — nằm trong các JAR phụ thuộc ở BOOT-INF/lib thay vì trong BOOT-INF/classes. Ứng dụng vẫn khởi động, máy chủ vẫn lắng nghe, log không có lỗi nào, nhưng mọi yêu cầu đều trả về 404 và Spring Security lùi về cấu hình mặc định, vì quét component của Spring không thấy bất kỳ lớp nào trong các JAR phụ thuộc: bộ nạp lớp được sinh ra chỉ đăng ký thư mục gói cho các mục ở BOOT-INF/classes. Điều này không liên quan đến mã hóa; cùng một bố cục đều hỏng dù các lớp có được bảo vệ hay không.
• Bộ nạp p4jx-fat giờ đây đăng ký một thư mục gói cho mỗi JAR ở BOOT-INF/lib và phơi bày cho framework qua một URL JAR lồng nhau cùng dạng mà chính Spring Boot dùng, nhờ đó quét component tìm thấy controller và cấu hình bên trong các JAR phụ thuộc. Với --protect-lib, stub metadata giờ nằm lại trong JAR phụ thuộc đã dựng lại thay vì được chiếu vào BOOT-INF/classes.

6.0.20 2026-08-22

Ứng dụng được bảo vệ gặp sự cố ngẫu nhiên trên mọi dòng JDK được hỗ trợ

• Đã sửa một lỗi trong môi trường chạy đi kèm khiến ứng dụng được bảo vệ có thể dừng đột ngột một cách ngẫu nhiên, từ vài phút đến một ngày sau khi khởi động. Khi trình biên dịch JIT loại bỏ mã đã tối ưu và dựng lại khung thông dịch, môi trường chạy đọc toán hạng của lệnh gọi phương thức trực tiếp từ bộ nhớ mà không giải mã, rồi dùng giá trị vô nghĩa đó làm chỉ mục vào bộ đệm nhóm hằng số. Triệu chứng được báo cáo là lỗi nghiêm trọng của JVM có nhắc đến parameter_size; cùng lỗi đó cũng có thể âm thầm phá hỏng vùng nhớ không liên quan. Những ứng dụng có đường dẫn mã nóng được tối ưu nhiều là dễ gặp nhất.
• Rà soát cùng loại lỗi trên cả năm dòng JDK phát hiện thêm năm chỗ đọc hoặc ghi siêu dữ liệu được bảo vệ mà chưa giải mã trước. Hai trong số đó khiến một phép kiểm tra nhất quán nội bộ dừng JVM ngẫu nhiên, và một chỗ là tranh chấp lúc liên kết lớp, có thể trả về con trỏ nhóm hằng số không hợp lệ khi lớp còn đang được chuẩn bị. Tất cả đã được sửa trong các môi trường chạy phát hành lần này.
• Bản sửa nằm ở môi trường chạy đi kèm chứ không phải ở bộ mã hóa, nên ứng dụng được bảo vệ hiện có phải được mã hóa lại bằng bản phát hành này mới nhận được.

Ứng dụng Spring Boot 4 không khởi động được trên JDK 25 với bố cục p4jx-fat

• Đã sửa việc bố cục p4jx-fat phân giải các phụ thuộc đa phiên bản theo sai phiên bản Java. Trình đóng gói dùng dòng môi trường chạy được chọn trên dòng lệnh — vốn quay về 21 khi chỉ truyền --jre-home — thay vì phiên bản của môi trường chạy thực sự được đóng gói. Do đó khi đóng gói cho môi trường JDK 25, mọi mục từ META-INF/versions/22 trở lên đều bị loại bỏ. Với Spring Framework 7, điều này làm mất ClassFileMetadataReaderFactory vốn chỉ có trong biến thể JDK 24, khiến mọi ứng dụng Spring Boot 4 khởi động thất bại với NoClassDefFoundError. Hai bố cục fat và separate chưa bao giờ bị ảnh hưởng vì chúng giữ phụ thuộc dưới dạng tệp JAR thông thường để chính JVM mở.

Lệnh encode hoạt động trở lại trên dòng lệnh

• Bản 6.0.19 đánh dấu tính năng mã hóa thư viện độc lập là đang phát triển trong giao diện đồ họa và vô tình chặn luôn lệnh encode trên dòng lệnh. Chặn này đã được gỡ bỏ và encode hoạt động như trước. Giao diện đồ họa vẫn giữ nhãn "Đang phát triển", nên phía đó không thay đổi.

Windows ARM64 không còn là nền tảng đích

• Hỗ trợ windows-aarch64 đã bị rút lại: nền tảng này không còn xuất hiện trong giao diện đồ họa, --target-platform windows-aarch64 bị từ chối, không sinh trình khởi chạy EXE cho nó và không phát hành môi trường chạy đi kèm. Windows trên ARM chạy gói windows-x64 thông qua cơ chế giả lập tích hợp sẵn của hệ điều hành. Các đích được hỗ trợ hiện nay là macOS trên Apple silicon và Intel, Linux trên ARM64 và x64, Windows trên x64 và x86.

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