Module Management
Module Management is where you choose how Nativify protects and optimizes a release. A Profile saves a complete selection of modules, target platforms, and modes, so the same reviewed configuration can be used again without rebuilding it by hand.
Start from a Profile close to the result you need, set the target platforms your release actually supports, then enable modules in small, testable groups. A module changes only code to which it applies; enabling it is not a guarantee that every method or call site will be affected.
| Control | Use it for | Effect on builds and releases |
|---|---|---|
| Profiles | Saving a named, reviewable configuration for an application or release channel | No runtime cost. Update a Profile only after testing the protected artifact. |
| Auto Save | Persisting valid changes to the active Profile as you work | No effect on the protected artifact. Turn it off when you want to compare several configurations before saving one. |
| Method Selection | Deciding whether to protect @Nativify methods or all eligible methods | A larger selection can increase build time, native artifact size, and the amount of application behavior to test. |
| Target Platforms | Producing native output for every operating system and architecture you ship | Each target increases build output and release-test scope. Select only audited release targets. |
A practical rollout
- Begin with the default or Balanced Profile and the smallest useful method selection.
- Select every target platform on which the protected JAR will run. Do not rely on a build target that is not part of your release plan.
- Enable stable optimization or obfuscation modules first. Verify ordinary application flows, startup, integrations, and performance on every target.
- Add experimental modules one at a time. Keep the test result and Profile together so a known-good configuration can be restored.
- Before publishing, smoke-test the exact protected artifact on every supported OS, architecture, and JDK distribution.
Reading the module reference
The reference groups modules by their primary purpose. Each entry describes the intended effect, likely cost, and the compatibility boundary that matters to a release.
| Term | Meaning |
|---|---|
| Stable | A supported configuration. It still needs testing with your application, target platforms, and Java runtime. |
| Experimental | A narrower compatibility envelope or a stronger behavioral trade-off. Enable it only after staging tests cover representative production behavior. |
| Build cost | Extra compilation time, memory use, or native output size. The exact cost depends on the selected code and target platforms. |
| Runtime cost | Added work while the protected application runs. A module may instead improve a particular hot path, have no measurable effect, or apply only to some code. |
Performance descriptions are directional rather than guarantees. Measure the protected artifact with representative workloads, especially before enabling several obfuscation or runtime-protection modules together.
Compatibility checklist
- Keep the JDK vendor and major version used in staging close to production.
- Test third-party integrations, reflection-heavy code, serialization, dynamic proxies, native integrations, and custom class loading when they are present.
- Verify behavior with the deployment tooling your customers use, including debuggers, profilers, security products, virtual desktop infrastructure, and automated test environments where applicable.
- Treat target-platform restrictions and module dependencies as hard configuration boundaries.
See Module Reference for the individual module descriptions.