Let’s go!

Featured Content

Piotr Przybył

Piotr Przybył  – Notorious engineer at work and after hours, tracing the meanders of the art of software engineering. Remote Software Gardener, mostly working in web-oriented Java gardens. Java Champion. Docker Captain. Testcontainers Champion. Programming usually in Java (since 1.3), Scala, and Go, but in other languages too. Fan of agility, seen mostly as choosing the right tools and approaches after asking the right questions. Developer, trainer, and conference speaker, currently working at Elastic as a Senior Developer Advocate.

Greetings, fellow Java developers! It’s a pleasure to be here again – it’s been three Java releases since the last time. We all know that means roughly 18 months, don’t we? ;-)
Both the world and our ecosystem were moving fast back then, and it seems they have only accelerated. This means one thing: good luck trying to keep up to date with everything. Luckily for us all, newsletters like this one help.

The autumn conference season of 2026 is slowing down. It was a busy and exciting one, for me in particular, because Java 28 is already shaping up. And if you look at the list of JEPs already there, how can you not be excited? Structured Concurrency is set to become final in March 2027, yay! Bye-bye, CompletableFuture, it was fun knowing you… not ;-). CF isn’t going anywhere, but it won’t be the best abstraction for concurrent subtasks. 
Apart from that, there’s going to be one less thing for me to rant about, because Java is going to have (for now as an incubator module) a Simple JSON API. If your microservice only has to send one simple REST request with a JSON body, maybe this plus the JDK’s HTTP client will be enough? You can learn about it from Dan Vega.
There are going to be improvements to GCs and more performance goodies, but my personal favourite is going to be Value Objects, because 42 is always 42, and it shouldn’t need an identity crisis to answer everything. I believe VOs will change the way we think about and work with data in Java. The need for this improvement is already here, because AI, like it or not, also means exchanging an awful lot of tokens and vectors.

To give you a taste of that, the following code yields different results on a default HotSpot configuration, with and without the value-object preview enabled:

Integer x = 1024, y = 1024; IO.println(x == y)

Intrigued? For more, please check out my post Java isn’t dead yet, but it can’t avoid Valhalla.

You may say, “Okay, but these are preview features or incubator modules; they can’t be used in production.” That’s not a blanket rule, although compatibility and support deserve a closer look. Sometimes even a non-GA feature of Java can be mature and worthwhile enough for you to make it a part of your library and code. I’m talking about the Vector API already being used in Lucene and Elasticsearch, and you can learn more about how it powers semantic search in them in one of my recent talks. If you prefer reading about SIMD, Krzysztof Ślusarski has you covered with this post.

I could go on and on about the exciting stuff in recent and upcoming Java releases. Marit van Dijk and I weren’t quite able to curb our enthusiasm for them, as can be seen in  this three-hour-long deep dive from Devoxx Belgium 😅. (We simply forgot to take a break, sorry!)
If you can spare just one hour, here’s a shorter and more compact version from Hello Stavanger.

A big congrats to Marit, my partner on stage, for becoming the most ubiquitous Java speaker for 2026!

Java News

Catch up on the latest updates: 

• Java News Roundup 1, 2, 3, 4 
• OpenJDK Bug Fixing, JavaOne, and JDK 28 – Inside Java Newscast #116
• JavaFX Links of October 2026
• Foojay Podcast #104: 53 CVEs, Two Emergency Releases: Why Java Security Holds Up with Simon Ritter
• JDK 27 G1/Parallel/Serial GC changes
• Allocating Off-Heap Memory: Typically 6-18x Faster in JDK 28
• eMudhra Intermediate CA Compromise
• Distrusting Compromised eMudhra Intermediates in Java
• Episode 72 “OpenJDK Bug Fixing, JavaOne, and JDK 28” [IJN]

Some JEPs to pay attention to: 

• JEP 544: Ahead-of-Time Code Compilation
• JEP 543: Structured Concurrency
• JEP 543 Finalizes Structured Concurrency in JDK 28, Ending Seven Preview Rounds
• JEP 546: Adaptive Heap Sizing for ZGC
• JEP 545: Faster Startup and Warmup with ZGC
• JEP 542: PEM Encodings of Cryptographic Objects
• JEP 540: Simple JSON API (Incubator)
• Quality Outreach Heads-up – JDK 28: Value Classes

Java Tutorials and Tips

Practical guides, clever shortcuts, and fresh ideas to help you understand Java better: 

• Java Secure Coding Guidelines
• Episode 73 “Immutable Data Beyond Value Classes”
• What’s Going Wrong with My JVM?! A Guide to First-Time Failure Diagnosis
• Reflect, Transform, Accelerate: Bringing GPU Computing to Java
• Modern Java – Past | Present | Future
• Foojay Podcast #103: Killing Reflection at Build Time with Dmitry Moskalyuk and Shai Almog
• Everyday JSON in Java
• Structured Concurrency Looms
• Java – The Year of the Runtime!
• Learning modern Java the playful way – Piotr Przybyl, Marit van Dijk – HelloStavanger 2026
• Bootiful podcasts you don’t want to miss:
  • ‘Data Geekery’ with JOOQ creator Lukas Eder
  • Can Java be more performant than Rust? Andrew Lombardi has the numbers
  • Legendary Java developer Kohsuke Kawaguchi
  • JReleaser creator and fellow Java Champion Andres Almiray

• IntelliJ IDEA Tech Talks: Playlist
• IntelliJ IDEA Conf 2026: Playlist 

• Optimizing nanosecond operations: when the CPU cache matters
• Batch Processing with MongoDB and Jakarta EE: From Customer Segmentation to Scalable Workflows
• Stop Writing Database Migration Scripts: Declarative Schema Sync for Java
• The Maven Build Cache in Practice
• JVM on Unikernel Nanos – GC trade-offs and heap uncommit
• Free Java, Real Risk: Why Unsupported OpenJDK Is Now a Security Gamble
• Searching Kafka Without an Index: Lessons From Building Message Search for Kafdrop
• What jstack Misses When Your Java Service Uses Virtual Threads
• New Java Features Are Not Just for Interviews. Two Real-World Use Cases from Axelix
• Exact Prices in Java: Decimal Strings and BigDecimal Traps
• Java Stream Gatherers: From Built-in Patterns to Custom Pipeline Mechanics
• Java Virtual Threads Under Load: Three Production Limits
• Upgrading from Java 21 to 25: What Actually Breaks
• Complex Event Processing (CEP) With Apache Flink: What It Is and When (Not) to Use It
• How Hard Is It to Check for Whitespace?
• Going All In On the JVM 25 Virtual Threads
• Introduction to Error Prone: How to Catch Bugs at Compile Time
• Building High-Performance Time-Series Applications With Java and QuestDB 

Kotlin Corner

Explore what’s new in Kotlin, sharpen your skills, and put your knowledge into practice:

• Kodee’s Kotlin Roundup: Shipaton 2026 Winners, Kotlin 2.5.0-Beta2, and KotlinConf 2027
• The State of Kotlin in 2026 Report
• The Companions to Come
• Kotlin Developer Survey 2026
• KotlinConf 2027 is coming to Kraków
• Testing Java and Spring Applications With Kotlin: Low-Risk to Adoption
• Why Kotlin or Java Is the Wrong Question For Enterprises
• Google Summer of Code 2026 With the Kotlin Foundation: Recap
• What Makes a Great KotlinConf Proposal?
• Instagram Modernized Its UI with an AI-Native Architecture, Cutting Token Costs by 33%
• KotlinConf Recap: Lessons from Verifone’s Architect on Kotlin in Mission-Critical Payments
• Start Your Next KMP App With Kotlin Toolchain 0.13
• Discontinuing Swift Language IDE Support in the Kotlin Multiplatform Plugin

AI

Discover smarter AI workflows and see how they reshape development – this month with a healthy dose of reality checks:

• Part 4: Multi-Agent Orchestration – Pairing Goose With Quarkus Flow State Machines
• Spring Office Hours Podcast: S5E27 – Hugging Face for Java Developers with Pratik Patel
• Tachyon MCP 1.0
• How Not to Use AI for Pull Requests and Code Changes
• How three Java Champions put GitHub Copilot to work
• How Does Java Fit Into the World of AI – and How Can It Become an Even Better Fit?
• How Netflix Made AI Coding Agents More Efficient with JetBrains IDE Intelligence
• What I Learned Building an AI Code Reviewer with Java and Spring Boot
• One Embedding per Job, or Two? Measuring Semantic Search in a Spring Boot Job Portal
• Your agents don’t need an LLM to negotiate
• How to Create Agent Skills: Tools, Testing, and Installation

• Systemic Approach to Memory, Knowledge, and Context in Agentic AI Architectures
• Anthropic Says Nobody Needs a Mental Model of Claude Code. Practitioners Are Testing That
• Developers Reporting Double-Digit Weekly Time Savings From AI Fell From 68% to 26%
• Study Finds AI-generated Code Fails to Boost Productivity Due to Downstream Bottlenecks
• Actors for Agents: Patterns for Production AI
• AI is an Amplifier: Scale High Performance, Not Dysfunction
• From Microservices to Agents: The Next Evolution of Distributed Systems

Languages, Frameworks, Libraries, and Technologies

Look beyond Java, Kotlin, and AI. There’s more happening across development:

• This Week in Spring 1, 2, 3, 4
• Distributed Spring Batch Without a Message Broker
• Spring Office Hours Podcast: S5E26 – dev2Next, Native JSON and a Week of New Models
• Spring Office Hours Podcast: S5E25 – Future of Software Development with Josh Long
• AI Agents Are Disrupting Open Source Security Disclosure

Conferences and Events

Plan your education sessions and networking, both online and offline:

• W-Jax – Online or Munich, Germany, November 2–6
• Øredev – Malmö, Sweden, November 4–6
• Devoxx Morocco – Casablanca, Morocco, November 4–5
• JConf Guatemala – Guatemala City, Guatemala, November 7
• JFall – Pathé Ede, Netherlands, November 6
• Voxxed Days Thesalloniki – Thesalloniki, Greece, November 7–8
• JavaFest India – Bengaluru, India, November 8
• JFall – Pathé Ede, Netherlands, November 11–12
• ChurConf – Sydney, Australia, November 18
• Voxxed Days Thessaloniki – Thessaloniki, Greece, November 20–21
• JavaDays Czech Republic – Online or Prague, Czech Republic, November 25–26

Culture and Community\

Find articles on developer life, career growth, and how engineers keep learning to survive with AI:

• Educating an Architect: A Conversation with Luca Mezzalira
• The Ladder Is Missing Rungs: Engineering Progression When AI Ate the Middle
• How to Make Artificial Intelligence More Environmentally Sustainable
• Member Spotlight: Shai Almog
• Optimizing Software Workflow: Exploring Fundamental Impacts in Technology
• You Can’t Trust Your AI Bill. And Neither Can I
• What Does It Really Mean To Program With AI: A Conversation with Joy Ebertz
• The Minimum Viable Manager: Building Trust, Feedback, and Alignment
• How to Develop Software Engineering Skills in the Age of AI

And Finally…

Check out what’s new from the IntelliJ IDEA blog in October:

• What’s New in IntelliJ IDEA 2026.3
• What’s fixed in IntelliJ IDEA 2026.3
• JetBrains Air: Building a System of Products for Agentic Software Development
• A New Agentic Experience: JetBrains Air in IDEs – EAP Now Open
• IntelliJ IDEA’s Java and Kotlin for Cursor and VS Code Hits 1.0
• Compromised eMudhra Certificates: Update Your JetBrains IDEs, ReSharper, .NET Tools, Toolbox App, and Gateway Now
• Your Next Action Is Two Dots Away
• Where Did the Saved Bytes Go? Compact Object Headers in IntelliJ IDEA

That’s it for today! We’re always collecting ideas for the next Java Annotated Monthly – send us your suggestions via email or X by November 20. Remember to check out our archive of past JAM issues for any articles you might have missed!

This version brings you Air, as well as an extension for Cursor and VS Code, debugging improvements, and support for the latest technologies in the Java ecosystem.

You can download the latest release from our website or update to it directly from inside the IDE, via the free Toolbox App, or using snap packages for Ubuntu.

As always, the complete list of key updates and demos is collected on our What’s New page. Make sure to explore it!

Explore the What’s New page

In addition, our developer advocates gathered to record a walkthrough video covering all the most exciting features in the latest release.

Here are the key highlights of this release:

• JetBrains Air – a new layer for agentic development
• IntelliJ IDEA’s Java and Kotlin for Cursor and VS Code extension
• Debugging improvements:
  • ij-debugger agent skill
  • Hibernate debugger
  • Spring Security diagnostics in HTTP responses
  • Spring cache support in Spring Debugger [coming 2026.3.1]
  • AppGlass
• Support for the latest technologies:
  • Java 28
  • Jakarta Persistence 4 and Hibernate 8 support
  • Scala updates
  • Kotlin support for Spring Modulith
• Quick tasks and edits without opening a project
• Git worktrees for parallel work and easy code reviews

Version 2026.3 also brings a wide range of stability, performance, and usability improvements across the platform. You can find the full details in our dedicated What’s Fixed blog post.

We’d love to hear what you think about the new features in this release. Your feedback helps us continue improving IntelliJ IDEA so it works even better for you.

Update to IntelliJ IDEA 2026.3 to explore all the new features. You can also join us on X, Bluesky, or LinkedIn and share your favorite updates with us.

IntelliJ IDEA 2026.3 ships over 1,000 bug fixes and over 300 performance fixes. We focused on performance, Java and Kotlin code intelligence, and the core workflows that matter for both classic and agentic development. User reports and data shared through automatic submission drive most of this work. Below is a recap of the most impactful updates.

Performance

Freezes, CPU usage, and memory were the focus of this release. Many of these fixes came from freeze reports and profiling of real projects, and others came from your tickets.

Fewer UI freezes

We removed UI freezes in the places where they were reported most often. Among others, Spring Boot inlay hints, property highlighting, and JPA entity analysis no longer stall the editor. Tomcat, WildFly, and JBoss no longer read configuration files on the UI thread. The same goes for the debugger’s variable building, the Git Commit and Changes trees, Optimize Imports, and Java SDK setup.

Indexing, memory, and CPU

Indexing is lighter on large projects. We removed excessive index updates when a second project closes during indexing and made the workspace model copy files lazily.

Launching the IDE no longer starts WSL when you do not need it.

The IDE also uses less memory. A code lens preview no longer keeps HiDPI images alive on the heap, and the JPA model no longer creates a new cache key on every lookup. Several leaks that kept closed projects in memory are fixed.

Project import

Importing large Maven and Gradle projects got optimization fixes. A deadlock during import on a remote development host is gone. A five-minute import of the Kotlin repository with Gradle 9.7 no longer spends most of its time processing errors after Gradle has finished.

Automatic error and freeze reporting

To find the problems that interrupt your work and fix them in order of impact, IntelliJ IDEA 2026.3 sends error and UI freeze reports to JetBrains automatically. Reports contain technical data only. File paths, URLs, and usernames are removed before anything leaves your machine. You can turn reporting off in Settings | Appearance & Behavior | System Settings | Data Sharing.

Java

JaCoCo is now the default coverage runner for new Java run configurations. It is the runner Gradle, Maven, CI systems, and SonarQube already use, so coverage numbers in the IDE match the ones in your pipeline.

The Unused declaration inspection now reports methods that are used only from test sources.

Quick fixes for the “might be null” inspection work on complex expressions, Rename stops suggesting the current name, and generic stream-to-list conversions no longer show a false compilation error.

Kotlin

A new inspection warns when CancellationException is caught in suspending code and not rethrown, and offers a quick fix. Blocking calls are highlighted in suspend lambdas, and converting Java to Kotlin now turns @lombok.Data classes into data classes.

Spring

There are hundreds of fixes for different aspects of Spring Framework support:

Profiles: Profile switching moved from an editor banner to a status bar widget, and the IDE finds more profiles, including test-scope ones. The empty popup and the stale widget icon are fixed.

Configuration properties: Find Usages on a ${…} placeholder first lists the key’s declaration and then all its usages. YAML placeholders resolve to keys with empty values. Editing config files no longer freezes the IDE.

Spring Data: Repository method completion is reworked: inherited methods come first, there is no wrong import, and Kotlin named queries are recognized.

Spring Cache: SpEL and meta-annotation handling is more accurate, with no false “missing cache name” warning for meta-annotations and Kotlin support in the cacheable components inspection.

Spring Modulith: allowedDependencies with String constants, additionalPackages, and @PackageInfo are read correctly, and violations are reported again.

Spring Debugger: About 20 fixes, mostly in bean presentation: FactoryBean<T> factories, init and destroy methods, and the security inlay.

Spring Web: Endpoint detection and URL references improved for Kotlin and Spring Boot 4, including companion-function routes and no false nullability warning for JSpecify parameters.

Spring Core and Spring Boot: 13 fixes, including Spring XML imports without a classpath prefix and from modules without the resource on their classpath, and import registration navigation for inner classes.

JPA and Hibernate: About 40 fixes, half of them performance problems. The JPA Console returns correct date values, @MapKeyJoinColumn resolves on @ManyToMany, and Generate DDL no longer loads forever.

Flyway and Liquibase: 22 fixes. Flyway Init and Diff work again, Liquibase validation errors are displayed, and Liquibase XML no longer causes high CPU use.

JPA Buddy: @OnDelete SQL generation works reliably, and the JPA Designer freeze and a slow Map To dialog are fixed.

Debugger

HotSwap

The debugger now suggests HotSwap only where it can work. Some edits cannot be reloaded by the JVM, such as changes to a class structure, a method or field signature, or the inheritance. For these Java and Kotlin edits, the IDE offers a restart instead. Spring and other scenarios where reloading works differently keep the previous behavior.

Virtual threads and tests

The thread dump now includes virtual threads, mounted and unmounted, in a single dump. You can rerun tests that failed in @BeforeAll, and the Stream Debugger shows an inline hint when the debugger pauses at a stream chain.

Debugging in WSL

Debugging in WSL is more reliable. The debugger no longer blocks the application in WSL2 mirrored network mode, gets stuck while attaching, or disconnects after the first breakpoint. Gradle tests in WSL also no longer hang.

Build tools

Maven and Gradle got many fixes. The most voted topic is Maven delegation.

With Delegate IDE build/run action to Maven enabled, every build, rebuild, and compile ran mvn install, which is usually not the desired behavior. And the presentation of the output was not the same as with the IntelliJ IDEA runner. We fixed both, and delegated builds now run the process-test-classes phase by default.

Running main() from the gutter now works with Gradle 9.7 Isolated Projects.

Scala

Scala 3

The Scala plugin now supports Scala 3.10. Scala 3 code analysis is more accurate, with fewer false errors around overloaded extension methods and inferred collection types. Completion also distinguishes extension methods more clearly and shows fewer duplicate suggestions.

Twirl

We’ve rewritten Twirl support for Play Framework to make editing and refactoring templates more reliable. Parsing, completion, formatting, and Find Usages have all improved, and template renaming updates references more consistently.

sbt

sbt 2.x projects import more reliably, while build scripts show fewer false errors around .value and / expressions. We’ve also addressed slow imports with Scala 3.8 and a BSP import performance regression.

Debugger

Debugger fixes remove interruptions caused by UI freezes during expression completion and watch evaluation. Breakpoints now stop execution as expected in Future callbacks and for comprehensions inside Scala 3 top-level methods.

Compiler-based highlighting

Compiler-based highlighting now uses fewer resources by reusing diagnostics, combining file checks, and avoiding unnecessary compilation retries. BSP checks and diagnostics after edits or cancellation are more reliable, and the editor explains blocked highlighting with links to the errors responsible. Further fixes span Scala CLI scripts and shebang syntax, dependency completion, formatting and Scalafmt integration, and incremental compilation after macro changes.

Markdown

Markdown received more fixes than almost any other area, so editing specifications and documentation is smoother. Absolute path links in the preview open the file, and a new setting, Strip trailing spaces in Markdown files on save, keeps whitespace out of your documents. GitHub wiki links and images embedded as base64 work in the preview. Breadcrumbs show the heading path, and you can exclude headings from a generated table of contents.

Terminal

The terminal got the ghostty emulator, and over 40 fixes on top of it. Among others, working with tabs was reworked, multiline URLs and file paths are handled better and more reliably.

User interface

New Plugin management UI

We’ve merged the Installed and Marketplace tabs into a single view, so one search box now finds plugins whether they’re already installed, bundled with the IDE, or available on JetBrains Marketplace. Results are grouped into clear Installed, Bundled, and Suggested sections that you can expand as needed, so you no longer have to switch tabs to find what you’re looking for.

The Plugins page also opens in its own window, which leaves more room for plugin descriptions, screenshots, and release notes. Simple on/off toggles and a less crowded layout give it a cleaner look.

Vertical tool window names and new layouts

The newly released Extended Tool Windows UI plugin adds vertical names beside tool window icons, keeping labels visible without taking extra width from the editor. You can also arrange tool window buttons in horizontal rows along the top or bottom edge and anchor tool windows in the upper-left or upper-right corners.

Reorder status bar widgets

Status bar widgets are now movable, and indentation settings, memory indicator, or inspection widget can sit where you look first. Drag widgets into your preferred order and hide the ones you don’t need. The IDE saves your layout between sessions.

Git

Git worktrees

Git worktrees are the most requested fix of this release. Worktrees now work in multi-root projects, and you can also open a merge request in a separate worktree.

Stash and remote development

You can include untracked and ignored files when you stash. In remote development, Open Diff as Editor Tab now behaves as it does in a local IDE.

GitLab connections with OAuth

Connect your GitLab account to your JetBrains IDE by signing in through your browser, without creating and pasting a personal access token. OAuth works with GitLab.com and custom GitLab instances, and you can use the connected account for merge requests and Git operations over HTTPS.

Git SHA-256 repositories

JetBrains IDEs now handle the 64-character object IDs used in Git SHA-256 repositories. The fixes cover Git Log filtering and navigation, file history, interactive rebase, and commit-editing actions.

Other improvements

SSH

JetBrains IDEs now use OpenSSH for SSH connections. This adds support for certificate-based authentication, hardware security tokens such as YubiKey, Kerberos SSPI, X11 forwarding, and ProxyJump, along with a broader range of SSH agents and wrappers.

Remote JSON schemas now download without a VFS error.

MCP server port is configurable in settings.

Deprecated plugins

In 2026.3, we deprecated several less frequently used Big Data Tools plugins: Big Data File Viewer, Metastore Core, Flink, Big Data Tools, Spark, Zeppelin, and Databricks. These plugins are now considered obsolete and no longer maintained.

The source code for the plugins is available in the Obsolete Plugins repository repository, where you can build and install them manually.

The Big Data Tools Core and Remote File Systems plugins remain supported and are compatible with 2026.3.

That’s it

That’s it for this overview. Let us know which fixes matter most to you and where you still see friction. Update to IntelliJ IDEA 2026.3 and share your favorite updates with us on X, Bluesky, or LinkedIn.

Thank you for using IntelliJ IDEA!

Synthetic benchmarks frequently demonstrate smaller object footprints, but what does this change actually deliver for a massive, real-world JVM application? We evaluated the impact directly inside IntelliJ IDEA.

What are compact headers?

Every Java object carries a header. It identifies the object’s class and holds or encodes state used for locking, identity hashing, and garbage collection. Because every instance incurs this tax, shrinking the header represents an attractive target for memory optimization.

In the 64-bit HotSpot configuration we tested, a conventional instance header takes 12 bytes: an 8-byte mark word and a 4-byte class pointer. The compact layout compresses both into a single 8-byte word.

Does that translate to an immediate 10%–20% reduction in total application memory? Not necessarily. Below, we trace the impact of compact headers from raw object layouts and heap dumps through to resident process memory and interactive IDE workloads, highlighting where the savings materialize and where they vanish.

How we tested compact headers in IntelliJ IDEA

We measured three configurations with escalating resource demands:

• No project (only the Welcome screen open).
• Small project: Spring Petclinic, with about 3,370 Java/Kotlin lines of code.
• Large project: IntelliJ IDEA monorepo, with about 26.5 million lines of code.

The codebase sizes differ by nearly four orders of magnitude, providing substantially different indexing profiles and memory footprints. For both project configurations, we ran an automated script that repeatedly opened Java source files, inserted and removed comments, resolved code references, saved changes, and closed the editor.

We used IntelliJ IDEA 2026.2.3 running on JBR 25.0.4 (the Java runtime used by JetBrains IDEs), explicitly switching compact headers on and off. Within each on/off comparison, the build, project snapshot, workload, and -Xmx values stayed the same. We ran multiple runs per configuration on an otherwise idle host, alternating the on/off execution order to minimize cache-warming and ordering bias.

Resident set size (RSS)

Let’s start with the primary metric users tend to notice when a process looks large: its RSS (resident set size).

RSS counts the physical RAM pages mapped to a process. This includes private memory pages and shared memory pages, such as dynamic libraries. Because shared pages count toward every process mapping them, RSS does not represent the amount of RAM exclusively held by the IDE.

We sampled the main IDE process using the ps command. The table below lists the mean of three per-run phase medians in MiB, with the lowest and highest run medians given in brackets.

Verdict: At identical -Xmx limits, compact headers produced no statistically significant or consistent reduction in overall RSS.

Does this imply that compact headers yielded no practical benefit? To answer that, we need to look inside the heap and find out how compact headers actually work, rather than assuming an across-the-board drop in process memory.

Measuring object footprints

Process RSS encompasses much more than live Java heap objects. Resident pages can include unallocated headroom inside the committed heap, class metadata, JIT-compiled code, thread stacks, native buffers and JVM data structures, shared libraries, and other memory-mapped files. Reducing object headers alone, therefore, might not necessarily lower the process’s  RSS by a matching number of bytes (if it makes a visible change at all).

To isolate the structural savings, we compared the object footprint – how many bytes the same set of captured objects would occupy under each header layout model.

For your projects, you can explore this directly in IntelliJ IDEA. Its memory dump shows instance counts, shallow sizes, and retained sizes by class, so you can see what occupies the heap. As of the 2026.3 EAP, it also offers compact-header-aware estimates using JOL’s layout models.

The table below contrasts the modeled footprints for identical captured heaps.

Here, the savings are visible: The fixed-population model reduces the Welcome and Petclinic objects by about 6.3%, and the monorepo objects by 8.2%–8.4%. While system-level RSS obscured the effect, the memory savings within the heap are real.

Why the win is not fixed

Why doesn’t removing 4 bytes from the header translate to a uniform 4-byte saving for every single object? Because two heaps of the same size can contain very different objects, and the header is only one of the variables at play.

An instance also stores primitive fields and references. An array stores its length and element data. Their number, type, and reference width all affect an object’s overall size. In our comparison, field types and reference width stay the same, but changing the header can move field offsets and alter padding. Here’s how that works:

HotSpot rounds each object’s shallow size up to a multiple of eight bytes by default. That can absorb the four-byte header reduction: An object with one int stays 16 bytes in either layout (12 + 4 bytes, or 8 + 4 bytes plus 4 bytes of padding). An empty Object, by contrast, shrinks from 16 to 8 bytes; one with two int fields shrinks from 24 to 16 bytes, as illustrated in the image below:

There can also be padding inside an object. Fields have their own alignment requirements; they do not all start on eight-byte boundaries. In the HotSpot layout modeled here, ordinary field offsets follow their storage width: one byte for byte/boolean, two for short/char, four for int/float and compressed references, and eight for long/double. That is separate from rounding the whole object to an eight-byte size, and it is not a Java-language guarantee.

Let’s look at Long.value. After a 12-byte header, its eight-byte field starts at offset 16, leaving a four-byte gap. After an eight-byte header, it can start at offset 8. The whole object shrinks from 24 to 16 bytes. HotSpot can pack or reorder fields, so the exact offsets still depend on the class and the JVM’s layout rules.

Arrays show the same pattern: byte[0] stays 16 bytes, while byte[1] shrinks from 24 to 16 bytes. When a heap contains millions of different shapes, its total saving depends on that mix, not just the object count.

We checked these examples against actual shallow sizes with Instrumentation.getObjectSize on the same JBR, with compact headers explicitly off and on. A shallow size counts the object’s header, fields, and padding, but not any objects reached through its references. We also verified compressed references and alignment. Here is what JBR 25.0.4 reported:

The takeaway from the table is simple: A smaller header does not make every object smaller. Total heap reduction depends entirely on an application’s object population profile.

Practical wins: Allocation, GC, and throughput

Even if the process’s RSS does not decline at a fixed -Xmx, does reduced object size benefit the runtime elsewhere? We looked for four effects:

• Does the same workflow allocate fewer total megabytes?
• Does the garbage collector run less often or consume fewer cycles?
• Do scripted IDE operations become faster as the result of the changes above or effects like better CPU cache locality?
• Can the application execute reliably under a smaller -Xmx?

For the first three questions, we compared headers off and on at the same -Xmx: 2,048 MiB for Petclinic and 4,096 MiB for the monorepo.

Did JVM allocate fewer bytes?

For each project, our benchmark script repeated the same sequence of operations: opening a Java file, inserting and removing a comment, resolving references, saving, and closing the editor. That includes concurrent background and probe work, so it is not an allocation summary for the edits in isolation.

If you want to analyze allocation hotspots in your own code, IntelliJ IDEA’s Memory Allocations profiler tracks call paths and timelines. Like IntelliJ IDEA’s heap dump tool, it natively models compact object headers, so you can expect true numbers for your application, regardless of your target JVM version.

Under identical workloads, compact headers eliminated 8.8% to 13.0% of total allocated volume.

Did the garbage collector have less to do?

Lower allocation volume could mean less work for the garbage collector. We compared the JVM’s GC counts and elapsed collection time during project opening/indexing, followed by GC pause times during scripted operations.

During monorepo opening/indexing, every compact-header run recorded fewer GC events than the conventional-header runs. Mean GC elapsed time and recorded GC CPU were lower in these comparisons, too.

Did IDE work speed up?

This is ultimately the question developers care about most. For the same operations, we compared their total time, their 95th-percentile operation latency, and process-wide CPU utilization.

The performance numbers trend slightly positive, suggesting a modest speedup.

How low can -Xmx go?

If compact headers pack more instances into the same heap volume, how far can we drop -Xmx before workloads fail? 

We stepped -Xmx downward until the indexing and editor scenarios could not completely reliably. A pass meant that the short scenario finished, even if it became slow.

The table below shows the lowest tested settings that completed every repeat for each project and header layout.

Note: These represent the boundary thresholds where test workloads consistently completed – not suggested production configurations.

For Petclinic, compact headers allowed us to lower the minimum viable heap from 400 MiB to 376 MiB (a 6% reduction). For the monorepo, the minimum ceiling dropped from 1,888 MiB down to 1,568 MiB – a 320 MiB (17%) saving.

Conclusion

Upgrades that make existing applications more efficient without requiring a single line of application code are rare. Compact object headers achieve this by reducing a memory tax paid by millions of objects. Alongside improvements to startup and garbage collection, they are part of Java’s broader work on runtime efficiency – strengthening the JVM at a time when we’re generating more code than ever.

When you adopt compact headers in your own applications, the actual benefit will depend on your mix of objects and their alignment. Many objects will take up less space, which often translates into lower allocation churn, reduced GC pressure, and a smaller viable heap ceiling. However, it does not guarantee an immediate, matching drop in process RSS or faster execution across the board. Measure those metrics separately, and don’t lower your -Xmx just because headers are supposed to be smaller.

You may already be using the feature in IntelliJ IDEA. The IntelliJ Platform change arrived in 2026.2, and Java 27 enables company headers by default. That removes any manual configuration as soon as you migrate to the new Java version – which is well worth doing, given how much runtime work has landed recently.

What would you like us to explore next? Are you interested in more articles on Java performance, newer Java features, or both? Let us know in the comments!

The latest update brings the following improvements:

• Files and directories in WSL projects no longer incorrectly appear as deleted or missing when file system prefetching fails. [IJPL-252022]
• The Java onboarding tour now ensures smooth progression through its lessons. [IJPL-250871]
• Import optimization now works as expected without affecting IDE responsiveness during code formatting, saving, or committing changes. [IJPL-249060]
• The IDE starts up reliably even if the plugin cache file contains invalid data. [IJPL-250688]

For a comprehensive overview of the fixes, see the release notes. If you spot any issues, let us know via the issue tracker.

Happy developing!

• The private keys of eight eMudhra intermediate certificates were compromised. A network attacker could use them to impersonate websites and services that JetBrains tools connect to.
• JetBrains IDEs, the Toolbox App, Gateway, and ReSharper are affected because they use the trust store of the bundled JetBrains Runtime (JBR). For IDEs, the embedded browser (JCEF) is also affected. Operating system updates don’t protect against this issue. 
• The Toolbox App and JetBrains IDEs use a background service, jetbrainsd. It has its own built-in list of trusted certificates and is fixed separately, in jetbrainsd 0.9.9728.
• At the time of publishing, we are not aware of any exploitation of this issue against JetBrains users.

Available fixed versions

The issue is fixed in the following versions:

• IntelliJ IDEA: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.4.
• PyCharm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• PhpStorm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• RubyMine: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• WebStorm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• Rider: 2026.3 EAP 9, 2026.2.4, 2026.1.5.3, 2025.3.5.3.
• CLion: 2026.3 RC, 2026.2.4.1, 2026.1.5.2, 2025.3.6.3, 2025.2.6.3.
• DataSpell: 2026.1.3.1, 2025.3.3.1, 2025.2.4.1.
• DataGrip: 2026.3 RC, 2026.2.6.1, 2026.1.4.1, 2025.3.6.1, 2025.2.6.1.
• GoLand: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.5.2, 2025.2.6.3.
• RustRover: 2026.3 EAP 8, 2026.2.5, 2026.1.4.1, 2025.3.7.1, 2025.2.6.1.
• Gateway: 2026.3 RC, 2026.2.4, 2026.1.4, 2025.3.3, 2025.2.6.
• ReSharper: 2026.3 EAP9, 2026.2.4, 2026.1.5.3, 2025.3.5.3.
• Toolbox App 3.9.1, 3.8.2.

The 2025.2.6.* updates for all IDEs now contain only the JBR fix. They will get a separate hotfix for the JCEF problem. Until then, use a workaround to disable JCEF in your IDE (see instructions below).

IDE versions 2025.1 and earlier, and Toolbox App 3.7 and earlier, will not receive this fix. You must update to a fixed version.

Details

In October 2026, the private keys of eight intermediate certificates issued by the certificate authority eMudhra were compromised. An attacker who can intercept your network traffic could use them to impersonate websites and services.

Full details of the incident.

JetBrains IDEs check certificates against the trust store of their bundled runtime, JetBrains Runtime (JBR), so updating your operating system doesn’t protect against this issue. We’ve integrated Oracle’s fixes for CVE-2026-91403 and CVE-2026-114820 into JBR as-is. The updated runtime blocks the compromised certificates and no longer trusts these root certificates:

• emSign ECC Root CA – G3
• emSign Root CA – G1
• emSign Root CA – G2
• AAA Certificate Services

In the fixed versions of 2025.3 and later, the embedded browser now receives Chrome’s certificate updates, which block the compromised certificates (CVE-2026-118696). It downloads them from Google’s update servers shortly after the IDE starts. If your network blocks access to Google’s update servers, the embedded browser stays unprotected. In this case, turn it off as described below.

The Toolbox App and JetBrains IDEs also install a background service, jetbrainsd. Its list of trusted certificates is built into the service itself, so updating JBR doesn’t fix it. We’ve released a separate fix in jetbrainsd 0.9.9728, tracked as CVE-2026-118697. Only one copy of jetbrainsd runs for each user, and a newer version always replaces an older one. Updating any app that includes jetbrainsd 0.9.9728 fixes it for all JetBrains apps.

What you should do: Update now

The fix is available in the latest versions of JetBrains IDEs, from 2025.2 up to 2026.3 RC. The upcoming 2026.3 release will include it too. Updating to the latest bugfix release of your current version is enough. Versions 2025.1 and earlier will not receive a fix. If you use one of them, please update to one of the versions above.

If you use ReSharper or other JetBrains .NET tools, update them to the latest version.

Important for Toolbox App users: versions 3.7 and earlier won’t receive this fix. If you’re on 3.7, update to version 3.9.1 or 3.8.2.

If you use JetBrains Gateway, update it to one of the following versions: 2026.1.4, 2025.3.3, 2025.2.6.

If you use JetBrains Runtime directly, update to one of the fixed builds: jbr25.635.79, jbr25.508.41, jbr25.329.142, jbr21.1163.125, jbr21.1038.91.

In rare cases, the IDE will no longer connect to a server whose certificate chains to one of the removed root certificates. The server’s owner will need to replace the certificate.

If you can’t update right away

Also check

Your project JDKs and any tools that bring their own runtime, such as Node.js, Python, or Go, use their own trust stores. Update them as their vendors recommend.

Support

If you have any questions about this issue or have trouble updating, please contact our Support team.

Today, we’re proud to announce 1.0, the first stable release of Java and Kotlin by IntelliJ IDEA.

And we’re not shipping it alone. This release is also the result of a close collaboration with the team at Cursor, who have worked alongside us to make Java and Kotlin a first-class experience in their development environment. 

Get Java and Kotlin by IntelliJ IDEA from Visual Studio Marketplace

Get Java and Kotlin by IntelliJ IDEA from Open VSX Registry

Why this matters

Agentic development is changing how software gets built. As agents take on more implementation work, developers spend less time manually editing code – and when they do edit, they often need only a focused set of features: navigating to declarations, finding references, code completion, and renames.

These capabilities are exactly what the Language Server Protocol was built for: implementing language support once, and reusing it in any LSP-capable editor. And it’s not only humans who benefit. Agents can call into an LSP directly, producing faster, more deterministic results – and, importantly, consuming fewer tokens.

These are the workflows we want to accommodate with our extension and the underlying IntelliJ IDEA’s Language Server and Debug Adapter.

Cursor collaboration

When we set out to bring IntelliJ IDEA’s language intelligence beyond our own IDE, Cursor was a natural first partner. 

Their team collaborated closely with us throughout the development of the extension, battle-testing it and making sure Java and Kotlin developers get a seamless experience inside Cursor from the moment they open a project. 

We’re glad to work with JetBrains to bring Java and Kotlin language intelligence to Cursor. With Java and Kotlin by IntelliJ IDEA, developers get IntelliJ IDEA’s code analysis, navigation, and refactoring while they work with Cursor’s agents.

— Rohan Shah, Product, SpaceX AI

What’s in 1.0

Java and Kotlin by IntelliJ IDEA is powered by the same Java and Kotlin language technology as the IntelliJ IDEA desktop IDE. 1.0 brings a focused set of capabilities to VS Code and Cursor, including:

• Java, Kotlin, and mixed-language project support
• Smart code completion, navigation, and code analysis
• Refactorings and editor assistance
• Maven, Gradle, and Bazel build tool support
• Fast, reliable performance even on large projects and monorepos
• Support for test runners right now for JUnit
• Powerful debugging capabilities, including emulated breakpoints and async stack traces

The full feature list is in our documentation.

For Cursor, there is dedicated support for the Agents Window. It may use its own instance of the Language Server to provide analysis capabilities based on IntelliJ IDEA’s inspections. This includes nullability support with JSpecify and for Spring Framework’s specifics.

Getting started

Install Java and Kotlin by IntelliJ IDEA from the Visual Studio Marketplace or the Open VSX registry.

Install in Cursor

1. Open Cursor.
2. Switch to IDE mode (IDE↗).
3. Copy the installation command .ext install JetBrains.intellij-server
4. Press Ctrl/Cmd+P, paste the command, and press Enter

Or get in from Open VSX Registry

Install in VS Code

1. Open VS Code or another compatible editor.
2. Copy the installation command .ext install JetBrains.intellij-server
3. Press Ctrl/Cmd+P, paste the command, and press Enter.

Or get it from Visual Studio Marketplace

Once installed, open your Java or Kotlin project in VS Code or Cursor. The extension analyzes your project, imports it based on any Maven, Gradle, or Bazel build files it finds, and enables Java and Kotlin language features in the editor.

Compatibility notice

Java and Kotlin by IntelliJ IDEA includes code analysis and quick-fixes that overlap with Red Hat’s and Oracle’s Java extensions. To avoid duplicated or conflicting behavior, we recommend disabling those extensions while using ours.

We have, however, made sure that our extension works well with others, like Spring Tools from the Spring Team.

Licensing

With version 1.0, the extension moves out of its free preview phase. Using it now requires an IntelliJ IDEA Ultimate subscription after a 30-day trial period during which you can try out its full feature set for free.

The same license covers IntelliJ IDEA’s Java and Kotlin capabilities everywhere you work – the IntelliJ IDEA desktop IDE, VS Code-based editors like Cursor, and other supported environments. You can review pricing here.

Note: The license is explicitly designed for human use; we’ll release an update regarding licensing models for purely agentic use soon.

Coming next: Agentic and terminal-based workflows

Java and Kotlin by IntelliJ IDEA 1.0 in the editor is just one milestone. 

In one of the next releases, agents that you orchestrate in the Agents view in Cursor or VS Code will also be able to call the LSP directly when writing code, leading to faster, better, or cheaper results.

In parallel, we’ve been running experiments applying the same LSP- and DAP-backed intelligence to fully agentic, terminal-based workflows – think Claude Code or Codex calling directly into IntelliJ IDEA’s Java and Kotlin understanding. News on this will also be announced soon.

Feedback and support

We’re still listening – Java and Kotlin by IntelliJ IDEA 1.0 is a milestone, not the finish line. Tell us what works, what doesn’t, and what you want next. Leave a comment here, open a ticket in our issue tracker, or submit a support request using this form.

Thank you to everyone who tested the preview, and to the Cursor team for launching this with us.

At a glance

The goal: Increase agent ROI

JetBrains and Netflix set out to give coding agents accurate, IntelliJ IDEA-grade code understanding in headless environments – with no IntelliJ IDEA instance running.

“Coding agents like Claude Code are slow and unreliable at navigating Java/Kotlin code, especially across library (JAR) boundaries. We integrated a headless JetBrains IDE’s code engine to give agents IntelliJ IDE-grade code intelligence in headless environments, with no IDE running. We created a benchmark with real programming tasks, which shows that with the JetBrains IDE’s code engine, agents are consistently more efficient – using fewer tokens and less time, with the exact gain depending on the model.”

— Paul Bakker, Staff Software Engineer, Netflix

The JAR problem Netflix is trying to solve that Paul describes above: JVM projects typically ship libraries as JAR files only, never as source. Agents have to unzip the JARs (guessing which ones matter), potentially decompile class files, then grep through that incomplete view.

The solution: JetBrains IDE intelligence

JetBrains has spent years building the code intelligence engine behind IntelliJ IDEA. It is based on a deterministic index of your project source files, including all libraries. This intelligence is now exposed via an LSP and available in VS Code-compatible editors. Netflix worked with a headless build of that engine.

The LSP alone isn’t enough for a coding agent to use directly: It’s just a server speaking a protocol, with no easy way for an agent to call it and no built-in process management to reuse a running instance between calls. Netflix closed that gap themselves using the daemon and CLI described in the next section.

Architecture in detail: Keeping the index warm

Building an index for a project takes real time, just as opening a large project in IntelliJ IDEA for the first time does. A coding agent calls the LSP in many small, fine-grained steps, and a realistic task needs several such calls. If each one spun up a fresh LSP server, every single call would incur a multi-second cold-start cost – even on a project whose index had already been built a minute earlier.

A daemon process is required to avoid the overhead of cold-starting the LSP server process on repeated calls. JetBrains is working on delivering a daemon, but no daemon was available by the time of evaluation, so Netflix has built one for their own needs:

1. Each tool call was short-lived and stateless – it just shelled out to the CLI.
2. The daemon is the part that stays up: Its session manager routes each call by project root to the matching server process, which holds that project’s index in memory.
3. A second call against the same project skips indexing entirely and goes straight to a warm server over stdio.
4. Both the daemon and CLI are developed in Java and distributed as a GraalVM executable, so there is no startup or runtime overhead from the JVM.

How Netflix measured the ROI of JetBrains IDE intelligence

To understand if (and to what extent) JetBrains IDE intelligence improves the performance of a coding agent, a benchmark suite was developed. Same model, same task, same codebase – the only variable was whether the agent could invoke the JetBrains IDE intelligence. Results are reported as the performance difference between runs with JetBrains IDE intelligence versus runs without it.

Evaluation environment and approach:

The benchmarks were run multiple times to validate the results and see the effects of changes from new LSP releases.

Results

Across every model, agent, and task type tested, JetBrains IDE intelligence made coding agents more efficient overall – typically 20–30% more efficient, and up to about 65% in the best case, depending on the specific model, agent, and task. The stronger models, with higher effort, saw the largest gains. These models are more expensive, so efficiency improvements matter more, but these models are also better at using indexes effectively.

These numbers are a snapshot, not a fixed benchmark result. Every new model release changes how agents search, reason, and use tools, so the exact percentages will keep moving – which is why this write-up reports ranges rather than per-model results. What held up across Netflix’s runs is the general shape: every model and agent tested became more efficient, the largest gains came from the strongest model at a high-effort setting, and the size of the gain differed noticeably from one model to the next.

Code-navigation tasks: More efficient across the board, correctness held or improved

Every model and effort level tested used fewer tokens with JetBrains IDE intelligence – no exceptions there – with savings ranging from roughly 15% to 60%. The size of the gain depended mostly on the model: the strongest model saw by far the largest improvements, while lighter-weight configurations landed at the lower end of both ranges. Correctness held steady in most runs and improved in two – it never dropped.

For the code-navigation tasks specifically, one tool/model combination already batches multiple search calls into a single command, so both with and without JetBrains IDE intelligence, it only makes one tool call there. Calling into JetBrains IDE intelligence is a little slower for that one call than the batched search command – which is what produced the clear lack of time benefit for that combination, not a fair reflection of real-world use. That’s why the broader end-to-end task suite is the more reliable read on time instead, where JetBrains IDE intelligence was faster across every model and agent tested.

End-to-end tasks: Consistently more efficient, correctness unaffected

On the expanded end-to-end run, correctness held steady everywhere across every model and agent tested, so the benefit shows up entirely in efficiency, not in whether the task got done. Every model and agent combination was roughly 10–30% more efficient with JetBrains IDE intelligence, looking at time to completion and token spend. A lot of this is explained by requiring fewer tool calls to come to the same conclusions.

Other evaluated alternatives

Before committing to the described approach, Netflix ruled out two others. The first rejected was a homegrown internal CLI that connected to a running IntelliJ IDEA instance to get access to a project index. The process is similar to what this article describes, but it requires an IDE to be running. This approach didn’t fit headless agents for environments like Otto, Bitbot, distributed refactoring tooling, CI, etc.

Second, an existing Eclipse LSP, which is used for Java in VS Code, was considered. But for Netflix’s build system (Gradle-based), it just didn’t work.

What’s next

Where Netflix goes from here

After the test, Netflix concluded that “the benchmarks show that there is a benefit to having a deterministic intelligence layer alongside your agent”. Of course, it doesn’t cut every coding-agent task by a fixed percentage. But for this specific problem – resolving real structure across JAR boundaries – the benefit is large, holds across models, and doesn’t cost anything in correctness.

Netflix plans to run the same benchmark methodology against Python, TypeScript/JavaScript, and Go. Coding agents for those languages have similar problems. But of course, the ways libraries are downloaded in a project vary by language, so the mechanics of the issues and possible solutions differ. JetBrains plans to continue the collaboration and support this evaluation further.

JetBrains’ take: The LSP is just one step, not the destination

JetBrains IDE intelligence for Java has been tested by Netflix and is now shipped as part of the Java & Kotlin by IntelliJ IDEA extension. JetBrains also continues experiments with the LSP+CLI approach and will report the results once ready.

The LSP’s basic primitive is a position in a text document. The specification defines a position as “between two characters, like an insert cursor in an editor”. That’s a natural primitive for a human working at a keyboard. But agents don’t really think in terms of cursor locations. They ask questions about the program, like “Why is this call inside createUser() unresolved?” and “Which tests are covering this method?”, etc. It’s about understanding relationships between parts of the code rather than looking at cursor positions. And a text position is a fragile identity – inserting one character before any given position causes that position to move.

What an agent needs isn’t a sharper cursor, but a layer that provides answers formulated in the same way as the tasks themselves – i.e. in terms of symbols, diagnostics, test relations, runtime behavior – and returns enough context to reason about the answer, not just locations in a text document.

“That’s what I mean by a code engine: not another protocol that lets an agent imitate editor interaction, but a set of precise operations over program structure and execution – one that returns enough context to actually reason about the result. LSP is useful, but it shouldn’t define the final agent-facing abstraction. Build agent tooling as if the agent were a tiny human at an editor, and you force it to speak in cursor coordinates. Agents need a code engine, not a virtual editor.”

— Aleksey Stukalov, IDE Division Lead, JetBrains

The Netflix numbers prove code intelligence is worth paying for. Deciding what shape that intelligence takes is the challenge that lies ahead.

Modern IDEs are packed with power. The real challenge isn’t whether your IDE can do something – it’s remembering how to trigger it.

Some features live behind shortcuts. Others are available through intention menus, Search Everywhere, postfix completion, live templates, or tool windows. Discoverability is a constant tax on developer focus: As an IDE grows more capable, keeping every feature within reach gets harder.

That’s why we created command completion, a context-aware entry point to useful functionality from the place where you spend most of your time – the editor.

Typing .. anywhere in a file surfaces intelligent actions tailored to your current code and caret position. Whether you need to refactor, navigate, generate, document, explain, or fix code, you can act immediately without breaking your flow.

Rather than answering “What can I type here?”, command completion addresses a more useful question: “What can I do here?”

This feature has already been around for a while. In IntelliJ IDEA 2026.3 EAP, it is taking another big step toward becoming your primary interface for everyday coding assistance.

Here’s what’s new and improved:

Logpoints are easier to reach

Debugging with temporary println() statements is a habit many of us struggle to break. You add print statements, re-run the app, read the console, and then manually clean up the code afterward.

Logpoints are a cleaner, non-intrusive alternative – and now they are accessible right through command completion:

Simply type .. over an expression or block to drop a logpoint instantly, using the current expression or context as the logged value. Even better: IntelliJ IDEA will now suggest replacing existing print statements with logpoints, helping you move from messy code edits to clean, debugger-supported logging.

If you’re new to logpoints, take a look at the logpoints tutorial. It explains how to combine them with your AI agents in IntelliJ IDEA. If you missed our 2026.2 updates, logpoints got a revised UI, AI agent support, improved navigation, and faster evaluation, making them one of the most versatile debugging tools in your toolkit.

In-context AI assistance

You can now trigger AI actions using the same .. workflow. Need to explain a complex method, generate docstrings, or refactor a block? You no longer have to interrupt your flow, switch tools, or describe the exact location to the agent. Because the IDE already knows your active file, language, line number, and selected expression, it can give the agent this rich context.

Note: If you have the Air plugin installed, your requests will be automatically routed through it.

For actions that affect a specific class, method, or declaration, IntelliJ IDEA now highlights the target so it is clearer what the selected command will apply to before you run it.

Postfix completion and live templates

As part of our effort to unify completion workflows, postfix completion, live templates, and command completion now share a consistent interface. You’ll notice clearer filtering, sharper preview panels, and more intuitive discoverability directly from the completion popup.

More contexts

Command completion is also becoming useful in more contexts, including binary files and decompiled code.

We’ve also expanded support to structured and framework-specific environments. You can now use .. inside properties files, Spring workflows, and other domain-specific formats, with support for build scripts coming soon.

Why this matters

Command completion isn’t just another flavor of autocompletion. It is a fundamental shift in how you discover IDE functionality. 

Instead of searching through top-level menus or memorizing hotkeys, you can start from where you already are – the code. IntelliJ IDEA continuously analyzes your syntax tree, scope, inspection state, and available actions to present only what is relevant in the moment.

For high-frequency actions, shortcuts remain the fastest choice. For everything else, command completion gives you a discoverable path directly from your code.

Try it out today

Open any Java, Kotlin, or Scala file in IntelliJ IDEA 2026.2 or 2026.3 EAP and type .. anywhere in the editor. Try it near a method, an expression, a regular expression, a declaration that needs documentation, or a place where you would normally open Search Everywhere. The completion popup will reflect what’s possible in that exact spot.

Command completion is continuously evolving, and we have big plans for future releases. Our core mission remains simple: one familiar entry point for whatever you want to do next in code.

This was our first step towards bringing IntelliJ IDEA’s Java and Kotlin intelligence beyond the IDE, giving developers and their agents accurate, project-aware code understanding across their tools and workflows.

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. The foundation for a stable 1.0 release is now in place, and the release itself will arrive very soon.

This RC is the final Early Access Program build and will remain available under the EAP terms for 30 days.

If you’ve been waiting for the right moment to try the extension on a real project, this is it.

Install from Visual Studio Marketplace

Install from Open VSX registry

From preview to Release Candidate

Since the first public preview, we’ve shipped several intermediate builds, improving performance, reliability, and the extension’s feature set along the way.

The extension has now been downloaded over 20,000 times across Visual Studio Marketplace and Open VSX Registry.

Early adopters helped us get here by reporting issues, sharing projects and logs, and telling us which capabilities they wanted to see next. We’ve also been dogfooding the extension ourselves, including on the large repository used to build IntelliJ-based IDEs.

The RC brings IntelliJ IDEA’s Java and Kotlin language technology to the whole development workflow. Alongside IntelliJ IDEA’s core coding assistance – including smart code completion, navigation, inspections, quick-fixes, and code analysis – the extension provides more advanced capabilities, such as project-wide refactorings, DAP-based debugging, Maven, Gradle, and Bazel project support, built-in test running, Spring tooling interoperability, and more.

It also makes this intelligence available to coding agents. 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.

We’re continuing to invest in this direction. The goal is not simply to reproduce IDE features in another editor. It is to make IntelliJ IDEA’s understanding of JVM code useful to developers and their tools wherever they choose to work.

Over the coming weeks, we’ll take a closer look at these capabilities and share more about where we’re taking the technology next, including fully agentic, terminal-based workflows.

What the Release Candidate means for licensing

The RC build is part of the Early Access Program and can be used for 30 days without a license.

Starting with the stable release, new users will receive a 30-day free trial. After the trial period, using the extension will require an IntelliJ IDEA Ultimate subscription.

Try the Release Candidate

Install Java and Kotlin by IntelliJ IDEA in VS Code, Cursor, or another compatible VS Code-based editor, open a real project, and tell us what you think.

You can leave a comment here or submit a request to us.

Thank you!

Get Java and Kotlin by IntelliJ IDEA from Visual Studio Marketplace

Get Java and Kotlin by IntelliJ IDEA from Open VSX Registry

Featured Content

Marit van Dijk

Marit van Dijk is a Java Champion and Developer Advocate at JetBrains with over 20 years of software development experience. She’s passionate about building great software with great people, and making developers’ lives easier.

Java 27 was released last month. Of course, we support it from day 1 in IntelliJ IDEA. You can read all about it in Java 27 in IntelliJ IDEA or watch the release stream if you missed it. Piotr Przybył and I updated our talk Learning modern Java the playful way and presented it at GOTO Copenhagen last week, where I was also on stage for two other sessions. This week, Piotr and I will be doing a Deep Dive version at Devoxx Belgium. Later this month you can find us at JDD and Hello Stavanger.

In other news, JetBrains Air was announced; one system for building software with agents. Please try out Air in the IDE and let us know what you think! 

Igor Kulakov wrote a Logpoints Walkthrough on how to use Logpoints; a new debugging feature in IntelliJ IDEA. Anton Arhipov shows how to tie that all together. And Siva Prasad Reddy K announced a course Building with AI Agents From Idea to Production where he will teach you about agentic development with IntelliJ IDEA and Spring Boot.

Finally, we are starting to release the videos from IntelliJ IDEA Conf 2026 on the IntelliJ IDEA YouTube channel, or catch up on IntelliJ IDEA Tech Talks episodes.

Java News

Here’s what’s new in the Java world: 

• Java News Roundup 1, 2, 3, 4
• The Arrival of Java 27!
• Java 27 in IntelliJ IDEA
• JDK 27 Security Enhancements
• Performance Improvements in JDK 27
• JDK 27 Runtime Updates Release Notes
• Java 27 Technically Within 2 Minutes
• Spring Office Hours Podcast: S5E23 – Java 27 Release Party with Billy Korando
• Java Next
• Just-In-Time Compilation for Java Performance: Recent and Ongoing Improvements
• Quality Outreach Heads-up – JDK 28: Rich JavaDoc Notes
• JEP targeted to JDK 28: 539: Strict Field Initialization in the JVM (Preview)
• JEP targeted to JDK 28: 541: Deprecate the macOS/x64 Port for Removal

Java Tutorials and Tips

Give your next coding session a head start with these practical guides:

• From Spec-Driven Development to Living Specifications in Java Projects
• Principles of Memory Management in Java

• IntelliJ IDEA Tech Talks:
  • Beyond Virtual Threads: Structured Concurrency – Balkrishna Rawool 
  • Agent Client Protocol for Java Developers – Mark Pollack
  • Agentic Patterns and Tool Calling with Spring AI – Christian Tzolov
• Native Calls in IntelliJ Platform Plugins: JNA vs FFM
• Masking a JVM thread dump without breaking the analysis
• My Ten Year Quest to Evolve Java Collections Beyond Java Stream 
• When Spec-Driven Development Pays Off
• Episode 68 “Operator Overloading with Type Classes” [AtA] 
• Come for Java. Get a Whole Lot More.
• The Java 21 Doomsday Clock Countdown
• Async is the New `goto`- Rethinking Structured Concurrency – Wout Werkman
• Getting more out of Maven – Marit van Dijk and Andres Almiray
• Module Imports

Kotlin Corner

A little Kotlin inspiration? Right this way: 

• Kotlin Developer Survey is ongoing 
• KotlinConf 2027 is coming to Krakow
• The State of Kotlin in 2026 Report 
• Companions to come

AI 

Beyond the AI buzz, there’s plenty to explore:

• Beyond Prompting: Context Engineering for Production-Grade AI
• Rigorous Yet Sustainable Human Reviews in the AI Era
• Did Your AI Agent Run the Debugger? One JVM Bug, Two Agent Runs
• Building an Agentic Warehouse Management System — Part 1: Where AI Agents Add Value
• Building an Agentic Warehouse Management System — Part 2: Java and Spring AI
• Building an Agentic Warehouse Management System — Part 3: Tools, Decisions, and Actions
• How Figma Uses AI Agents for Security
• Making Your Data Ready for Agentic AI
• Platform Engineering in the Age of AI
• Debugging Is Invariant Discovery: What One Kafka Session Taught Us About AI Agents
• The Lifecycle of LLM-as-a-Judge: Building, Aligning, and Monitoring at Scale 
• Independent Investigation of Hugging Face Incident Reveals How Agents Collaborated and Behaved
• Did Your AI Agent Ever Run a Debugger? One JVM Bug, Two Agent Runs 
• How I Built an AI Assistant for My Career with Java, Spring AI, and MongoDB
• Can You Explain the Diff Your AI Agent Just Wrote?
• Tachyon MCP 1.0 is here!

Languages, Frameworks, Libraries, and Technologies

Your next useful discovery might be outside your usual stack:

• This Week in Spring – 1, 2, 3, 4, 5
• Spring Office Hours Podcast: S5E21 – Pro Spring Boot 4 with Felipe Gutierrez
• Spring Office Hours Podcast: S5E21 – Pro Spring Boot 4 with Felipe Gutierrez 
• Quarkus Insights #258: Quarkus Feature Flags 
• Aggregation Optimization in MongoDB: Sorting With Indexes (Part 5)
• Kubernetes Promotes KYAML as a Safer, More Consistent Way to Work with Manifests
• A Bootiful Podcast: Netflix’s Paul Bakker
• Andrew Kelley Interview: Why He Built Zig, Banned AI Contributions, and Moved Zig off GitHub
• Context Is the New Code

Conferences and Events

Clear some space on your calendar for these conferences: 

• Devoxx Belgium – Antwerp, Belgium, October 5-9; Come meet JetBrains people and learn the recent news at our booth. 
• JavaCro – Rovinj, Croatia, October 11-14
• Dev2Next – Lone Tree, USA, October 12-15
• BaselOne – Basel, Switzerland, October 14-15
• {j}DD – Kraków, Poland, October 20-21; Join the session by Marit van Dijk. 
• JCon USA – Atlanta, USA, October 26-29
• J On the Beach – Malaga, Spain, October 29-30

Culture and Community

Great software starts with people, and people have stories to tell:

• Personality Over Skillset: How Adam Wachtel Builds Engineering Teams
• You Can’t “Vibe Code” Love
• I don’t like LLMs
• Build your Agentic Harness is Out

And Finally…

One last detour before you go: 

• Project Loom in IntelliJ IDEA: Virtual Threads, Scoped Values, and Structured Concurrency
• The Grails Plugin Has a New Home: Apache Grails
• Debug Past an HTTP 403 Without Breaking Spring Security
• The Evolution of WSL Support in JetBrains IDEs

That’s it for today! We’re always collecting ideas for the next Java Annotated Monthly – send us your suggestions via email or X by October 20. Don’t forget to check out our archive of past JAM issues for any articles you might have missed!

Last week, we shared our point of view on where we think agentic development is headed and introduced JetBrains’ answer to it: JetBrains Air, an open system of products for agentic development.

Today, we’re launching the Early Access Program for Air in JetBrains IDEs. It’s available now as a plugin on JetBrains Marketplace or natively in the 2026.3 EAP builds of JetBrains IDEs. Try Air with free Junie Lite runs, our efficient coding agent for everyday tasks.

The Air plugin for JetBrains IDEs is a conduit for agents and subscriptions you already use. It is not an AI provider, and it ships with no agents installed.

Why a new experience?

AI in the IDE has traditionally centered around AI chat. Agentic development, however, changes the established interaction model: You delegate larger tasks and allow agents to work in parallel. This means you need to be able to see what they’re doing and steer them along the way. We tried to integrate that function into our existing AI Assistant solution by adding more agents to the AI chat. But as these workflows evolved, one thing became clear: Orchestrating several tasks concurrently is fundamentally different from having a conversation with AI. 

Air is designed around that difference.

Behind this lies a bigger paradigm shift, and we won’t mince our words: Agentic development is becoming the norm, and an IDE that keeps agents at arm’s length will struggle to stay relevant. 

That makes the IDE more important, not less: As agents do more of the work, verifying and owning the result becomes the hard part, and that is what the IDE is for. The center of gravity in JetBrains IDEs is shifting towards agentic development, and Air is how we get there.

Introducing JetBrains Air in IDEs

Air brings agentic development into the IDE without locking you into a particular agent or changing the way you already work. It’s built around three principles – the first two you’ve heard from us before. What’s new is a product designed around them from the start.

1. Bring your existing agents into the IDE

Air works with the agents you already use, such as Codex, GitHub Copilot, Junie, Cursor, and other ACP-compatible agents. It detects agents already installed on your machine and makes it easy to bring them directly into the IDE. With JetBrains Air in IDEs you can also use your Claude subscription in Air’s terminal and full-screen tab. 

You don’t need a JetBrains AI subscription to use your agents with Air. Use your existing AI provider subscriptions or JetBrains AI if you already have it. 

2. IDE intelligence for you and your agents

Development doesn’t end when code is generated – it still needs to be run, reviewed, and validated. That’s exactly what an IDE is built for. It gives you the tools to understand and review the agent’s work – from diffs and navigation to inspections and more.

And agents benefit from the IDE, too. Built-in IDE skills and tools give supported agents access to specialized JetBrains expertise and workflows for tasks like debugging, performance profiling, database exploration, and semantic code search. This can help agents produce better results and, for some tasks, use fewer tokens.

3. An agentic-first UX

Air is designed for working with multiple agents in parallel, not just interacting with one at a time. Agent work is organized into sessions, with all your sessions visible in one place, so you can track progress, see what needs your attention, steer agents, and review their work across projects.

Working with Air

Here’s what that looks like in practice:

Stay on top of parallel agent work. View sessions across projects in one place, with activity, unread updates, changed files, and outgoing commits at a glance. See what each session costs as you work, so spend stays visible across agents and tasks. This makes it easy to track progress and quickly see what has changed and what requires your attention.

Delegate a task in one keystroke. Double-tap Ctrl from anywhere in the IDE to open a prompt window and start a new agent session, with your current context already attached.

Choose the preferred UI for an agent session. Sessions themselves open right in the editor as tabs, giving agent work a real screen space alongside your code. If you prefer the terminal UI, you can keep using it directly in the IDE. Or choose a graphical chat when that works better for the task. 

Run agents locally or in the cloud. For tasks that are complex, long-running or can be done in the background, run agents in the cloud, and close your machine. Follow along on mobile (coming soon) to steer the agent. Currently available to orgs with AI seats.

Keep parallel agent work isolated with temporary worktrees. Start a session from any branch, either on a new branch or in a detached way. Track changes and commits from the chat, then cherry-pick the result back into your main project when it’s ready.

You stay in control

AI Assistant remains available while you try Air in your IDE. Over time, we expect Air to become the primary experience for agentic workflows in JetBrains IDEs.

As Air becomes a bigger part of JetBrains IDEs, the first question from many of you will be about control: Can I keep this off, and where does my code go? 

No agents? Nothing leaves your machine. Air is a tool window, not an AI provider, and it ships with no agents installed. It detects agents already on your machine, the way the IDE detects your terminal, but nothing runs, and no data leaves your machine until you sign in to an agent or a JetBrains AI plan. If your organization doesn’t allow agents, there’s nothing for Air to run and nothing to send.

Your data goes to your provider, not to JetBrains. With a third-party subscription, data goes directly to that provider under the agreement you already have with them. It doesn’t pass through JetBrains. If you use JetBrains AI, the JetBrains AI Terms of Service apply, as is already the case with AI Assistant. Air adds no new data processing terms.

You can turn it off. Disable the Air plugin, and nothing else changes.

Try it — with Free Junie Lite

We believe we should provide some version of free AI in our IDEs, so we’re offering Junie Lite for free*. This is our coding agent with a cost efficient model for everyday tasks so you can experience Air without paying for anything. 

Give Air a real task: Run agent sessions across multiple projects and tell us how it fits into your workflow. Share your feedback via YouTrack so it lands in our teams’ backlog, or drop your thoughts in the comments below.

Install Air from JetBrains Marketplace, via the notification in AI Assistant, or as part of the 2026.3 EAP builds of JetBrains IDEs, then connect the agents you already use, or use the ones available through JetBrains AI. If you install Air from the notification in AI Assistant, AI Assistant will be disabled to prevent both from running side by side. You can re-enable it at any time in Settings | Plugins, or reinstall it from Marketplace.

*Applies to Junie Lite configuration, after signing in with your JetBrains Account. Terms and available models may change.

Frequently Asked Questions: 

What is going to happen to AI Assistant?
We believe Air is the future of agentic development in JetBrains IDEs, but AI Assistant will remain available and supported as a separate plugin you can install from the marketplace. 

Which agents and models are supported?
Air supports Codex, Gemini, GitHub Copilot, Claude Agent, and Junie out of the box, and many others can be connected via ACP. You can use your own third-party subscriptions where possible, or use JetBrains AI.

Can I use my Claude subscription? 
Yes, You can use your Claude subscription in Air’s terminal surface which opens as a full-screen IDE tab. 

Do I need a JetBrains AI subscription?
You can use your JetBrains AI subscription, but it’s not mandatory. However, a JetBrains AI subscription is currently required for cloud runs and a JetBrains Account is required to access Junie Lite runs.