JetBrains Says 1.0. The Roundup Still Says Candidate.

The stable post and the roundup are nine days apart, and they do not describe the same stage. JetBrains’ IntelliJ IDEA blog, published Thursday, October 15, 2026, at 13:06 UTC in the idea feed, says the company is announcing 1.0, the first stable release of Java and Kotlin by IntelliJ IDEA. A roundup indexed October 20 still has a table whose last row reads “Full stable release / Not yet announced / Pending JetBrains confirmation.” The confirmation was already a blog post. The table did not pick it up.

This is not JetBrains Air. Air, in the September note, is a control layer around Junie and a governance console, and it was not generally available when that piece ran. The extension in this note is a language server for Java and Kotlin inside VS Code and Cursor. Composer 2, in that Cursor note, is a different product surface. If a procurement line says “we bought Air, so the Java extension is covered,” it has merged two announcements.

JetBrains’ candidate was October 6. The stable post was October 15.

The release-candidate post is also in the feed. Andrei Kogun’s RC note is timestamped Tuesday, October 6, 2026, 09:54 UTC. It says the extension has reached release candidate, that the foundation for a stable 1.0 is in place, and that the release itself will arrive very soon. It calls that RC the final Early Access Program build, available under EAP terms for 30 days.

A writeup indexed October 18 puts the RC announcement on October 7. 09:54 UTC on October 6 is still October 6 in US time zones and still October 6 in Taipei. October 7 is a different day. The same writeup, three days after the 1.0 post, still treats 1.0 as future tense: the foundation is in place, the release will arrive very soon. That sentence is the October 6 post. It is not a description of October 18.

The October 20 table makes a different mistake. It dates the release candidate to October 15 and leaves stable as “not yet announced.” October 15 is the date on the 1.0 post, and it is the date on the package row below. It is not the date on the RC post. Collapsing the two posts onto one day deletes the candidate entirely and then claims the stable announcement never happened.

The preview is older than both. The 1.0 post says the preview opened ten weeks earlier and links the August LSP post. The October 18 writeup names August 5, 2026. The October 20 table says August 2026. Ten weeks before October 15 lands in early August. That is consistent with a preview in that month. It is not a license to print August 5 as if the October 15 post had named the day.

The package row is 1.0.27, and the counters do not match

The blog says 1.0. The registries say 1.0.27. Open VSX, checked at 17:09 UTC on October 24, returned version 1.0.27, preview false, timestamp 2026-10-15T06:59:09Z, downloadCount 19329. The Visual Studio Marketplace gallery query in the same session returned version 1.0.27, lastUpdated 2026-10-15T08:45:22Z, with install at 12470, downloadCount at 3549, updateCount at 10245, and an average rating of 5.0 from 4 ratings. The publisher id on the marketplace item is JetBrains.intellij-server. Open VSX uses JetBrains/intellij-server. Same extension name, Java and Kotlin by IntelliJ IDEA. Not the same counter.

19,329 and 3,549 and 12,470 cannot be added into one “downloads” figure. One is an Open VSX download count. One is a Marketplace download count. One is a Marketplace install count. A slide that says the extension has been downloaded 19,329 times on VS Code is using the Open VSX number on the wrong registry, or using it as if the two stores were one store. They are not. The 1.0 post tells you to install from either.

The package clock is earlier than the blog clock on the same calendar day. Open VSX’s version timestamp is 06:59 UTC. Marketplace’s newest lastUpdated in that query is 08:45 UTC. The blog pubDate is 13:06 UTC. The registry row existed before the post went out. “1.0” in the headline is the release name. “1.0.27” is the build the stores were serving when checked on October 24. A lockfile that pins 1.0 and a lockfile that pins 1.0.27 are not asking for the same string. The stores, that afternoon, had 1.0.27.

Four ratings at 5.0 is a count, not a quality case. I would not put it in a bake-off against the Red Hat Java extension. The sample is four.

Two different sentences both say 30 days

The October 6 post says the RC remains available under EAP terms for 30 days. The October 15 post says something else: with 1.0, the extension moves out of its free preview, and using it requires an IntelliJ IDEA Ultimate subscription after a 30-day trial of the full feature set. The same license, that post says, covers the desktop IDE, VS Code-based editors such as Cursor, and other supported environments. It links a pricing page. Do not invent one from a roundup.

The October 18 writeup mixes the clocks. It says the RC can be used for 30 days without a license, and that after stable 1.0 new users get a 30-day trial, then Ultimate. The second half matches the October 15 post. The first half matches the October 6 EAP sentence. They are sequential, not simultaneous. By October 18 the stable post was already three days old. A team that starts a trial on October 24 is on the 1.0 sentence, not on a candidate that a roundup still thinks is the current build.

There is a third license sentence, and it is the one easy to skip. The 1.0 post says the license is explicitly designed for human use, and that an update on licensing models for purely agentic use will come later. “Later” is not a SKU. If the plan is to run the language server only from an unattended agent, the post does not say the Ultimate seat already covers that. It says an update is coming. Cursor’s own agent surface is not the license.

The Agents Window is not “agents call the LSP”

What 1.0 does ship, for Cursor, is dedicated support for the Agents Window. The post says that window may use its own instance of the language server, including nullability support with JSpecify and Spring Framework specifics. That is editor-side analysis while a person is in that window.

The next paragraph is future tense. In one of the next releases, agents orchestrated in the Agents view in Cursor or VS Code will also be able to call the LSP directly when writing code. “Will be able” is not “can, as of 1.0.” A design doc that says the extension already cuts token use because agents call the server is quoting the motivation section, not the shipping section. The motivation section does say agents can call an LSP and use fewer tokens. The shipping section says that direct call, for agents in the Agents view, is a later release.

Terminal agents are a third bucket. The post says JetBrains has been running experiments applying the same LSP and debug-adapter stack to Claude Code or Codex, and that news will be announced soon. An experiment is not an install step. There is no flag in this post for “point Codex at intellij-server.”

The quote on the page is from Rohan Shah, Product, SpaceX AI: developers get IntelliJ IDEA’s code analysis, navigation, and refactoring while they work with Cursor’s agents. The attribution line says SpaceX AI, not “Cursor CEO” and not a job title at JetBrains. Use the line as printed. It does not say the agent license question is settled. The license note further down says it is not.

JUnit is the test runner. The other Java extensions should be off.

The 1.0 capability list is a focused set, the post’s words: Java, Kotlin, and mixed-language projects; completion, navigation, and analysis; refactorings and editor assistance; Maven, Gradle, and Bazel; a claim of speed on large projects and monorepos; test runners, right now, for JUnit; debugging, including emulated breakpoints and async stack traces. “Right now for JUnit” means other test runners are not in that sentence. A checklist that says TestNG is covered because “test runners” is plural has ignored the qualifier.

The full list is deferred to the docs. This review does not pretend the blog bullets are exhaustive. It does treat them as the list the announcement was willing to print.

Compatibility is a practical line, not a slogan. The extension’s analysis and quick-fixes overlap Red Hat’s and Oracle’s Java extensions. JetBrains recommends disabling those while using this one. It says the extension works with Spring Tools from the Spring team. Disable is the instruction for the overlapping Java packs. It is not the instruction for Spring Tools. Leaving both Java engines on is how you get duplicate inspections and then blame the language for a fight between plugins.

The October 20 roundup says JetBrains confirmed Visual Studio Code, Cursor, and Google Antigravity. The October 15 post names VS Code and Cursor, and says the same license covers VS Code-based editors like Cursor and other supported environments. Antigravity is not named. I am not declaring it unsupported. I am saying the stable post does not confirm that name, and a roundup that says JetBrains confirmed it is ahead of the post I am reading.

Neither post says the extension replaces IntelliJ IDEA. The 1.0 announcement calls it a focused set of capabilities powered by the same language technology as the desktop IDE. The roundup’s “this does not replace the IDE” is compatible with that. It is not news. The news is the stage: stable, paid after a trial, human-license note attached, agent call still pending.

What to put on the install note

Write October 6 for the candidate and October 15 for the stable post, both UTC from the feed. Ignore a table that puts the candidate on October 15 and the stable release in the future. Pin the extension id, JetBrains.intellij-server, and the build you actually installed. On October 24 at 17:09 UTC that build was 1.0.27 on Open VSX, preview false. Do not add Open VSX’s 19,329 downloads to Marketplace’s 3,549 downloads or to its 12,470 installs.

Write the trial as 30 days of the full set, then an IntelliJ IDEA Ultimate subscription, same seat as the desktop IDE, dollar amount unread here. Write the agent-license line as “not this seat, update later.” Write Agents Window support as shipped, direct LSP calls from agents in the Agents view as a later release, and Claude Code or Codex as an experiment with no install step in the post.

Turn off the other Java language extensions. Leave Spring Tools if you use them. Expect JUnit in the test-runner sentence, and do not expand it. Then open a real project. The announcement’s speed claim on monorepos is a claim. Your repo is the test.