Browse documentation
Start
Overview Getting started How it works
Protection passes
Overview Nativization Class name obfuscation Method & field renaming String & constant encryption Control-flow flattening Decompiler-resistant wrapping Anti-tamper checksums Anti-debug detection Resource & asset encryption Native library bundling Loader & runtime hardening Build-time watermarking
Exclusions & configuration
Overview Reflection by name ServiceLoader JPMS module descriptors Spring proxying Proxy-library internals Config-driven keep rules Trial / evaluation mode Configuration reference
Compatibility
Overview JDK & class files Platforms Frameworks & reflection Build integration & deployment
Trust
Security model Known limitations
Account
Licensing
Documentation / Compatibility / Platforms

Platforms

What's been built and verified, separate from the documented target design.

Verified today

macOS has been the project's own development and verification platform throughout building the protection pipeline, including end-to-end runs against an unmodified 1,200-plus-class third-party application.

Design target, not yet independently verified

The project's own build-target design specifies a tiered platform matrix, modelled on a comparable native-compilation tool's verified split: stable: Linux x86-64, Windows x86-64, Windows ARM64, and Apple Silicon macOS; experimental: Linux ARM64 and Intel macOS. This is the documented design, not a claim that every listed platform has been built and tested. Cross-platform builds have not yet been independently produced outside the primary development machine.

If you're evaluating RJNI for a specific deployment target, note the difference. "Verified today" and "design target" are not the same claim. If your deployment platform isn't macOS, treat platform support as planned, not confirmed, until told otherwise.
PreviousJDK & class files