daniellansun commented on PR #2936: URL: https://github.com/apache/groovy/pull/2936#issuecomment-5731710074
@blackdrag Thank you for taking the time — and for pushing on “what this is,” not only on the diffs. The sentence you quoted is outdated. Joint compilation *is* in groovy-lsp now; what we still refuse is IDE- or build-tool-driven joint work (Gradle/Maven Tooling API, JDT, cross-language rename). That mix of claims was confusing. Here is a sharper picture of what this PR is trying to be. **What it is.** A compiler-backed Language Server for Groovy: same in-tree `CompilationUnit` (through `SEMANTIC_ANALYSIS`, no Groovy classgen), client-supplied classpath, conservative edits. When `.java` sources are present it uses the compiler’s own joint path (`JavaAwareCompilationUnit` + `memStub` + `javax.tools` javac) so Groovy and Java *types* can see each other. That is compiler-level joint compilation, not an IDE joint-compile protocol. **What it is not.** Not a replacement for Groovy-Eclipse / IntelliJ / edt. Not GDSL, not Gradle/Maven invocation, not DAP, not a test runner, not identifier-scan rename. Not a full Java language server (no Java completion/format/Java-only rename). **IDE use.** I agree with your limits. This will not match a serious plugin on large projects, custom compiler configuration, or cross-language rename. The client must push classpath/source paths; if those differ from the IDE, the LS will differ too. A lean editor can use it; a full Groovy+Java IDE still wants edt/JDT. We should not advertise it as more than that. **Reuse by other LSPs.** Prominic could *in principle* be replaced for a small Groovy-only editor. groovyls (GDSL, forced STC, Aether) and edt (JDT) are not going to sit on this tomorrow. That reuse story was a hypothesis, not something we have evidence for. I should not have leaned on it as a reason for the design. **The extension mechanism.** You are largely right. The built-in `groovy.lsp.stc` pass exists because `@TypeChecked` / `@CompileStatic` run at `INSTRUCTION_SELECTION`, which we never reach. It copies `DIRECT_METHOD_CALL_TARGET` onto `methodTarget` for those annotated members only, so hover/rename/inlays can see a *compile-time* bind. Dynamic Groovy is left alone. Rename still refuses when `methodTarget` is empty. Unique-arity hover is labelled `_inferred_`. Those binds are not a promise of the runtime target — we have to live with that, as you say. That pass does **not** need to be a `ServiceLoader` plugin. It can be a private step after compile. The SPI was sketched so a later GDSL / forced-STC / extra-settings plugin (or `groovy-mcp`) would not fork the stdio loop. `groovy-mcp` itself only needs to wrap the process; it does not need `GroovyLspExtension`. No other extension ships today. Ordering and maintenance cost are real, and for this PR the SPI is mostly carrying our own STC. If the picture we want is “compiler-backed Groovy LS, optional joint types, conservative edits,” I am happy to fold STC into core and drop or shrink the incubating SPI rather than keep a seam nobody is using yet. I would rather have that be an explicit choice than leave the mechanism looking like a vision we cannot back. Happy to adjust the PR description and the code in that direction if this reading matches what you wanted to pin down. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
