How RJNI runs today, what a protected jar needs at deployment, and why code signing isn't part of that.
RJNI runs as a JVM application against an input and output JAR path, invoked as one step in a build pipeline. A packaged, standalone CLI binary, and build-tool plugins for Gradle and Maven, are planned but not yet shipped, see the status note on Getting started.
The output is a drop-in replacement JAR: same entry point, same public behaviour, runs on an ordinary JVM. Nothing about how you deploy or launch it changes.
Neither Windows Authenticode nor macOS notarization is required by this architecture, and
neither is planned. RJNI's output is a library loaded in-process via System.load()
from already-running JVM code, not a shell-launched executable, so the launch-time
"unverified developer" gate both mechanisms exist to satisfy doesn't apply here. The
one exception you can fix yourself: macOS applies its quarantine attribute to a jar downloaded
through a browser, which can propagate to the extracted native library on first load.
Resolved with a right-click-then-Open, or xattr -d com.apple.quarantine run
against the jar.