ADFA-5052: Defer eager JavaCompilerService construction until a real .java file is touched

[davidschachterADFA]

Summary

DefaultLanguageServerRegistry.onProjectInitialized dispatches setupWithProject to every registered language server unconditionally, regardless of the project's actual language. JavaLanguageServer.setupWithProject() referenced JavaCompilerService.NO_MODULE_COMPILER and called SourceFileManager.clearCache(), both of which trigger class-init that eagerly constructs real javac Context/JavacFileManager machinery plus a full android.jar top-level-class scan -- on the first project open in the app's lifetime, Kotlin-only projects included. shutdown() had the mirror-image problem on every project close.

This is the same eager-load bug pattern ADFA-5010 fixed for the Kotlin Analysis API. While researching whether javac could get ADFA-5010's DexClassLoader/carrier-APK treatment too, I confirmed and sized the real analog (openjdk.tools.javac, ~2,238 classes, ~3.7MB of the dex) and found this identical bug independently of whether a module-split/carrier-APK is ever built. This PR is scoped to just that: no DexClassLoader split, javac/jdk-compiler stay in the main dex, just constructed lazily now.

Change

• setupWithProject() now only stashes the Workspace; the actual reset (destroy NO_MODULE_COMPILER, clear file-manager/JAR-fs caches, index module classpaths) moved to a new ensureProjectReset(), called from getCompiler(), onContentChange(), and analyze() -- all gated on DocumentUtils.isJavaFile(), so the reset now only runs on genuine Java-file interaction.
• shutdown() skips its javac-specific cleanup entirely if that reset never happened.
• Per-file LSP dispatch methods (complete/findReferences/findDefinition/expandSelection/signatureHelp) needed no changes: the editor's IDELanguage already resolves one language server per file before calling any of them, so they were never the source of the cross-language trigger.
• Concurrency: replaced the initial @Volatile + narrow synchronized claim with an explicit PENDING → RESETTING → INITIALIZED / SHUTDOWN state machine guarded by one ReentrantLock held for the entire reset or shutdown, not just the decision to run one. getCompiler()/onContentChange() hold the lock across both the reset and the subsequent JavaCompilerProvider lookup/use (reentrant, so no deadlock), closing a narrow window where a concurrent reset for a newer project could destroy() a compiler mid-use.
• Robustness: an exception during the reset (e.g. a bad submodule) now re-queues the workspace and reverts to PENDING before rethrowing, instead of silently claiming INITIALIZED for a half-torn-down state with no retry path.
• analyze() (diagnostics) now also triggers the deferred reset: JavaDiagnosticProvider.analyze() builds its own JavaCompilerService directly, bypassing getCompiler(), and diagnostics are often the first real Java-file interaction (auto-triggered on file open, ahead of any completion request) -- without this it could run against stale R.jar/classpath caches for an entire session.

These last three items came from a /code-review high pass on the original version of this PR; two other findings from that pass were assessed and intentionally left as-is: shutdown() blocking on an in-flight reset with no cancellation checkpoint (real, but performance-only -- no crash/corruption -- and disproportionate to fix given the narrow, bounded-cost window); and KotlinLanguageServer still constructing eagerly (real, but already fixed by the separate, not-yet-merged ADFA-5010 (PR #1635) -- this branch just forked before that merge landed).

Test plan

• :lsp:java:testV8DebugUnitTest passes
• :app:assembleV8Debug builds clean
• Manual on-device verification (Pixel 6 Pro), initial lazy-load pass: closed a mixed Java+Kotlin project, opened a Kotlin-only project (wizard-created, zero .java files) and its .kt file, opened a second Kotlin-only project's file -- greping the whole session's logcat for JavaCompilerService/SourceFileManager/openjdk.tools.javac/CacheFSInfoSingleton returns zero hits throughout. Then opened a Java project's .java file: SourceFileManager's Creating source file manager instance for module: AndroidModule: :app fires for the first time at that exact point, and live completion on a real field (binding: ActivityMainBinding) returns correct, type-resolved results. No crashes throughout.
• Manual on-device re-verification (Pixel 6 Pro) after the concurrency/robustness fixes: repeated the same negative test (mixed project close -> Kotlin-only project + its .kt file -> still zero javac-related log hits) and confirmed shutdown() doesn't hang/crash when compilerLifecycle is still PENDING. For the positive test, opened a Java file and let diagnostics auto-fire via the file-open/analyze-timer path without ever touching completion first: logcat shows SourceFileManager's creation log firing beforeJavaDiagnosticProvider's "Analyzing:" log, confirming analyze()'s new ensureProjectReset() gate actually runs ahead of diagnostics. Live completion (which now holds the widened lock across the provider lookup) still returned correct, type-resolved results, naturally exercising concurrent getCompiler() + onContentChange() calls (one per keystroke) with no hang or deadlock. Closed the project again from the INITIALIZED state (this time javac really was built) to exercise shutdown()'s actual cleanup branch -- clean shutdown, process survived. Zero crashes/ANRs across the whole session.

🤖 Generated with Claude Code

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[coderabbitai]

📝 Walkthrough

• Defer JavaCompilerService and SourceFileManager initialization until a real .java file is accessed.
• Serialize compiler reset, initialization, use, and shutdown with a ReentrantLock.
• Handle workspace changes during an in-progress reset.
• Retry failed resets by preserving the pending workspace state.
• Clear compiler and filesystem caches and preload module classpaths during project reset.
• Restart analysis after a successful reset on the analysis path.
• Skip javac cleanup during shutdown() when compiler initialization did not occur.
• Keep Java LSP dispatch behavior unchanged.
• Keep javac in the main dex. Do not add DexClassLoader or a carrier-APK split.
• Java unit tests pass.
• The V8 debug app builds successfully.
• Manual verification confirms that Kotlin-only projects do not initialize javac and that Java files initialize the compiler and provide completion.
• Risk: Deferred initialization and serialized lifecycle transitions require continued on-device verification.
• Risk: Reset, compiler access, and provider use now share lifecycle locking. Review performance and deadlock behavior during concurrent analysis and document operations.

Walkthrough

JavaLanguageServer defers project reset and compiler initialization until compiler or Java document processing occurs. A lifecycle lock serializes reset, compiler lookup, document changes, and shutdown. Resets clear caches, preload module classpaths, restart analysis, and retry failures.

Changes

Java deferred initialization

Layer / File(s)	Summary
Project reset state and initialization lsp/java/src/main/java/com/itsaky/androidide/lsp/java/JavaLanguageServer.kt	The server records pending workspace state and performs synchronized resets. Resets destroy stale compiler state, clear caches, preload module classpaths, restart analysis, and preserve newer workspace state.
Interaction-triggered compiler setup lsp/java/src/main/java/com/itsaky/androidide/lsp/java/JavaLanguageServer.kt	Analysis, compiler lookup, and Java document changes perform the deferred reset before compiler access or updates.
Shutdown lifecycle and formatting updates lsp/java/src/main/java/com/itsaky/androidide/lsp/java/JavaLanguageServer.kt	Shutdown serializes cleanup and destroys compiler infrastructure only when initialized. formatCode behavior remains unchanged.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant Workspace
participant JavaLanguageServer
participant Compiler
participant Analysis
Workspace->>JavaLanguageServer: setupWithProject
JavaLanguageServer->>JavaLanguageServer: store pending workspace
Workspace->>JavaLanguageServer: Java analysis or document change
JavaLanguageServer->>Compiler: reset, clear caches, and preload classpaths
JavaLanguageServer->>Analysis: restart analysis
JavaLanguageServer->>Compiler: resolve or update compiler

Loading

Poem

A rabbit watched the compiler wait,
While workspace state stood at the gate.
A Java touch began the reset,
Caches cleared and paths were set.
Then analysis hopped back in.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely identifies the main change: deferring JavaCompilerService construction until a Java file is accessed.
Description check	✅ Passed	The description accurately explains the lazy initialization, lifecycle synchronization, retry handling, testing, and scope of the changes.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch task/ADFA-5052-lazy-load-java-compiler

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lsp/java/src/main/java/com/itsaky/androidide/lsp/java/JavaLanguageServer.kt`:
- Around line 198-205: Serialize project reset, compiler access, and shutdown
through one lifecycle lock or explicit synchronized state. In
lsp/java/src/main/java/com/itsaky/androidide/lsp/java/JavaLanguageServer.kt
lines 198-205, keep reset-in-progress state private until compiler destruction,
cache cleanup, and module cache setup complete; lines 102-106 must represent
pending, resetting, initialized, and shutdown states under that mechanism; lines
144-151 must acquire it before compiler cleanup. Ensure concurrent requests and
shutdown block until reset finishes.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 120f2cf7-d110-4431-8ac1-a9620a9adb9c

📥 Commits

Reviewing files that changed from the base of the PR and between a80a8fa and 0d9356d.

📒 Files selected for processing (1)

• lsp/java/src/main/java/com/itsaky/androidide/lsp/java/JavaLanguageServer.kt

[coderabbitai]

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lsp/java/src/main/java/com/itsaky/androidide/lsp/java/JavaLanguageServer.kt`:
- Around line 109-113: Keep compiler lifecycle operations leased and
synchronized so shutdown cannot destroy a compiler while it is in use. In
JavaLanguageServer.kt:109-113, extend the lifecycle state with active-operation
tracking; at 153-164, make shutdown wait for active operations before destroying
the compiler and remain terminal; at 203-210, prevent setupWithProject() from
changing SHUTDOWN back to PENDING; at 355-359, acquire and use the compiler
through the lifecycle lease; and at 385-396, route onContentChange() through the
same guarded execution mechanism.
- Around line 252-261: Update the reset lifecycle flow around setupWithProject()
and its finally block so a failed reset never transitions compilerLifecycle to
INITIALIZED. Track whether the reset completed successfully, retain PENDING when
it fails or when pendingWorkspace exists, and narrowly catch known recoverable
reset failures to transition to the established explicit error state.
- Around line 214-264: Add focused tests covering the compiler lifecycle around
setupWithProject() and ensureProjectReset(): verify the initial reset is
deferred until Java interaction, a reset failure restores a recoverable
lifecycle state, a project queued during RESETTING becomes pending for a
subsequent reset, and shutdown() safely handles a pending reset before any Java
file interaction. Use existing test seams and lifecycle symbols rather than
relying only on compile tests.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8b58cba5-e4c7-439f-aa27-79459d354d36

📥 Commits

Reviewing files that changed from the base of the PR and between 0d9356d and ad09be1.

📒 Files selected for processing (1)

• lsp/java/src/main/java/com/itsaky/androidide/lsp/java/JavaLanguageServer.kt