Protection for Java class libraries

Library Encryption corresponds to the low-level encode command; it only generates a protected archive, does not copy the runtime components, and does not create an application startup script.

1. GUI Operations

  1. On the application type page, select Library Encryption. If you need a deliverable package that can be launched directly, choose Java Application, Spring Boot, or Tomcat WAR instead.

    Select Library Encryption

  2. Select the input JAR, the Java version that matches the actual loading environment, and the target platform, then choose between simple mode or advanced mode. The class library output does not include vlxjre, but these selections are still used to determine the runtime identity corresponding to the archive; do not mix outputs from different platforms in order to reduce the number of artifacts.

    Select the library JAR, Java version, target platform, and mode

  3. Simple mode will scan the input JAR and automatically apply the scanner ZIP overlay and archive suffix recommendations supported by Library Encryption. It will still encrypt all .class entries in the input JAR, while leaving other resources unencrypted.

  4. Advanced mode can be configured as needed:

    • Disable JIT for protected methods: Ensures that protected methods run only in the interpreter;
    • Append scanner ZIP overlay: Provides public resources and metadata stubs for tools that directly parse the ZIP’s central directory;
    • Compatibility scan…: Scans for compatibility risks such as ZIP access, suffix assumptions, JNI/native class usage, and runtime bytecode reading.

  5. On the output page, select the complete output filename, normally with the .p4jx suffix. Use .jar only when an integration is hard-coded to require the .jar suffix. The Archive suffix selection or scan recommendation on the advanced page updates the selected filename between .p4jx and .jar. Review the Java version, target platform, JIT, scanner overlay, then click Run protection.

    Single-platform tasks use the exact file path selected. When multiple target platforms are chosen, the GUI creates subdirectories for each platform within the directory where the file is located, with corresponding archives saved there.

2. Use cases

  • Protecting custom JARs that are part of other controlled P4JX applications;
  • Load the P4JX archive using an existing launcher;
  • Advanced integration that requires manual management of the full delivery directory.

If the target is a standard executable application, Spring Boot, or Tomcat, use the corresponding packaging command.

3. Basic commands

p4j encode library.jar library.p4jx

Abbreviations can also be used:

p4j library.jar library.p4jx

encode writes the full output filename provided by the user; thus, both of the following are in P4JX format:

p4j encode library.jar library.p4jx
p4j encode library.jar library.jar

4. ZIP overlay

p4j encode library.jar library.p4jx \
  --zip-overlay scanner

The overlay contains only public resources, directories, and metadata stubs to ensure compatibility with tools that directly parse the ZIP’s central directory. It does not expose the actual protection methods nor convert P4JX into a regular JAR.

5. Runtime requirements

The lower-level encode does not generate vlxjre; the user must provide a VLX runtime that matches the identity used during encoding. Do not:

  • Use a regular OpenJDK/Oracle JDK to load it;
  • Copy lib/modules or native libraries from another version’s output package;
  • Mix runtimes from different target platforms, JDK training lines, or encoding tasks with the archive.

For regular delivery projects, it is preferable to use higher-level packaging commands to automatically maintain these relationships.

6. License

A license issued by the server must be successfully obtained and embedded when generating an archive. Official accounts and trial modes follow the same archive verification process. Do not hardcode passwords in the exported task scripts in automated environments.