Upgrading from Protector4J v5 to v6

⚠️ For the security of your code, please upgrade to v6 as soon as possible

AI-assisted reverse engineering is rapidly lowering the barrier to code analysis. The protection strength of v5 is no longer sufficient for the current threat landscape, and staying on it leaves your code at a higher risk of disclosure. We strongly recommend migrating your protected applications to Protector4J v6 as soon as you can.

1. Why upgrade to v6

AI tools are making code analysis and reverse engineering easier. Traditional bytecode obfuscation and simple encryption are no longer sufficient for the latest security challenges.

To provide stronger protection for Java code, we redesigned Protector4J v6. Its new P4JX architecture introduces more than one hundred security measures across code encryption, class loading, runtime validation, anti-debugging, and other layers. Even with advanced AI analysis tools, reverse engineering protected code remains extremely difficult.

As a result, v6 differs significantly from v5 in its protection architecture, configuration, command-line syntax, and output format.

2. Main differences between v5 and v6

The most important change is that v5 encrypted files, runtimes, and YAML task files cannot be reused directly by v6.

3. Use compatibility mode for a simple setup

Stronger protection requires more options for the protection scope, runtime, layout, compatibility, and target platforms. To keep users from having to understand every option before getting started, v6 provides a compatibility mode.

In the GUI, use Simple (recommended) mode:

1. Select the application type.
2. Select the original JAR or WAR.
3. Select the Java version and target platforms.
4. Let Protector4J scan the application and choose conservative compatibility settings.
5. Confirm the output directory and start protection.

Switch to Advanced mode only when you need precise control over the protection scope, Spring Boot layout, JVM options, JavaFX, or other settings.

On the command line, use --compat-apply. It scans the application, applies conservative compatibility recommendations, and then generates the protected package:

p4j javaapp app.jar dist --compat-apply

Compatibility mode simplifies configuration, but it does not replace real testing. After packaging, verify startup, core features, reflection, serialization, database access, and third-party framework behavior.

4. The command-line syntax has changed completely

The v5 CLI depends on a YAML task file:

p4j -t java -f java-task.yml

v6 can run without a configuration file and accepts all settings as command-line arguments:

# Regular Java application
p4j javaapp app.jar dist --compat-apply

# Spring Boot application
p4j springboot app.jar dist --compat-apply

# Tomcat WAR
p4j tomcat app.war dist --compat-apply --context /app

# Java library
p4j encode library.jar library.p4jx

Application type mapping:

Note that v6 encode protects every class in the library and requires a VLX JRE to load it. It is not a drop-in replacement for the v5 workflow that converted selected methods to native code while continuing to use a standard JRE.

v6 still supports task files, but they must be newly exported from the v6 GUI as p4j-task.yml:

p4j --task-file p4j-task.yml

Do not try to edit and reuse a v5 YAML file. The v5 and v6 task formats are incompatible. Reconfigure the task in the GUI or rewrite the command using the latest CLI documentation.

For all commands and options, see the v6 CLI Reference.

5. Migrate from v5 to v6

Follow this single migration path:

Keep a v5 backup → find the original JAR/WAR → regenerate in v6 compatibility mode → test → switch

Step 1: Keep the v5 environment

Keep the working v5 output directory and startup procedure so that you can roll back if necessary. Do not overwrite the v5 directory.

Step 2: Prepare the original input

Find the original JAR, Spring Boot JAR, or WAR that has not been encrypted by v5. The vlxlib, encrypted JARs, and vlxjre generated by v5 cannot be used as v6 input.

Step 3: Regenerate with v6

For interactive use, start with Simple mode in the GUI. For automation, use direct command-line arguments together with --compat-apply. Write the output to a new directory and do not mix it with v5 files.

Step 4: Validate the v6 output

Start the application with the generated run.sh, run.command, or run.bat. Deploy the generated vlxjre with the application. Do not replace it with a system JRE or a runtime from another task.

At minimum, verify that:

• the application starts and stops normally;
• core business features work correctly;
• reflection, serialization, ORM, Spring proxies, and resource loading work correctly;
• the package has been run on every target operating system.

Step 5: Switch the complete package

After validation, switch to the complete v6 output directory. For later updates, regenerate a full package from the original JAR or WAR instead of using the v5 KeySeed + onlyEncryptJarFiles partial-update workflow.

6. Upgrade recommendation

AI-assisted reverse engineering is rapidly lowering the barrier to code analysis, so continuing to use v5 increases the risk of code disclosure. For security reasons, we recommend upgrading from v5 to v6 as soon as possible.

Use a parallel migration: keep v5 available for rollback, generate a new package with v6 compatibility mode, validate it, and only then switch the production environment.

Related documentation:

• v6 Quick Start
• v6 CLI Reference
• v6 Compatibility and Protection Scope
• v5 documentation archive