# JetBrains Put IntelliJ's Java Brain in VS Code

JetBrains built a VS Code extension carrying IntelliJ's Java and Kotlin intelligence, and as someone who has hand-built an LSP client for a JetBrains plugin, I have a stake in reading this honestly.


JetBrains sells IDEs. In August 2026 it also started giving away, in preview, the exact Java and Kotlin intelligence that its IDEs have always used to justify the licence. I build JetBrains plugins for a living, so I read that announcement more carefully than most people will.
What actually went out “IntelliJ IDEA Goes LSP” is a preview extension that brings IntelliJ’s Java and Kotlin code intelligence into VS Code and its forks, Cursor and Antigravity included, over the Language Server Protocol. It is free while it is a preview. JetBrains says an Ultimate licence will be required once it is not. That is the whole announcement, and it is a strange one for a company whose entire product has historically been the editor wrapped around that intelligence, not the intelligence by itself.
Separating the two is the actual news. Java and Kotlin completion, navigation, and inspection quality inside IntelliJ have never been portable. They lived inside the IDE process, tied to IntelliJ’s own indexing and PSI machinery, and you got them by opening IntelliJ. Now the engine talks LSP, which means in principle it can sit behind any editor willing to speak the same protocol on the other end. In principle. A preview extension for three specific VS Code forks is not “any editor,” and free-during-preview is not “free.”
What it does not mean It does not mean VS Code becomes IntelliJ, or that JetBrains is quietly retiring its own IDE. The licensing model is intact and stated up front: this is a funnel, not a giveaway, and the eventual Ultimate requirement means the business still runs on the same thing it always ran on. It also does not tell you anything certain about JetBrains’ longer strategy, and I am not going to pretend I know it. Companies ship experiments that go nowhere all the time. What I can say is that this is not a one-off stunt, because it sits next to a second, quieter move on the exact same protocol, going the other direction.
The other direction, and where I sit in it IntelliJ’s LSP client API, the part that lets an IntelliJ plugin consume an external language server instead of writing its own PSI-based language plugin from scratch, became generally available to all plugin developers in September 2025. JetBrains open sourced that client API during the IntelliJ IDEA 2026.2 development cycle. So in under a year, JetBrains formalised both sides of the LSP conversation: IntelliJ as a client that reaches out to a language server, and now IntelliJ’s own engine as a server that something else reaches into.
I care about the client side specifically, because Flexible Julia, my own JetBrains plugin, is an LSP client. It can drive three completely different Julia language server backends: LanguageServer.jl, the newer JETLS, and Fatou, which is a standalone Rust binary that never runs Julia at all. Three different runtimes, one plugin, because LSP is the thing they all agree on. That range is a decent advertisement for the protocol on its own.
Here is the part that is specific to me rather than to the news: I built that client by hand. Looking at my own code, there is no sign of an official client API in it, just raw process I/O, Content-Length headers parsed manually, and a comment I left myself after finding out the hard way that reading those headers with a character-based reader instead of a byte-based one silently corrupts the stream. That is the exact plumbing the now-open-sourced client API exists to hand you for free. I do not know yet whether moving Flexible Julia onto the official path is worth the migration cost for something that already works in production, and it would be dishonest to promise you an answer I have not tested.
The honest read What I take from watching both halves of this land close together is not a grand JetBrains strategy, because I do not have access to one and would be guessing if I claimed otherwise. What I take from it is narrower: JetBrains has decided LSP is the right seam to expose Java and Kotlin intelligence through, on both sides of the wire, at the same time the rest of the editor market is full of forks competing on exactly that kind of interoperability. That is a bet about where the real advantage in an IDE actually sits, not proof of where it lands.
If you want to try the VS Code side, it is here: blog.jetbrains.com/idea/2026/08/intellij-idea-goes-lsp. If you want to see what a plugin built on the client side of that protocol looks like from the inside, Flexible Julia is still a new, actively developed extension, not a finished one, and now I get to find out whether the plumbing I wrote by hand before there was an official version to lean on was wasted effort or just early.