Configure NOL with the analysis assistant
Start from a configuration
Open the NOL configuration dialog from Object Flow, or choose Assist configuration while configuring a build. The assistant has no sidebar item. It carries the current project, input, and complete unsaved compiler configuration, including the backend, targets, and NOL declarations. Analysis is an independent, free tool; running it does not activate Object Localization or submit a build.
NOL requires declarations about application entry points and dynamic boundaries. Search the input index for exact classes, members, and resource paths. Readable method signatures help distinguish overloads; the editor supplies their exact bytecode descriptors. External symbols can be entered manually. These declarations describe intended application behavior: do not add a broad declaration simply to remove a diagnostic.
Follow the setup flow
The guided flow is Input → Entry points → Resolve issues → Review → Build.
- Input: use the carried JAR or choose an input. Indexing exposes symbol and resource choices without executing the application.
- Entry points: review the backend's likely
public static void main(String[])candidates and select the methods that actually start your application. These are proposals, not an exhaustive list of application entry points, and are not added automatically. Declare other externally invoked entry methods when needed. - Resolve issues: run analysis, inspect the evidence, and prepare declarations for the relevant boundaries. Prepare several changes before running analysis again; each run verifies the submitted input and configuration together.
- Review: inspect the configuration difference and select the NOL changes to return to the surrounding draft. Saved project defaults are untouched. You can also return without declaration changes.
- Build: decide explicitly whether to select Enable NOL for this build, then return to the build draft, review it, and submit through the normal build action. Enabling NOL also enables its required module settings for the selected backend; review those changes. Analysis and activation remain separate choices.
| Configuration group | What to declare |
|---|---|
| Entry points | Methods that can start application execution, with their class and exact signature. |
| Reflection and JNI | Classes and members discoverable through these boundaries, including initialization and any deliberate all-declared-member selection. |
| Serialization, proxies, resources | Serialized classes, proxy interface groups, and resource declarations used by the application. |
| Keep | Class declarations or members that must remain. Keeping a declaration does not itself add an executable entry point. |
| Loader domains | Class-loading domain names, parents, and classes. |
| Enum localization | The off or proven mode; availability depends on the backend and NOL configuration. |
Apply to draft updates the surrounding configuration draft. Cancel leaves it unchanged. The complete compiler draft and selected input survive the trip to the assistant and back, including unrelated module settings. Saving the project is a separate action. Advanced JSON is available for exact editing and roundtrips the same configuration; you do not need to write JSON to use the ordinary forms. Report paths and schema details are managed by the service.
Analyze and fill gaps
Run analysis to see the proof outcome, candidate classifications, errors, and warnings. Filter issues by location or severity and inspect their evidence. A candidate is an analysis result, not a claim that optimization has already happened.
Each actionable diagnostic uses its structured configurationSection and guidance to open an issue-specific declaration prompt. The prompt explains the affected boundary and asks for exact classes, members, or resources. For example, an unresolved reflective target needs the actual target classes or members from the application owner. A call to a reflection API alone cannot prove which targets are possible. The assistant neither guesses targets nor parses English diagnostic messages to decide what to declare.
Without declared entry points, the analysis conservatively includes all original methods, including private methods that external reflection might invoke. The entry-point warning explains that scope; it does not itself make the proof incomplete. Declare entry points only when you can account for every external entry into the application. Selecting one convenient method simply to remove warnings would describe a different application boundary.
Prepare the declarations locally, then run analysis once for the combined changes. Review the resulting configuration difference and select the NOL changes to apply back to the draft. Other compiler settings and saved project configuration are not overwritten. Reanalysis compares resolved, remaining, and new issues. Changing the input or configuration marks older evidence as unverified for the current draft; editing a declaration alone does not prove that an issue is resolved.
Understand completion and downloads
An analysis can finish with an incomplete proof. Read the remaining issues instead of interpreting completion as permission to localize every class. A process failure and an incomplete proof are different results; a failed run can still have a useful diagnostic report. If the process failed before producing a report, the interface says so.
Download the raw JSON when you need the full evidence or want to share it with a collaborator. Reports are private and follow task access controls. Analysis does not produce a newly protected JAR. Its charge is 0 NCU, including unsuccessful runs; upload, concurrency, and resource limits still apply.