Any plan for Supporting Language Server Protocol?


The language server protocol (LSP) is a common protocol for a tool and a language smartness provider.

It will be nice to have a Kotlin language server, since there are already some popular LSP clients available (VSCode, NeoVim) and some are in progress (emacs, sublime etc.).


We have no plans to support LSP at this time. Instead, we’re focusing on providing the best possible Kotlin development experience in our own IDE, IntelliJ IDEA.


While I understand your focus on developing your IDE, I believe the general acceptance of Kotlin is in the best interest of both JetBrains and the programming community. While I wish to use Kotlin on my work projects, I cannot convince managers to even consider Kotlin since there is no Kotlin language server to support integration with a variety of tools from a variety of vendors and the Open Source community. IF JetBrains were to play nice, it would help the adoption of the Kotlin languages. Sure some members of the team would use tools not built by JetBrains, but I and many others would purchase commercial IntelliJ IDEA licenses, because it would be the leading tool. So overall, I believe adding such community focused capabilities would help your business as well as the greater adoption of the Kotlin language.

Thank you for reading this.


I think supporting LSP would help provide the best possible development experience. Since the protocol is here to build outstanding support for a language, all the IDE has to do is support the protocol. I think the IntelliJ IDEA would benefit largely from supporting this. What’s the argument against it?


The LSP doesn’t allow to build outstanding support for a language, it allows to build the “least common denominator” support only.


Just to understand. What language support would be missing from the IDE if IntelliJ was using the Language Server Protocol?


For example, all refactorings other than Rename.


Indeed, as per this issue. Thanks.


This is a no excuse. You can’t always let the commons denominator be the same and extend the protocol with custom requests that fulfills your needs. This way your open source code could really be useful to the community and not confined in the Intellij Idea scenario.
You just have to decide if you want an open API approach or prefer to keep everything in house. (Which is legitimate, I’m not judging anyone.)


We can develop our product far more efficiently if we can build the features we need as part of our product directly, not as extensions to a third-party protocol. Also, the quality of experience of people developing Kotlin in IntelliJ IDEA is far more important to us than the usefulness of our open source code to the community of developers not using IntelliJ IDEA.


I’ve built a decently complete language server implementation using the Kotlin compiler implementation, it’s still a little buggy but quite usable. You can try it out by installing it from the VSCode marketplace:


We maintain an Intellij plugin for our product. Our product also runs a Language server that works well on VS code, vim, emacs etc. It’d be nice if IntelliJ undestands the language server protocol to provide basic features like auto-completion, symbols etc so that we don’t have to re-implement all of this on our IntelliJ plugin.


There’s a plugin for IntelliJ IDEA that allows it to act as a client for a Language Server Protocol server:

Official support for Visual Studio Code

I am currently developing a Kotlin language server and an experimental Kotlin debugger for VSCode. The language server is a fork of George Fraser’s version, which is not actively maintained anymore. So if anyone is interested in contributing, I would definitely appreciate support. :slight_smile: