Running the protected JAR
There is nothing to wire up. Nativify adds the code that loads the native libraries for you, so a protected JAR runs exactly like the original.
What's inside the output JAR
- Your original classes, with the protected method bodies replaced by
nativestubs. - The native libraries (
.so/.dll/.dylib) for each platform you built, embedded inside the JAR. - A loader that extracts and loads the correct native library automatically at startup.
You don't add any loader call, change your main method, or set any system property.
Shipping to multiple platforms
Build for every platform you intend to run on, in one command:
dist/bin/nativify -i app.jar -o app-protected.jar \
-compileFor windows-x86_64,linux-x86_64,linux-aarch64
All requested native libraries are embedded in the single JAR; at startup the loader picks the one that matches the running OS and architecture. If you ship to a platform whose native library isn't in the JAR, that JAR won't run there — so include every target you support (see Limitations).
Signed JARs
Protecting a JAR modifies it, which invalidates any existing signature. Nativify
removes the now-invalid signature files (*.SF, *.RSA, *.DSA, *.EC) from
META-INF/. Re-sign the protected JAR if your distribution requires a signature.
Stripped native libraries
With the dynamic-registration feature enabled, the embedded native libraries can be
stripped of their symbols for additional protection — runtime loading still works the
same way. See Configuration.
If it doesn't load
An UnsatisfiedLinkError almost always means the JAR doesn't contain a native library
for the current platform — rebuild with the right -compileFor target. See
Troubleshooting.