Compatibility
Protection should fit the application you ship.
Java versions are part of the release target#
The ordinary injected runtime helpers target Java 17 without preview features. This does not lower the Java requirement of your application: newer class files and APIs still require their original runtime. Native interface carriers have a separate Java 21 boundary.
Validate the actual output on every Java version you support. The engine’s own development JDK is not a statement that every protected application needs that JDK.
Names can be part of an external contract#
Reflection, service loaders, serializers, dependency injection and plugin frameworks may refer to names indirectly. Renaming or removing such members can break those contracts. Bring framework information and externally referenced entry points to the configuration review.
- Test configuration-driven class loading and resource lookups.
- Check serialized data and compatibility with previously stored objects.
- Exercise framework startup and extension discovery, not just a simple main method.
Native protection has a platform boundary#
The current native backend targets Windows x64 using the MSVC toolchain. A native-protected build must be tested on that target. This is not a promise of native portability to Linux, macOS or other CPU architectures. Use the Java protection path where portability is required.