Protector4J 6 / P4JX

Protection across the full bytecode lifecycle

P4JX keeps archive access, class parsing, protected linking, interpretation, JIT compilation, and runtime integrity inside a customized HotSpot security boundary.

Traditional class encryption

Decrypt first, then hand plaintext to the JVM

A custom ClassLoader can hide files on disk, but the ordinary class definition boundary and runtime inspection mechanisms remain available.

• The loader becomes a concentrated interception point.
• Plain class structures re-enter the standard JVM pipeline.

The P4JX architecture

The protected archive and runtime form one security boundary

Protection remains active from authenticated archive access through parsing, linking, interpretation, JIT compilation, and runtime integrity checks.

• Closed archive access inside the VM
• Per-method staging and immediate remasking
• Interpreter and JIT decode chains

Seven layers. One continuous trust chain.

1. L1 · Authenticated archive
2. L2 · Staged class loading
3. L3 · Protected linkage
4. L4 · Protected interpretation
5. L5 · Compiled execution protection
6. L6 · Runtime integrity
7. L7 · Anti-injection boundary

Protected at every transition

From .p4jx delivery to execution inside the VM, one runtime chain carries protection forward.

1. Seal
   Package JAR, WAR, or library content into a protected .p4jx archive.
2. Load
   Bring protected content into the VM runtime during loading.
3. Link
   Complete verification and protected linking inside the VM security boundary.
4. Execute
   Execution remains within the runtime protection boundary.

Built for real Java applications

Protect existing deployment shapes while preserving the runtime behavior that frameworks and scanners depend on.

Java: 8 · 11 · 17 · 21 · 25
Systems: Windows · macOS · Linux
Architectures: x64 · x86 · Arm64