JetBrains has pushed its Java and Kotlin language engine out of IntelliJ IDEA and into Visual Studio Code and Cursor. The company’s “Java and Kotlin by IntelliJ IDEA” extension reached Release Candidate status on October 7, 2026, according to JetBrains’ own blog post announcing the milestone. It is the clearest sign yet that even the maker of the most-used Java IDE on the planet now treats the editor window as replaceable, and the underlying language intelligence as the real product.
The move lands at an awkward moment for Microsoft’s own Java tooling and for Red Hat, whose language server has powered Java support in VS Code for years. It also arrives as AI coding agents, including Cursor’s own agent, lean harder on structured code understanding rather than plain text prediction. JetBrains is betting that developers want IntelliJ-grade refactoring and navigation wherever they type code, not just inside IntelliJ IDEA itself.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Just Shipped: From Preview to Release Candidate in Nine Weeks
JetBrains first opened a preview of the extension on August 5, 2026, calling it “Java & Kotlin by IntelliJ IDEA” and pitching it at developers who work in VS Code or VS Code forks such as Cursor but still want IntelliJ-level code intelligence. Two months later, on October 7, the company announced the extension had reached Release Candidate status, describing the RC as the final build of its Early Access Program. JetBrains said in the announcement that the foundation for a stable 1.0 release is now in place and that the release itself will arrive very soon, though it stopped short of naming an exact date.
That nine-week sprint from preview to Release Candidate is fast by JetBrains’ own historical pace. The company has spent more than two decades building IntelliJ IDEA’s Java and Kotlin analysis engine as a tightly coupled part of its desktop IDE. Exposing that same engine through the Language Server Protocol, the open standard that lets any editor talk to any language-aware backend, required JetBrains to separate logic that had never been designed to run outside its own IDE process.
The Release Candidate remains usable under Early Access terms for 30 days from release, after which JetBrains expects to ship the stable build. Users who install the RC today get a 30-day evaluation window with no license required, mirroring the free terms JetBrains applied to each build during the preview phase.
What “Java and Kotlin by IntelliJ IDEA” Actually Does
The extension is not a thin wrapper that just forwards code to a cloud service. It runs IntelliJ IDEA’s actual Java and Kotlin analysis engine locally as a language server, then speaks the Language Server Protocol so any compatible editor can request completions, diagnostics, and refactorings from it. JetBrains describes the Release Candidate as bringing IntelliJ IDEA’s language technology to the whole development workflow, not just to syntax highlighting or basic autocomplete.
Code Intelligence and Refactoring
Core features carried over from IntelliJ IDEA include smart completion that understands type context, code navigation across large codebases, inspections that flag likely bugs before compilation, and quick-fixes that apply corrections automatically. The Release Candidate adds project-wide refactorings, a step up from file-level editing that lets developers rename a method or extract an interface and have the change ripple correctly across an entire project, not just the open file.
Debugging, Testing, and Build-System Support
Debugging runs through the Debug Adapter Protocol, the companion standard to LSP that lets editors attach a debugger without writing custom integration code for every tool. The extension also includes built-in test running and Spring tooling interoperability, a detail that matters given how much enterprise Java work still runs on Spring Boot. On the build side, JetBrains says the extension supports Maven, Gradle, and Bazel, covering the three build systems most commonly used across both startup and enterprise Java and Kotlin projects.
Distribution runs through the Visual Studio Marketplace and the Open VSX Registry, the latter being the open-source marketplace that VS Code forks like Cursor, VSCodium, and others rely on because they cannot legally use Microsoft’s own marketplace under its terms of service. That dual-channel distribution is why the extension works in Cursor at all.
Why Cursor Gets Special Billing
JetBrains calls out Cursor by name in its announcement, and the reason is specific to how AI coding agents work. When the extension is installed inside Cursor, Cursor Agent can query the same language server for semantic code search, navigation, and code analysis that a human developer would use. JetBrains argues this produces faster and more deterministic results than an agent that has to infer code structure from raw text alone.
That framing points at a broader shift. AI coding agents have historically leaned on large language models reading plain source files, which works but can misjudge symbol references, overloaded methods, or generic type bounds in large Java and Kotlin codebases. Handing the agent a real compiler-grade language server instead of raw text turns fuzzy pattern matching into verified lookups. If an agent asks where a method is actually called from, the language server can answer with certainty rather than a best guess.
This is also a pragmatic move for JetBrains. Cursor has pulled a meaningful slice of professional developers away from both VS Code and JetBrains’ own IDEs over the past two years by pairing an AI-first workflow with a familiar editor shell. Rather than compete head-on for those users with its own AI editor, JetBrains is positioning itself as the language-intelligence layer underneath whichever editor wins, Cursor included.
The Java IDE Market JetBrains Is Defending
IntelliJ IDEA did not need this extension to stay dominant among Java developers. According to JRebel’s 2025 Java Developer Productivity Report, IntelliJ IDEA reached 84% adoption among surveyed Java developers, up from 71% in 2024. VS Code came in second at 31%, and Eclipse continued its multi-year decline, dropping to 28% from 39% two years earlier. Those figures measure adoption rather than exclusive primary-editor share, since many developers use more than one tool, but the trend line is consistent: IntelliJ IDEA keeps gaining while Eclipse keeps losing ground and VS Code holds a stable second position among Java-specific developers.
| IDE / Editor | Java Developer Adoption, 2024 | Java Developer Adoption, 2025 | Trend |
|---|---|---|---|
| IntelliJ IDEA | 71% | 84% | Rising |
| VS Code | Not separately reported | 31% | Stable / second place |
| Eclipse | 39% | 28% | Declining |
Source: JRebel 2025 Java Developer Productivity Report, as cited in industry coverage of IntelliJ IDEA versus Eclipse adoption trends.
Those numbers explain the logic behind the LSP extension. If roughly three in ten Java developers already prefer VS Code’s editing experience while IntelliJ IDEA’s engine keeps pulling further ahead on raw adoption, JetBrains has an opening to serve that VS Code-preferring minority without forcing a tool switch. It can sell the engine instead of the window around it, and in the process keep those developers inside JetBrains’ subscription business rather than losing them entirely to a free, Microsoft-maintained alternative.
VS Code’s Existing Java Stack Isn’t Going Away
VS Code’s current Java support runs through Microsoft’s Extension Pack for Java, which bundles Red Hat’s Language Support for Java extension along with separate tools for debugging, testing, Maven integration, and project management. That stack has been the default Java experience in VS Code for years and is not being removed or deprecated by anything JetBrains has announced. JetBrains’ extension is positioned as an alternative language-intelligence layer, built on IntelliJ IDEA’s own technology rather than the Eclipse-derived Red Hat language server that currently powers the Microsoft pack.
That distinction matters for anyone deciding which to install. The Red Hat-powered Microsoft pack is free and open, built on the Eclipse JDT Language Server lineage. JetBrains’ extension is free to try but ties long-term use to an IntelliJ IDEA Ultimate subscription once the stable release ships and the trial window closes. Developers now face a real choice between a no-cost, Eclipse-lineage language server and a subscription-gated, IntelliJ-lineage one, both running inside the same VS Code window.
| Attribute | JetBrains “Java and Kotlin by IntelliJ IDEA” | Microsoft Extension Pack for Java (Red Hat) |
|---|---|---|
| Underlying engine | IntelliJ IDEA language technology | Eclipse JDT-derived language server |
| Supported editors | VS Code and VS Code forks, including Cursor | VS Code |
| Debugging protocol | Debug Adapter Protocol | Debug Adapter Protocol |
| Build systems | Maven, Gradle, Bazel | Maven, Gradle |
| Status as of October 2026 | Release Candidate | Established, GA for years |
| Licensing after trial | IntelliJ IDEA Ultimate subscription required | Free, open source |
Licensing: What the Free Trial Actually Covers
JetBrains has been explicit about the commercial model even while the product is still a Release Candidate. During the preview, each build renewed a 30-day evaluation period automatically. The Release Candidate can be used for 30 days without a license. After the stable release ships, new users get a 30-day free trial, and continued use after that requires an IntelliJ IDEA Ultimate subscription.
That is a meaningful detail for budget-conscious teams. IntelliJ IDEA Ultimate is already a paid product for anyone using the full desktop IDE, and this extension does not introduce a separate, cheaper tier. It effectively asks VS Code and Cursor users to buy into JetBrains’ existing subscription stack to keep IntelliJ-grade Java and Kotlin support once the trial runs out. Teams that already pay for IntelliJ IDEA Ultimate licenses for some developers get the extension at no additional cost; teams that have avoided JetBrains subscriptions specifically to stay on free tooling will need to weigh whether the refactoring and navigation gains are worth the recurring cost.
The Competitive Landscape: Eclipse JDT, Kotlin LSP, and the Bigger LSP Trend
JetBrains is not the only party running a Java or Kotlin language server through LSP. The Eclipse Foundation’s own JDT Language Server has existed for years and underpins the Red Hat extension that Microsoft bundles into VS Code. JetBrains has also shipped a separate, lighter “Kotlin by JetBrains” extension for VS Code, now at version 0.0.13 according to the project’s GitHub release notes, which bundles a standalone Kotlin Language Server and is explicitly installable in Cursor, VSCodium, and other VS Code forks.
That means JetBrains is currently running two related but separate efforts: a lightweight Kotlin-only LSP extension, and the broader Java and Kotlin by IntelliJ IDEA extension that reached Release Candidate on October 7. The company has not published a detailed feature-by-feature comparison against the Eclipse JDT Language Server, so developers choosing between the two are largely working from each project’s own feature lists rather than independent benchmarks.
The pattern fits a wider trend across the developer tools space in 2026: language-intelligence engines are increasingly being decoupled from the editors that popularized them. Go’s tooling team has been shipping interactive refactoring support through gopls, the Go language server, exposing it through the VS Code Go extension rather than tying it to any single editor. JetBrains separating IntelliJ’s Java and Kotlin engine from the IntelliJ IDEA shell follows the same logic: the editor is becoming a replaceable front end, and the language server underneath is where companies compete.
Historical Context: JetBrains’ Long, Complicated Relationship With VS Code
JetBrains built its business on the premise that a purpose-built, deeply integrated IDE beats a general-purpose text editor with extensions bolted on. That premise has held up well enough that IntelliJ IDEA still leads Java adoption by a wide margin even as VS Code has become the most-installed code editor across all languages combined. But JetBrains has also quietly built bridges to VS Code’s ecosystem for years, shipping language server implementations for Kotlin and now for Java specifically because it recognizes that a large and growing share of professional developers simply prefer VS Code’s lighter weight and faster startup time, especially on laptops and in cloud-based development environments.
The arrival of AI-native forks like Cursor changed the calculation again. Cursor is built on top of VS Code’s open-source core but layers in its own AI agent, and it has attracted a meaningful base of professional developers who want AI-assisted coding without leaving an editor shell they already know. JetBrains naming Cursor directly in its Release Candidate announcement signals that the company sees Cursor’s user base as large enough, and sticky enough, to be worth supporting on day one rather than treating it as an afterthought behind VS Code proper.
Market Impact: What Changes for Developers and AI Coding Agents
For individual developers, the immediate impact is a new, free-to-trial option inside VS Code and Cursor that brings IntelliJ-level refactoring and navigation without requiring a switch to the full IntelliJ IDEA desktop application. For teams already standardized on VS Code for non-Java work who maintain a Java or Kotlin service on the side, it lowers the cost of getting IntelliJ-grade tooling into that one editor rather than running two IDEs across a team.
For AI coding agent vendors, the bigger impact is architectural. Giving an agent direct access to a real language server rather than relying purely on token prediction over raw source text is a pattern likely to spread beyond Java and Kotlin. Agents that can call into a compiler-grade analysis engine for symbol resolution, type checking, and safe refactoring are less likely to produce code that looks plausible but breaks a build. JetBrains’ explicit mention of Cursor Agent benefiting from “faster and more deterministic results” is effectively a preview of how every major coding agent will likely want to consume language servers going forward, not just for Java and Kotlin but across any language with a mature LSP implementation.
For Microsoft and Red Hat, the competitive pressure is real but not urgent. The Extension Pack for Java remains free, widely deployed, and deeply integrated into VS Code’s default Java experience. JetBrains’ extension does not replace it by default and requires a separate install plus, eventually, a paid subscription. The risk for Microsoft and Red Hat is less about losing existing users immediately and more about losing the next generation of Java and Kotlin developers who might default to the JetBrains-powered option from the start if it proves measurably faster or more accurate during the stable release.
What JetBrains Is Saying
JetBrains framed the milestone as a continuation of a commitment made back in August. In its October 7 announcement, the company wrote: “Two months ago, we announced the preview of Java and Kotlin by IntelliJ IDEA – an LSP-based extension that brings IntelliJ IDEA’s Java and Kotlin intelligence to third-party editors, starting with VS Code and its forks, such as Cursor,” according to JetBrains’ blog post on the Release Candidate.
JetBrains added: “We’re moving fast on that commitment, and today marks another big step: Java and Kotlin by IntelliJ IDEA has reached the Release Candidate stage,” according to the same blog post. On the path forward, the company stated: “The foundation for a stable 1.0 release is now in place, and the release itself will arrive very soon,” per JetBrains’ announcement.
Describing the scope of the Release Candidate’s capabilities, JetBrains said: “The RC brings IntelliJ IDEA’s Java and Kotlin language technology to the whole development workflow,” according to the company’s blog. And on the Cursor-specific benefit, JetBrains explained: “When the extension is installed in Cursor, Cursor Agent can use the same language server for semantic code search, navigation, and code analysis, leading to faster and more deterministic results,” as stated in JetBrains’ Release Candidate announcement.
Installing the Extension: A Quick Reference
Developers testing the Release Candidate in VS Code or Cursor install it the same way they would any other extension, through the editor’s extensions panel or, for VS Code forks that rely on Open VSX rather than Microsoft’s marketplace, through the Open VSX Registry directly. A typical settings adjustment to make the new language server the active one for a workspace looks like this:
{
"java.jdt.ls.enabled": false,
"jetbrains.intellijLsp.enabled": true,
"jetbrains.intellijLsp.kotlin.enabled": true
}That kind of toggle, disabling the Red Hat-based language server while enabling JetBrains’ LSP implementation, is the practical decision point for any team evaluating the Release Candidate: run both side by side temporarily, or commit to one as the project’s default and uninstall the other to avoid conflicting diagnostics in the editor’s problems panel.
Predictions: Where This Goes From Here
- JetBrains will likely ship the stable 1.0 release of Java and Kotlin by IntelliJ IDEA within weeks given the company’s own “very soon” language and the fact that the RC is explicitly the final Early Access build.
- Expect JetBrains to publish, or be pressed by developers to publish, a direct feature comparison against the Red Hat/Eclipse JDT language server once the stable release ships, since side-by-side evaluation is currently left to individual developers.
- More AI coding agent vendors beyond Cursor will likely add explicit support for consuming LSP-based language servers directly, following the same logic JetBrains laid out for Cursor Agent, rather than relying solely on raw-text code understanding.
- JetBrains’ subscription-gated licensing model is likely to draw pushback from developers who expected a fully free alternative to the Microsoft Java extension pack, which could slow adoption among individual developers and open-source maintainers relative to enterprise teams already paying for IntelliJ IDEA Ultimate.
- Watch for Eclipse Foundation or community contributors to respond with performance or feature updates to the JDT Language Server, since a credible, well-marketed alternative from JetBrains creates competitive pressure even without a direct public benchmark yet.
Frequently Asked Questions
What is “Java and Kotlin by IntelliJ IDEA”?
It is an LSP-based extension from JetBrains that brings IntelliJ IDEA’s Java and Kotlin code intelligence, including completion, navigation, inspections, and refactoring, into third-party editors such as VS Code and Cursor.
When did it reach Release Candidate status?
JetBrains announced the Release Candidate on October 7, 2026, roughly two months after opening the preview on August 5, 2026.
Does it work in Cursor?
Yes. JetBrains explicitly names VS Code forks, including Cursor, as supported editors, and distributes the extension through the Open VSX Registry so Cursor and other forks can install it.
Is it free?
The Release Candidate can be used for 30 days without a license. After the stable 1.0 release, new users get a 30-day free trial, after which continued use requires an IntelliJ IDEA Ultimate subscription.
How is this different from the Java extension already in VS Code?
VS Code’s default Java support comes from Microsoft’s Extension Pack for Java, which bundles Red Hat’s Language Support for Java extension built on Eclipse JDT technology. JetBrains’ extension is a separate, alternative language-intelligence layer built on IntelliJ IDEA’s own engine rather than the Eclipse-derived one.
Can I run both the Red Hat extension and the JetBrains extension at the same time?
Technically both can be installed, but running two active Java language servers in the same workspace risks conflicting diagnostics. Most developers testing the Release Candidate disable one while evaluating the other.
What build systems does it support?
JetBrains says the extension supports Maven, Gradle, and Bazel, alongside built-in test running and Spring tooling interoperability.
When will the stable 1.0 release ship?
JetBrains has not given an exact date. The company said in its October 7 announcement that the foundation for a stable release is in place and that it will arrive “very soon,” without committing to a specific calendar date.
