bugfix: stop a build tool restarting its daemon on every debug session - #8774
bugfix: stop a build tool restarting its daemon on every debug session#8774damiankus-vl wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughThe change centralizes ChangesJava home parsing and integration
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
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 `@mtags/src/main/scala/scala/meta/internal/metals/JdkSources.scala`:
- Line 51: Update the fromString parsing branch in JdkSources so the file:
prefix check is case-insensitive, allowing mixed-case schemes such as FILE:.
Preserve URI-to-AbsolutePath conversion for matching values and add a test
covering a mixed-case file URI.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: d815745a-5494-4705-9005-6b3e13a82b3c
📒 Files selected for processing (3)
metals/src/main/scala/scala/meta/internal/metals/mbt/MbtDebugSessionStarter.scalamtags/src/main/scala/scala/meta/internal/metals/JdkSources.scalatests/unit/src/test/scala/tests/JdkSourcesSuite.scala
d8eb02d to
569d67e
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
1 similar comment
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
The MBT debug path exported no JAVA_HOME when neither the build target nor the user configured a java home, so the launched command inherited whatever the environment held. That value often ends with a separator, `/jdk/Home/`, while every command that goes through `ShellRunner` exports the same JDK as `/jdk/Home`. The build tool compares JAVA_HOME against the value its running daemon started with, sees two different JDKs, and shuts the daemon down. It did that between the importer's commands and the ones Metals launched, and the analysis cache went with it. The debug path now goes through `JdkSources.envVariables`, like every other command, so all of them export the same spelling. `JdkSources` also accepts a `file:` URI, which is how a BSP `JvmBuildTarget` reports its java home; `AbsolutePath` alone reads `file:///jdk/Home` as a relative path whose first segment is `file:`. `JdkSourcesSuite` covers the spellings a java home reaches Metals in, one case per platform: a trailing separator, a `file:` URI, a percent-encoded space, a Windows drive or share, and the spellings that no path can hold. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2c95316 to
b69a69c
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
Reproduction steps
Actual behavior (main-v2)
The test case fails due to differences in JAVA_HOME path spelling
If we add a client_debug parameter (apply this patch: client_debug.patch), we can observe this warning
Note the difference in the trailing slash
default_system_javabase=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
default_system_javabase=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/
Expected behavior (fix)
BazelDapMbtLspSuite succeeds

Description of changes
The MBT debug path exported no JAVA_HOME when neither the build target nor the user configured a java home, so the launched command inherited whatever the environment held. That value often ends with a separator,
/jdk/Home/, while every command that goes throughShellRunnerexports the same JDK as/jdk/Home. The build tool compares JAVA_HOME against the value its running daemon started with, sees two different JDKs, and shuts the daemon down. It did that between the importer's commands and the ones Metals launched, and the analysis cache went with it.The debug path now goes through
JdkSources.envVariables, like every other command, so all of them export the same spelling.JdkSourcesalso accepts afile:URI, which is how a BSPJvmBuildTargetreports its java home;AbsolutePathalone readsfile:///jdk/Homeas a relative path whose first segment isfile:.JdkSourcesSuitecovers the spellings a java home reaches Metals in, one case per platform: a trailing separator, afile:URI, a percent-encoded space, a Windows drive or share, and the spellings that no path can hold.Summary by CodeRabbit