feat: support IntelliJ Platform 2026.1

[jomof]

Configuration and test fixes required to support the IntelliJ Platform version 2026.1 (261).

Key changes:

• Added junit-platform-launcher to resolve test discovery issues encountered with platform 2026.1.
• Updated LSPFoldingRangeFixtureTestCase to account for changes in platform EditorTestUtil.buildInitialFoldingsInBackground() behavior. I confirmed gradlew build, test, and verifyPlugin work for all platform versions from 2024.1 to 2026.1. I also did runIde for each and visually confirmed the plugin is loaded. After this change, it is possible to re-enable "IJ Latest" github action since it is currently running against 2026.1.

[angelozerr]

Close this PR in favor of #1459

[angelozerr]

@jomof thanks for your contribution.

I am curious why you are contributing to LSP4IJ? Have you a plugin which consumes LSP4IJ?

If yes, could you add it in https://github.com/redhat-developer/lsp4ij?tab=readme-ov-file#who-is-using-lsp4ij

And if you like LSP4IJ, please add a review in JetBrains Marketplace to help us to promote LSP4IJ. Thanks!

[jomof]

@angelozerr Hi Angelo!
I do have a planned update to the readme here: main...jomof:lsp4ij:asfp-readme. I'm not ready to do it yet, since we're still in evaluation mode, but I'll be happy to give a good review on JB marketplace. We're evaluating whether LSP4IJ could suit our needs in the long run (with my help of course, if you'll have it). We rebase to IJ EAP early to shake out any bugs in the integration well beforehand, which is why I was interested in 261 support.

We currently use LSP4IJ for Rust language services, but I'll be looking at DAP soon(ish).

Actually, I have a quick question. Is Kotlin allowed in LSP4IJ codebase? I noticed while I was working on ij-253 that Kotlin would work without configuration changes. Related features we write on our side will certainly be Kotlin so I was previously working under the assumption that upstreaming anything that might be generally useful was off the table.

[angelozerr]

@angelozerr Hi Angelo! I do have a planned update to the readme here: main...jomof:lsp4ij:asfp-readme.

It is a super news for LSP4IJ, hope you will adopt LSP4IJ.

I'm not ready to do it yet, since we're still in evaluation mode, but I'll be happy to give a good review on JB marketplace. We're evaluating whether LSP4IJ could suit our needs in the long run (with my help of course, if you'll have it). We rebase to IJ EAP early to shake out any bugs in the integration well beforehand, which is why I was interested in 261 support.

Nice!

We currently use LSP4IJ for Rust language services, but I'll be looking at DAP soon(ish).

With user defined https://github.com/redhat-developer/lsp4ij/blob/main/docs/user-defined-ls/rust-analyzer.md or with an IJ plugin? And for DAP please see https://github.com/redhat-developer/lsp4ij/blob/main/docs/dap/user-defined-dap/codelldb.md

Actually, I have a quick question. Is Kotlin allowed in LSP4IJ codebase?

Today I would like to avoid mixing Java and Kotlin, but if there are some good reason to use Kotlin (if I remember inline completion is just available with Kotlin) I am open to change that.

I noticed while I was working on ij-253 that Kotlin would work without configuration changes. Related features we write on our side will certainly be Kotlin so I was previously working under the assumption that upstreaming anything that might be generally useful was off the table.

I would prefer keeping Java but if there is a good reason to use Kotlin, I am opened with this idea.

[jomof]

With user defined https://github.com/redhat-developer/lsp4ij/blob/main/docs/user-defined-ls/rust-analyzer.md or with an IJ plugin?

We have a little plugin on our side to do the configuration. For the most part we try to make the experience integrated for the user.

Today I would like to avoid mixing Java and Kotlin, but if there are some good reason to use Kotlin (if I remember inline completion is just available with Kotlin) I am open to change that.

Okay, good to know. Yeah, actually we actually did have to extend org.eclipse.lsp4j.services.LanguageServer in our plugin to get inline completion support.

interface InlineCompletionService {
  @JsonRequest("textDocument/inlineCompletion")
  fun inlineCompletion(params : InlineCompletionParams) : CompletableFuture<InlineCompletionResult>
}

We had to have it because that's how AI completions came in for us. It's not really cleanly upstreamable because I didn't plan for that being possible. Is there a reasonable chance a PR for that in Kotlin would be accepted? If so, I could investigate what it would take.

[angelozerr]

We had to have it because that's how AI completions came in for us. It's not really cleanly upstreamable because I didn't plan for that being possible. Is there a reasonable chance a PR for that in Kotlin would be accepted? If so, I could investigate what it would take.

If you can do that with Java without hack, I would prefer, otherwise yes if it is not possible. It would be fantastic if you could provide inline completion in LSP4IJ to fix #643