JetBrains Java for VS Code Hits 1.0, and the Trial Ends in a Subscription You Should Price First

What JetBrains just shipped

JetBrains has released version 1.0 of its Java and Kotlin extension for VS Code and VS Code forks, including Cursor. The extension, called Java and Kotlin by IntelliJ IDEA, brings IntelliJ's language engine into Microsoft's editor, and the stable release was announced around October 15 and 16, 2026. For Java and Kotlin developers who left IntelliJ for VS Code, or who never wanted to leave VS Code in the first place, this is the extension they have been waiting for.

The key detail is the engine underneath. This is not a new language server written from scratch for VS Code. It is IntelliJ IDEA's language technology, repackaged as an extension. That means the refactoring, navigation, and code understanding that IntelliJ users rely on should, in theory, carry over. In practice, how much carries over, and how well it performs inside a different editor, is what developers will judge over the next few weeks.

The licensing catch, stated plainly

Here is the part to read before you install. During the preview, each build renewed a 30-day evaluation period automatically. The release candidate could be used for 30 days without a license. With the stable 1.0 release, users get a 30-day free trial, and continued use after that requires an IntelliJ IDEA Ultimate subscription.

That is not a small print trick. JetBrains has been explicit about it, and it changes the math completely. If your team already pays for IntelliJ IDEA Ultimate licenses for some developers, this extension costs those developers nothing extra. If your team deliberately avoided JetBrains subscriptions to stay on free tooling, this extension asks you to buy into the subscription stack after a month. There is no separate, cheaper tier for the extension alone. Budget for the full Ultimate subscription, or plan to switch back when the trial ends.

How it compares with the free alternative

The established free option is Microsoft's Extension Pack for Java, built on Red Hat's language server, which is derived from Eclipse JDT. It is free, open source, and good enough for a huge number of Java developers. It supports Maven, Gradle, and Bazel builds, and it uses the Debug Adapter Protocol for debugging, just like JetBrains' extension.

So why would anyone pay? The honest answer is IntelliJ's refactoring and navigation. Renaming across a large codebase, finding usages accurately, extracting methods safely, and understanding Kotlin code in particular are areas where IntelliJ has traditionally led. If your daily work involves large refactors in a big Java or Kotlin codebase, that edge can be worth a subscription. If your work is mostly writing new, smaller services and running tests, the free extension probably already does what you need, and the JetBrains extension is a luxury, not a necessity. Try both on your own codebase for a week each. That comparison is worth more than any benchmark.

What it supports, and what to test

The extension supports VS Code and VS Code forks, including Cursor, which matters because a growing number of developers work in AI-assisted forks rather than stock VS Code. It supports Maven, Gradle, and Bazel, and debugging through the Debug Adapter Protocol. That covers the build and debug basics for most Java and Kotlin teams.

What to test in your trial, in order: first, import your largest project and check indexing time and memory use. IntelliJ's engine is powerful and hungry, and a laptop that handled the free extension comfortably may struggle. Second, try a real refactor, not a toy rename, and check that it updates every usage correctly. Third, test Kotlin support specifically if you write Kotlin, because that is where the engine difference should show most. Fourth, test it inside Cursor if that is your editor, because fork compatibility can lag behind stock VS Code. Write down what breaks. A 30-day trial is only useful if you actually use it on real work.

The bigger picture for developer tools

JetBrains' move is part of a wider shift in developer tooling. Editors are becoming platforms, and language intelligence is becoming the product, not the editor itself. JetBrains is betting that developers will pay for its language engine wherever they edit, rather than only inside its own IDE. Microsoft and Red Hat are betting that a good free engine keeps developers inside VS Code's ecosystem. Both bets can be true at once, for different teams.

For developers, the practical advice is boring and correct: do not adopt a paid tool on launch-week enthusiasm. Use the trial on real code, measure what it saves you, and compare it honestly with the free tools you already have. The open-source world keeps producing strong alternatives, from OpenCode 2.0 rebuilding the coding agent around a background service, to SvelteKit 3 simplifying configuration in a way that sounds small and feels large. JetBrains' Java extension belongs in that same evaluation: try it, measure it, and only pay for it if it earns its subscription on your codebase.