Changelog

6.0.18 2026-08-13

Multi-release JAR support in the Spring Boot p4jx-fat layout

• Fixed multi-release dependencies being loaded from their base version in the Spring Boot p4jx-fat layout. When unpacking a nested BOOT-INF/lib JAR, the class loader stored entries under their literal names, so classes under META-INF/versions/ were never selected and the base-version fallback was always used. A concrete symptom: with Spring Framework 7.0.5, VirtualThreadDelegate resolved to its base-version stub, which throws UnsupportedOperationException unconditionally, so an application running on JDK 25 with spring.threads.virtual.enabled=true failed to start. Many widely used dependencies ship as multi-release JARs, so other version-specific code paths were affected in the same way.
• The class loader now resolves multi-release entries at load time, picking the highest version that the running JDK supports, and the packager applies the same resolution when it builds the fat resource index, so the index and the loader always agree on which entry wins. The other two layouts, fat and separate, were never affected because they keep dependencies as ordinary JAR files that the JVM opens itself.

6.0.17 2026-08-13

Startup fix for protected applications on Windows paths with non-ASCII characters

• Fixed protected applications failing to start on Windows when their path contains non-ASCII characters, such as Chinese. Depending on where the path was misread, the launch failed either with archive error E816 or with a decryption failure surfacing as ClassFormatError. The runtime opened the archive and normalised paths byte by byte, so a character encoded in a legacy code page whose second byte happens to be 0x5C — the backslash — was split down the middle, and its tail was read as a directory separator. Many everyday Chinese characters encode that way in GBK. Paths made up only of ASCII characters were never affected.
• On Windows the runtime now converts paths to wide characters through the system ANSI code page before opening files and before computing the runtime fingerprint, which is how the stock JDK has always opened files. Only the Windows code path changed; Linux and macOS behave exactly as before. All five JDK lines were rebuilt with the fix: JDK 25, 21 and 17 to VLX 1.0.22, JDK 11 to VLX 1.0.20, and JDK 8 to VLX 1.0.13.

6.0.16 2026-08-10

Windows packaging fix for Linux and macOS targets

• Fixed a packaging failure on Windows when the target platform is Linux or macOS. Extracting the bundled runtime reported Failed to extract P4JX runtime even though the runtime had in fact been extracted correctly. Windows cannot create symbolic links without elevated privileges, and the Linux and macOS runtimes contain slightly over a hundred of them under legal/ — license texts that jlink points at java.base instead of duplicating. The tar command shipped with Windows treats those as warnings and still returns a non-zero exit code, which the encoder read as a hard failure and then deleted the extracted runtime. Packaging on Windows for a Windows target was never affected, because the Windows runtimes contain no symbolic links at all.
• Archive handling no longer depends on the platform's tar command. The encoder now reads and extracts .tar.gz runtimes and JavaFX assets itself, so the behaviour is identical on Windows, Linux, and macOS. File permissions, including the launcher's executable bit, come from the archive itself rather than from the host file system. On Windows the license symlinks are skipped: they carry no runtime function and are not part of the runtime fingerprint, so applications protected on Windows decrypt exactly as they did before.

6.0.15 2026-08-08

Update dialog fixes

• The "New Version" dialog now opens at a fixed, reasonable size instead of stretching to fill the entire screen when the changelog is long.
• Added a "Check for Updates" entry to the toolbar, so you can check for a newer release at any time, not only at startup.

6.0.14 2026-08-07

Inline string-constant encryption, now the default

• Added an inline string-protection mode that rewrites ldc string loads into a call to a synthetic per-class decrypt method, removing a string constant's plaintext from the constant pool entirely. The plaintext no longer enters the SymbolTable at class load, appears on the heap only when that code actually runs, and unused strings stay encrypted. The ciphertext travels inside the class body and is covered by the existing per-method encryption, so this is a pure encoder-side bytecode transform: the archive format and the runtime are unchanged, and it works on every supported JDK line with no runtime update.
• String protection is now a single option with three modes — None, Standard (constant-pool V72), and Inline — and Inline is the default for every application type, including Tomcat. It was validated end to end on ordinary servlets, string-switch business logic, and JspC-precompiled JSP servlet classes. The CLI flag is --encrypt-strings none|constant|inline, and the GUI offers the same choice.
• A method that cannot be rewritten — an interface in an old class-file format, a method near the 64 KB code limit, or a rare serialization edge case — falls back to the standard V72 layer, so the result is never weaker than before.

Faster Spring Boot p4jx-fat startup

• The pure-fat Spring Boot class loader now reads its nested-resource index on demand instead of eagerly, cutting startup work for large p4jx-fat applications.

Account credentials from environment variables

• The encode, javaapp, springboot, and tomcat commands and task-file mode can now read the account email and password from P4JX_ACCOUNT_EMAIL and P4JX_ACCOUNT_PASSWORD (or P4JX_ACCOUNT_PASSWORD_MD5), used only when the matching command-line option is absent, so an exported task file stays free of credentials.

6.0.13 2026-08-05

Startup fix for protected applications that use javax.lang.model

• Fixed NoClassDefFoundError: javax/lang/model/SourceVersion at startup in protected applications whose frameworks reference the javax.lang.model API — most notably Spring Data JPA, whose repository AOT processor touches SourceVersion while the container initializes. The java.compiler module, previously removed from the bundled runtime, is now included again. It is an API-only module with no compiler implementation, so ToolProvider.getSystemJavaCompiler() still returns null and jdk.compiler stays absent — the protection surface is unchanged.
• JDK 17, 21, and 25 runtimes are rebuilt to VLX 1.0.21, and JDK 11 to VLX 1.0.19, all carrying the restored java.compiler module. JDK 8 is unaffected because it has no module system and already provides these classes.

6.0.12 2026-08-02

JxBrowser 9 support, and a crash fix for protected applications that throw NullPointerException

• Protected applications can now embed JxBrowser 9. --native-compat jxbrowser selects one of the nine built-in catalog versions, 9.0.0 through 9.3.1, across seven platforms on Java 17, 21, and 25. The runtime grants thread-attach permission only to the official IPC library whose SHA-256 is registered for the selected version, and re-checks the calling module when a thread actually attaches. Paths, hashes, and library names are never accepted from the command line. On macOS 26, use JxBrowser 9.0.1 or later: TeamDev fixed a Chromium crash during Engine creation in that release, and 9.0.0 crashes there on a plain JDK as well.
• Fixed ClassFormatError in protected applications that throw a NullPointerException. The 6.0.9 fix suppressed the JVM's helpful-NPE message per method, which turned out to be insufficient: that feature parses method bodies as standard bytecode, and no per-method flag can prove the parse is valid once P4JX has transformed them. The runtime now disables the extended message unconditionally. The exception type, stack trace, and any application-supplied message are unaffected. JDK 17, 21, and 25 runtimes are rebuilt to VLX 1.0.20; JDK 11 is unaffected and stays on VLX 1.0.18, and JDK 8 stays on VLX 1.0.12.
• java -version now reports the VLX runtime build, so a packaged runtime can be identified without unpacking it.
• The two Windows EXE version fields are now validated before packaging starts, instead of failing partway through. Windows stores each component as an unsigned 16-bit integer, so each of the one to four dot-separated numbers must be between 0 and 65535. Leaving the fields empty still means 0.0.0.0.

6.0.11 2026-07-27

Native Windows launchers for protected applications

• Added optional native Windows EXE generation to Java App packages, all three Spring Boot layouts, and Tomcat packages. Console and GUI launchers are available for Windows x64, x86, and ARM64, while the existing launch scripts remain in every package.
• Added CLI and GUI settings for the EXE filename, mode, icon, and Windows version metadata. Multi-platform tasks generate an EXE only for selected Windows targets, and the settings are preserved in version 2 of p4j-task.yml; version 1 task files remain readable.
• Integrated the pure Win32 JExeKit launcher with the packaged vlxjre, exact classpath and JVM arguments. Launchers reject paths that escape the package, reparse-point substitutions, and unsafe agent or boot-classpath options before starting Java.
• JExeKit templates are embedded only as AES-GCM-encrypted .jxt resources and decrypted in memory for generation. Every generated launcher carries a production-status Ed25519 signature over its parameter block; icon, version, manifest, and parameter changes finish before the user's final Authenticode signature.

6.0.10 2026-07-27

Faster, structure-preserving Tomcat dependency loading

• Fixed severe Tomcat startup slowdowns caused by re-reading and hashing an entire protected WEB-INF/lib nested JAR whenever a class was loaded. VLX 1.0.17 now verifies each sealed nested JAR once, caches its authenticated provenance inside the VM, and continues to validate every requested class against the encrypted class index.
• Removed the temporary web-libs extraction and mounting workaround. WEB-INF/lib/*.jar remains inside the protected .p4jx archive, preserving the original WAR structure and application isolation. VLX 1.0.17 runtimes are published for JDK 11, 17, 21, and 25 across 24 supported platform combinations; JDK 8 keeps its existing ZIP overlay path and remains on VLX 1.0.11.
• Fixed compatibility scanning for application module-info.class. Module descriptors are now automatically excluded from encryption because they contain no method bodies, while remaining readable by descriptor tools.
• CLI commands exported by the GUI can now place --java-version, --target-platform, and --create-new-folder after the packager arguments as a contiguous suffix. The existing prefix form remains supported.

6.0.9 2026-07-25

Crash fix for encrypted apps that surface null-pointer exceptions

• Fixed a JVM crash that could occur when a protected method threw an implicit NullPointerException and the application read its message or printed its stack trace. The runtime's helpful-NPE detail feature tried to rebuild the "because ... is null" text from the method's encrypted bytecode and dereferenced invalid memory, crashing the VM (observed with JavaFX FXML applications). Protected methods now skip the detail message and fall back to a standard NullPointerException; the exception type, stack trace, and any application-supplied message are unaffected.
• JDK 17, 21, and 25 runtimes are rebuilt to VLX 1.0.16 with this fix. JDK 11 is unaffected because the helpful-NPE feature does not exist before JDK 14 and stays on VLX 1.0.15; JDK 8 stays on VLX 1.0.11.

6.0.8 2026-07-24

Downloadable Tomcat runtimes and production-safe defaults

• Fixed the released self-protected encoder failing to package Tomcat WARs because Tomcat classes inside app.p4jx were no longer visible as a physical classpath JAR. Tomcat 9.0.107 and 10.1.53 are now immutable, versioned R2/COS artifacts selected by servlet namespace, downloaded on first use, cached locally, and verified against an exact SHA-256 and JAR manifest. Tampered caches are discarded and downloaded again.
• Public WEB-INF/lib JARs are now staged as per-application, hash-bound physical web resources, avoiding repeated nested-archive reads and verification for each class during Spring startup.
• New builds now default to the production license endpoint at https://protector4j.com. The internal http://10.10.10.16:16002 endpoint is used only when P4JX_LICENSE_MODE=dev or -PlicenseMode=dev is explicitly selected.

6.0.7 2026-07-24

Nested Tomcat dependencies and trusted dynamic classes

• Fixed protected Tomcat WARs that load classes or services from WEB-INF/lib/*.jar. Protector4J now seals exact nested JAR and class SHA-256 metadata into app.p4jx; unknown, replaced, or tampered dependencies remain rejected.
• Fixed JDK 11 Spring CGLIB and Hibernate Byte Buddy failures caused by MethodHandles.Lookup#defineClass using a JDK 11-specific source marker. Dynamic trust still requires VM-verified caller or loader provenance; marker strings, class names, paths, packages, and CodeSource do not grant trust.
• Published VLX 1.0.15 runtimes for JDK 11, 17, 21, and 25 across 24 supported platform grids. All passed strict L1-L5 gates, including real FXML, Swing/AWT, Tomcat nested-dependency loading, and negative provenance and tamper cases. JDK 8 remains on VLX 1.0.11.

6.0.6 2026-07-22

Trusted class-definition provenance

• Fixed protected JavaFX FXML startup failures caused by MethodUtil defining its verified Trampoline helper through defineClass(byte[]). Trust now propagates only from VM-verified class or loader provenance, not from class names, paths, packages, or CodeSource strings.
• Added real FXML coverage with fx:controller, property elements, controller injection, and WebView startup, plus regressions for trusted dynamic definitions, two-level propagation, unknown sources, unauthorized JARs, and protected-name replacement.
• Published VLX 1.0.14 runtimes for JDK 11, 17, 21, and 25. JDK 8 remains on VLX 1.0.11.

6.0.5 2026-07-21

JavaFX native runtime integrity

• Fixed Windows JavaFX WebView startup failures (Graphics Device initialization failed / No toolkit found) by placing packaged JavaFX DLLs in vlxjre/bin and aligning the launcher's native library search.
• Extended the encrypted app.p4jx allowlist to external native libraries. JavaFX native files must match exact SHA-256 values regardless of path, and Glass revalidates the actual loaded file; unrecognized or tampered files are rejected.
• Published refreshed Protector4J runtimes for JDK 11, 17, 21, and 25. Supported JavaFX grids passed L5.1-L5.4, covering WebView startup plus tamper rejection for module JARs, jdk.jsobject, and Glass native libraries.

6.0.4 2026-07-21

External module integrity and JavaFX runtime compatibility

• Removed path-based trust for external modules. Every external module JAR must now match an exact SHA-256 allowlist entry embedded in app.p4jx; unrecognized or tampered files are rejected regardless of location.
• Added automatic dependency-closure detection from JavaFX module-info.class and controlled admission of pinned JavaFX and JDK modules, including javafx.media and jdk.jsobject.
• Fixed JavaFX WebView startup and post-boot-layer E818 / ClassFormatError failures across supported JDK trains and platforms with newly released P4JX runtimes.

6.0.3 2026-07-20

JavaFX WebView module compatibility

• Fixed optional jdk.jsobject resolution for supported P4JX runtimes rebuilt from the same JDK/VLX version. Packaging no longer rejects a compatible runtime solely because its complete lib/modules image has different bytes.
• Retained train/platform-specific artifact selection, exact module SHA-256 and module-name validation, and dependency-closure verification after installation.

6.0.2 2026-07-20

JavaFX WebView compatibility

• Fixed JavaFX WebView startup failures by packaging javafx.media together with javafx.web and automatically resolving the exact P4JX-matched jdk.jsobject module when a pruned runtime does not include it.
• Added SHA-256-pinned, version/platform/runtime-bound optional module downloads from the regional public download service. Runtimes that already include the module skip the download.

6.0.1 2026-07-20

JavaFX compatibility

• Fixed startup failures for fat JARs that embed JavaFX runtime classes. Compatibility Apply now keeps embedded JavaFX API, implementation, and JNI bridge namespaces unencrypted, avoiding duplicate ownership with packaged JavaFX modules.
• Improved compatibility diagnostics and multilingual guidance for applications with shaded JavaFX runtimes.

6.0.0 2026-07-20

Protector4J 6.0 is a major release built on a redesigned protection architecture, rather than an incremental update to the 5.x series.

Architecture and protection

• Redesigned the foundational architecture of Protector4J and introduced the new P4JX protection engine.
• Added nearly 100 protection measures across archive generation, class loading, runtime execution, anti-debugging, and artifact integrity.
• Significantly raised the barrier to reverse engineering. The new architecture is designed to make short-term cracking extremely difficult, even with advanced AI-assisted analysis tools.
• Strengthened license requests, runtime downloads, artifact verification, and cross-platform installer security.

Product experience

• Added support for JDK 8, 11, 17, 21, and 25, with graphical packaging workflows for Java, JavaFX, Spring Boot, and Tomcat applications.
• Added compatibility scanning, selective class encryption, dependency JAR protection, YAML task import/export, and batch builds for multiple target platforms.
• Redesigned the desktop interface with support for 11 languages and persistent language preferences.

Migration notes

Protector4J 6.0 differs substantially from earlier versions. Please read the latest documentation before using it, and rebuild and migrate your encrypted applications to 6.0 as soon as practical to benefit from the stronger protection.

Download Protector4J 6.0

Earlier releases