Module Reference

This reference describes the modules available in Module Management. It is intended for release owners deciding which protections and optimizations belong in a Profile. Test the complete protected artifact rather than judging a module only from a small benchmark or a successful compilation.

Core

Compiler backend

Missing backend values in existing configurations mean JNI. JNI retains multi-target output and its five presets. JVMCI produces a single Windows x86-64 or Linux x86-64 artifact and requires the supported Zulu runtime. The module catalog resolves backend and target availability, built-in behavior and dependencies. Review adjustments when switching backend; each backend keeps its own draft. The JNI-specific dependency descriptions below do not override that catalog. In a JNI build with multiple targets, a platform-specific module may apply to only some targets. The UI lists that scope explicitly; enabling a Windows-only protection does not apply it to the Linux artifact.

Structural Obfuscation

Configure common transformations in the form and inspect advanced options when required. Application is the default scope; whole-artifact is experimental and needs testing against external consumers. Keep rules preserve the declarations that integrations depend on. A fixed 64-bit seed is stored as a decimal string in Web configuration so JavaScript does not round it. Download the private structural mapping from build details and retain it with that exact release. The service chooses its storage path.

NOL configuration and analysis

The NOL dialog groups entry points, reflection, JNI access, serialization, proxies, resources, keep rules and loader domains. Keeping a declaration does not make it an execution entry point. Search for exact classes, members and resources from the JAR, or enter external symbols manually; advanced JSON uses the same configuration. Enum localization has off and proven modes and requires the supported JVMCI/NOL combination shown by the catalog.

Assist configuration opens the free guided Input → Entry points → Resolve issues → Review → Build flow with the complete unsaved compiler draft. It has no sidebar item. Likely main-method candidates require user selection. Issue prompts use structured configuration sections and ask for the actual targets; they do not guess declarations. Prepare multiple edits before rerunning analysis. Review selected NOL changes before returning, or return without declaration changes; saved project defaults remain untouched. Analysis does not activate Object Localization. Its reports describe candidates and proof completeness for the submitted input and declarations, and changing the draft leaves older evidence unverified. See Configure NOL with the analysis assistant for the workflow.

Semantic Mirage and Runtime Profile

Semantic Mirage is an experimental JVMCI protection option. Runtime Profile is an optional JVMCI diagnostic feature; its measurements add runtime work. Both are off by default. Availability and dependencies are resolved for the selected backend and target, and profiling is not a prerequisite for compilation.

Method Selection

Choose Annotated to protect methods marked with @Nativify, or All eligible to extend protection to every eligible method. Annotated selection is the better starting point when a release needs precise control over scope.

Target Platforms

Select the operating system and architecture combinations for which Nativify produces native output. JNI Profiles can contain from one to four targets; JVMCI Profiles contain exactly one Windows x86-64 or Linux x86-64 target.

Dynamic Native Registration

Dynamic Native Registration binds protected methods when the application starts. It is also required by modules that use dynamic registration.

Link-time Optimization

For JNI, Link-time Optimization applies additional optimization after native code for the selected methods is combined. Thin is the scalable default; Full prioritizes the broadest optimization opportunity. JVMCI also supports off, Thin and Full. Its enabled LTO runs within each method recipe’s complete native link unit; it does not merge Java methods across recipe boundaries. Required IR optimization remains active when LTO is off.

Optimization

IR Optimization

IR Optimization improves the native code generated for protected methods. Standard is the default choice; Aggressive applies a broader optimization set.

Static Direct Call

Static Direct Call optimizes eligible calls between protected static methods, avoiding unnecessary boundary work when both sides can be linked directly.

Virtual Inline Cache

Virtual Inline Cache accelerates repeatedly observed virtual and interface call targets when they can be cached safely.

Object Flow

Object Flow uses proven information about how objects move through selected code to simplify eligible operations. Its Advanced option exposes further focused optimizations.

String Flow

String Flow is an Advanced Object Flow option for predictable, non-escaping string-length work in eligible regions.

Exact Instance Direct Call

Exact Instance Direct Call is an Advanced Object Flow option that directly calls an instance target when its type is proven exact, while preserving normal dispatch elsewhere.

Object Localization

Object Localization is an Advanced Object Flow option for configurations where object use is precisely understood. Its configuration records application entry points and the dynamic access patterns that must remain available.

Stdlib Replacement

Stdlib Replacement substitutes supported standard Java library operations with optimized native equivalents when Nativify can do so safely.

Unsafe Memory Access

Unsafe Memory Access uses sun.misc.Unsafe for eligible direct field access.

Obfuscation

Obfuscation modules increase the effort needed to understand the protected native code. Their strongest configurations usually increase native code size, build time, runtime work, or all three. Add them after a stable baseline has passed functional and performance testing.

String Encryption

String Encryption protects native string constants so they are not stored as directly readable native text.

Constant Encryption

Constant Encryption encodes native numeric constants, including floating-point bit patterns, to make straightforward inspection less useful. Available runtime operands and supported use sites affect coverage.

It replaces the previous implementation under the same module and feature IDs. Choose Integer only, Floating-point only, or Mixed expression families. Integer only adds no floating-point arithmetic. Floating-point only still needs integer bit packing and conversions. All three modes can protect both integer constants and floating-point bit patterns.

Sampling uses the build seed. Proof and instruction-budget limits can reduce actual coverage below the requested percentage. Existing enabled-only configurations use the defaults above. Dashboard presets explicitly increase coverage and budget as you move toward protection. LLVM optimization stays enabled.

Bogus Control Flow

Bogus Control Flow adds opaque branches that make the native control-flow graph less direct to follow.

VM Control Flow Flattening

VM Control Flow Flattening represents eligible native control flow through a protected dispatcher. The module name refers to the protected execution form, not to a Java virtual machine.

Instruction Substitution

Instruction Substitution replaces selected native operations with equivalent, less obvious instruction sequences.

Linear MBA

Linear MBA rewrites eligible arithmetic using mixed boolean-arithmetic expressions, making an operation harder to simplify by inspection.

Split Basic Block

Split Basic Block divides eligible native blocks into smaller blocks to make control flow less compact.

Call Indirection

Call Indirection replaces direct native calls with indirect calls through a pointer.

Global Variable Indirection

Global Variable Indirection accesses eligible native globals indirectly rather than through a direct reference.

VM Virtualization

VM Virtualization transforms eligible integer regions into a protected execution form designed to be harder to analyze.

LLVM Anti-Debugging

LLVM Anti-Debugging adds native debugger checks to protected methods.

LLVM Anti-Hooking

LLVM Anti-Hooking checks protected native method entry points for signs of inline modification.

Runtime Protection

Runtime-protection modules can decide that an environment is not acceptable for the protected application. They are intentionally incompatible with some development, automation, virtualization, or analysis environments, so staging tests must closely match production.

Runtime Anti-Analysis

Runtime Anti-Analysis checks for suspicious Windows environments. Balanced uses a lower-sensitivity policy; Strict applies more sensitive checks.

VM Rejection

VM Rejection prevents the protected application from running in detected Windows virtual-machine environments.

Encrypted Native Payload

Encrypted Native Payload protects all selected Windows x86-64, Linux x86-64, and Linux ARM64 native libraries at rest in one authenticated graph. Each target uses its own verified bootstrap. Linux streams decryption into anonymous ELF segments, without retaining a complete plaintext main file or memfd. Temporary AES material and decompression workspaces are released before image code executes. The unmodified recovered main library rejects initialization without a fresh signature from its build-specific loader; this does not prevent runtime memory inspection, native-code patching, or handshake replication after reversing the bootstrap.