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. 

Six months ago, we began publicly experimenting with agentic development environments. Around the same time, we introduced JetBrains Central as an open control and execution system for agent-driven development. We subsequently began rolling out JetBrains Central CLI, shared context, cloud agents, automations, governance, and AI cost controls for teams and organizations.

Today, we are bringing this work together as JetBrains Air: an open, coherent system of products for developers, teams, and organizations, inside and beyond JetBrains IDEs. It is multi-surface and multi-service. Each product solves a distinct problem, but the products work better together.

JetBrains Air marks a significant expansion in what JetBrains is building for. For 26 years, we have focused primarily on the individual developer workbench. Now, we are building for the wider system through which agentic work is initiated, executed, coordinated, reviewed, and governed.

The IDE remains important to JetBrains’ future. The era in which the whole software development system can be contained in one window is ending. As part of our continued investment, we are now bringing the foundational agentic experience into JetBrains IDEs, giving professional developers an environment where they can work effectively with agents while understanding, changing, and verifying the resulting code. JetBrains Air connects the wider system developing around it.

That system is based on a core belief that the future of agentic development will be multi-vendor. No single model, agent, or service will be right for every developer, team, or task.

From one product to an open system of products

This strategic shift has a practical consequence: JetBrains Air cannot be just another agent or development environment. It must connect products for individual work, team coordination, organizational control, context, and process automation – and remain open to the tools and agents developers choose, including those JetBrains does not build.

JetBrains Air includes products that are available today alongside others that will be introduced as the system develops:

• Air in JetBrains IDEs – a complete agentic development experience for directing and orchestrating agents and verifying their work inside JetBrains IDEs. 
• Air Teams – a new way to coordinate and automate software-delivery workflows involving developers and autonomous agents. 
• Air Governance (formerly JetBrains Central) – organizational policy, visibility, auditability, cost management, and accountability for AI-assisted and agent-driven development. 

Junie is JetBrains’ coding agent for professional software development. It will be supported across all Air surfaces.

Air in JetBrains IDEs gives developers the environment to direct agents and verify their output using JetBrains’ code intelligence. Air Teams turns individual agent activity into coordinated team workflows. Air Governance makes that activity visible, governable, and accountable across the organization.

But an open system cannot stop at JetBrains’ own products. The Agent Client Protocol (ACP) standardizes the connection between an IDE and an agent’s full harness, including its planning, logic, tools, model routing, and observability. Through the ACP Registry, developers can discover and run a growing range of compatible agents while continuing to work inside JetBrains IDEs.

Air Governance is designed to extend visibility and cost governance across providers and the different tools through which agentic work takes place. This means developers can choose the agent, model, or service suited to the task without forcing the organization to give up context, visibility, or control.

Together, the Air products allow work to move between developers, agents, tools, and environments without losing the context and controls surrounding it.

Individual adoption has moved faster than organizational infrastructure

Since March, our products have progressed significantly, but so has our understanding of what agentic development requires.

Developers have been adopting agents faster than organizations can build the infrastructure around them. Agent capabilities have advanced, and different models and agents have proven useful for different tasks. However, the context, coordination, governance, and cost management surrounding them have not kept pace.

For many developers, agents are already delivering practical value. At the organizational level, the economics are much harder to prove. The costs surface elsewhere – in review, rework, security, infrastructure, and spend. 

Which agents can access company code? Where can data go? Which output requires human review? What happened while an agent was working remotely? Who approved the resulting change, and how was it verified?

Fragmentation at this level isn’t just irritating. It makes software development harder to understand, measure, and govern at exactly the point when more of the work is being delegated.

The bottleneck is shifting with the work

Code that’s obviously wrong gets caught quickly. That part of the system still works. The harder problem is code that’s almost right: plausible, capable of passing a superficial check, but quietly carrying a bad assumption or architectural inconsistency that won’t surface until it’s expensive.

As agents take on more of the execution, the bottleneck shifts from producing change to understanding, verifying, and owning it. Code becomes cheaper to generate but more expensive to verify. Agent activity becomes easier to start but harder to coordinate, audit, and explain.

And while the work can be delegated, accountability cannot. An agent will not get the call at 3:00 am when something breaks. The responsibility for what ships still belongs to the people and organizations that ship it. 

This is why control becomes harder, not easier, as AI improves. A more capable model may produce better output. It does not establish organizational policy, preserve provenance, provide cost visibility, or decide who accepts responsibility for the resulting change.

The future is multi-vendor

Multi-vendor support is a foundational design principle of JetBrains Air, shaping how the system is being built from the outset.  

We don’t believe this market will consolidate any time soon. Models vary in what they’re good at, and rankings change every few months. Teams inside the same company already make different choices, and they are often right to do so. Standardizing on one AI vendor today means making a multi-year commitment in a market that won’t look the same next quarter.

Keeping the options open is the reasonable thing to do. The problem is what openness currently costs. Every new model, agent, or service an organization adds takes away a little more visibility into its own development work. Context doesn’t carry over between tools. Spend can’t be attributed. Policies have to be rebuilt for each service. 

Organizations should not have to choose between using the best available tools and understanding what is happening inside their own engineering. That trade-off exists because nothing in the current stack was built to sit above several vendors at once.

This is the work JetBrains has taken on. We build our own agent, and we intend to make it excellent. But JetBrains Air does not require customers to use ours, and our strategy does not depend on which model provider leads the rankings this quarter. We have no reason to make the ecosystem smaller than it is.

What we can offer instead is one place to run, see, govern, and account for agentic development across every model, agent, and service – for the developer, the team, and the organization.

Supporting multiple models and agents is the floor, not the ceiling. The part that matters is what sits above them: shared context, one set of policies, a single cost view, and a record of what happened, regardless of which vendor produced the change.

Why JetBrains?

Multi-vendor choice solves only part of the problem. Agents also need reliable software intelligence.

JetBrains brings 26 years of engineering intelligence to the problem, helping developers understand the structure and behavior of complex software, not simply generate more of it. That deterministic code intelligence provides a foundation for making agentic work more reliable, efficient, and understandable across different models and agents. We are seeing promising results from giving AI agents access to deterministic code intelligence. 

This is an economic advantage as well as a technical one. Agents spend time and money rediscovering information the codebase already contains. An agent that can retrieve that knowledge is cheaper and more accurate than one that has to reconstruct it. Because intelligence does not belong to one model, the benefit can extend across supported agents and services. 

We are also going through the same transition as the organizations we build for, adopting agents internally, redesigning workflows, and learning where individual productivity gains translate into better software delivery and where they simply move work elsewhere.

What comes next

JetBrains Air will develop through a rolling series of releases. We will be explicit about what customers can use now, what is entering preview, and what remains part of our longer-term direction.

Over time, JetBrains Air will extend further into mobile and remote experiences, allowing people to initiate, monitor, review, and continue agentic work as it moves between environments. The goal is not to reproduce the IDE on every surface. We are making the right context and controls available wherever decisions need to be made. 

We will also bring JetBrains’ intelligence into more agentic workflows. This includes richer context drawn from code, architecture, repositories, runtime behavior, and organizational knowledge, as well as better ways to route work between developers, models, agents, and services.

More work will be triggered by repository events, schedules, and delivery processes rather than by a developer opening an editor and issuing a prompt. JetBrains Air will provide the intelligence, oversight, and human control these workflows require across surfaces and services.

We will not name future products before their scope and availability are ready to be confirmed. With each release, we will explain what works, how it connects, and what’s still in progress.

Where JetBrains Air is going

The companies that succeed in adopting AI will not necessarily be those that generate the most code or deploy the most agents. They will be those that can expand experimentation without losing quality, context, cost discipline, or human understanding.

JetBrains Air is our commitment to building for that reality. It expands JetBrains from the developer workbench into a system of products connecting developers, agents, teams, and organizations.

The goal is not more code. It is software that developers, teams, and organizations can understand, verify, and stand behind.

Even though working with them is as simple as debugging with plain println statements (and arguably simpler), they vastly broaden the range of issues that you can debug. For some issues, logpoints are the only practical approach. And for the rest, logpoints provide a convenience that saves a lot of time and effort.

Also, in IntelliJ IDEA 2026.2, logpoints got some very cool improvements, so it’s a perfect time to explore them.

Our example problem

Here’s a mini client and server that use gRPC for communication. The server has a bug that makes it return incorrect discount values for some tenants.

So we’ll follow the usual debugging flow. We’ll reproduce the problem, set up visibility into the inner workings of the server, send a problematic request, and observe exactly how it produces the wrong result.

Reproducing the bug

To simulate running in another environment, the project bundles a Dockerfile with the listening and debug ports exposed. You can launch it using the supplied GrpcQuoteServerContainer run configuration or directly from the command line:

docker build -t grpc-timeout .

docker run --rm -p 50051:50051 -p 5005:5005 grpc-timeout

Then for a problematic request, use the GrpcQuoteClientLoop run configuration, which will periodically query the server. This lets us forget about sending requests manually and focus more on what happens on the server.

When both the server and the client loop are running, the console shows the following:

tenant='JetBrains' region='EMEA' status=OK symbol=IDEA price=100.00 USD source=live detail=region=emea, discount_bps=0

But we would expect to see:

tenant='JetBrains' region='EMEA' status=OK symbol=IDEA price=80.00 USD source=live detail=region=emea, discount_bps=2000

Attaching to the server

The server is not launched from a local IntelliJ IDEA debug session, but it listens for debugger connections, so we can still attach to it using the provided GrpcQuoteServer attach run configuration.

It’s worth noting that, for the debugger, there is no difference whether the process runs locally, in a separate environment, or on a remote host. In all three cases, the communication happens over a socket, so our exercise is valid for debugging any Java process regardless of locality.

Logpoints

Logpoints are similar to println statements in that they don’t suspend the program but only log the necessary details to the console. Unlike println statements, however, they can be changed without rebuilding or redeploying the application.

You might already know how to set a logpoint, but IntelliJ IDEA 2026.2 introduced a faster way. Click in the gutter in between any two executable lines and enter the expression you want to log. As the starting point, we can use the beginning of the query handling method ( QuoteEndpoint:12 ):

For every incoming request, the console now prints:

EMEA JetBrains

Now, with the request loop running, we can progressively change and add logpoints until the output points to the bug. Just add more logpoints or update the existing ones and watch for new messages in the console as new requests come in.

After following the call chain, which allows us to rule out any initial suspicions we might have had, we arrive at the discountBpsFor() method:

The console points at the tenant name not being properly normalized:

tenant = JetBrains expected: jetbrains

Also, the absence of discount applied tells us that the block with the correct discount is never entered. Normalizing the tenant name should fix the bug:

private static int discountBpsFor(String tenant) {
    if ("jetbrains".equalsIgnoreCase(tenant)) {
        return 2_000;
    }
    return 0;
}

Pro tip: When in doubt about what produced specific console output, click the line in the console, and IntelliJ IDEA will take you to the relevant logpoint or piece of code:

Even if you are using println statements for logging, the navigation will work for you as long as you are running the process with IntelliJ IDEA’s debugger.

Testing the fix

Let’s test the fix while we’re here. Logpoints are meant for logging, not for modifying the program, but nothing really prevents us from testing how a particular fix would behave:

The prototype works as expected:

EMEA JetBrains

jetbrains

discount applied

Now that we’ve tested the fix, we can change the actual server code.

Why not use println statements?

You’re probably thinking logpoints look like nicer println statements. And they do, in a sense, because the core mechanic is the same. In both cases, you add probes in a simple way that doesn’t affect how the program runs.

Despite their similarities, there are several reasons why logpoints can be a better choice:

• They don’t clutter the code, meaning you won’t spend effort on cleaning up (and won’t commit a stray one to production).
• They are flexible about what they log and when. For example, if you only want to sample frequent events, this is how you configure it.
• They allow you to insert logging inside your dependencies (we’ll do that shortly).
• Most importantly for this scenario, they can save you costly redeploys. Rerunning a local Docker container just to add logging in a toy project might be acceptable, but in large real-world projects it often is not.

These advantages set logpoints apart from println statements and make them feel more like the professional debugging tool they are.

Why not use regular breakpoints?

When using the debugger, most developers will reach for breakpoints. But in the particular scenario we’ve been looking at, logpoints are a better fit, and this is not just a matter of preference.

Let’s see what happens if we use regular breakpoints. After attaching to the server, set a line breakpoint at GrpcQuoteServer.java:55 . The next request from the loop suspends the server:

But after looking at the program state and stepping a couple of times, we find ourselves in the cancellation path:

Once we’re there, there is no useful information, because it’s not where requests normally end up. This happens because the deadline that the client has set is expired and the server discards further work on the request. You can see that IntelliJ IDEA greyed out parts of the code that are not going to be executed. To bring the problematic state back, we have to send requests one after another and do our debugging work within the timeout window.

This happens because our client sets a deadline for the remote call. Unlike a typical HTTP/REST client timeout, where the timeout only signals failure on the client, gRPC can propagate the client’s deadline to the server. As a result, the client can actually cancel the server-side work, not just stop waiting for a response.

On the other hand, logpoints give us the same information we would get in the debugger UI, except that we observe it in the console. Importantly, using them doesn’t suspend the server, so we can extract the information we need without triggering the timeout.

Bonus: Removing the timeout

If you’d prefer an alternative approach to this scenario, here’s another way to debug it. For our gRPC example, the problematic bit was the timeout, and we can remove it at runtime using… logpoints!

As you’ve just seen, logpoint expressions can modify the running program through side effects. Here, we can use this technique to adjust the incoming request.

First, find the library method that sets the timeout. There are several methods we can use. One of them is io.grpc.internal.ServerImpl.createContext :

In that method, we can rewrite the value of the timeoutNanos local variable right after it has been assigned:

With this logpoint in place, every time the gRPC timeout value is read from the request headers, it is immediately replaced with a five-minute deadline. This means we can suspend the server again.

If you want to only extend the timeout for the reproducer requests and keep the server functioning as usual – for example, if it runs on a shared staging instance – you can use multiline logic inside a logpoint:

Here’s the code to copy to the logpoint:

Metadata.Key<String> DEBUG_HEADER = Metadata.Key.of("Debug", Metadata.ASCII_STRING_MARSHALLER);
String debugHeader = headers.get(DEBUG_HEADER);
if ("Debug".equals(debugHeader)) {
    timeoutNanos = java.util.concurrent.TimeUnit.MINUTES.toNanos(5L);
    return "Timeout reset";
}

The multiline expression parses the request headers and extends the timeout only for requests with the Debug header (which our test clients add). Other requests keep the normal deadline. The if branch returns “Timeout reset”, confirming when the branch was visited.

Pro tip: By combining logpoints with the Mark Object feature, you can access arbitrary objects in the logpoint expression field. This article covers the technique in more detail.

The ij-debugger AI agent skill

Of course, the method above requires familiarity with the library or time to explore it. If you have neither and just want to change the runtime behavior quickly, you can delegate the task to an AI agent using the bundled ij-debugger AI agent skill:

The AI agent follows the same path we followed manually, finding where the deadline is read and producing a logpoint expression that changes only the requests we care about. So even without knowing the gRPC internals upfront, we can still get to a targeted workaround and continue debugging.

Conclusion

In this article, we looked at a use case where logpoints offer a simpler and more elegant alternative to breakpoints or println logging. We:

• Attached to a remote process
• Added diagnostics at runtime using logpoints
• Adjusted logging on the fly
• Tested the fix without changing the application code
• Changed the timeout for a running server
• Used the ij-debugger AI agent skill

I hope you learned something new and now have a better option for the next time println statements or breakpoints get in the way. In the next post of the series, we’ll look at debugger instrumentation, the underlying mechanism that makes the new logpoints so fast.

Happy debugging!

The latest update brings the following improvements:

• When opening a recent project, the Maven tool window is now populated with the corresponding data. [IDEA-391792]
• Several causes of IDE freezes have been resolved. [IJPL-235455], [IJPL-252292]
• The vertical scrollbar is once again displayed correctly in the Markdown preview pane. [IJPL-251259]
• The PlantUML extension has been updated to version 1.2026.6, enabling support for its latest features. [IJPL-253366]
• Applications running in Debug mode with WSL2 mirrored networking no longer become unresponsive and can be stopped as expected. [IDEA-355585]

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

Java 27 delivers nine JEPs, four of which are final. In addition, four preview features continue to mature and one JEP continues as an incubator feature.

Even if you’re not using IntelliJ IDEA, you can still get its intelligence elsewhere: IntelliJ IDEA Goes LSP: Java and Kotlin Intelligence Comes to VS Code, Cursor, and Agentic Flows. This provides the same level of support for the latest Java versions and features, including early access versions and preview features.

For this blog post, let’s start by setting up IntelliJ IDEA to use the latest Java version.

Using Java 27 in IntelliJ IDEA (setup) 

First, you will need to download JDK 27. There are several ways to do so; you can download it from inside IntelliJ IDEA, using tools like SDKMAN! or asdf, or install it yourself.

Downloading the JDK

To download JDK 27 from IntelliJ IDEA, open the Project Structure, go to the tab Project Settings | Project, open the drop-down menu in the SDK field, and select Download JDK. In the Download JDK popup that opens, set Version to 27, and in the Vendor field, select the vendor you want to use.

If you have already installed the JDK, you can point IntelliJ IDEA to your installation. Instead, select Add JDK from Disk from the drop-down menu.

The JDK version will be automatically propagated from your project settings to the terminal, which means that both you and your agent can use the right JDK for your project on the terminal in IntelliJ IDEA. A demo of this feature was shown in the What’s New in IntelliJ IDEA 2026.2 video.

If you use SDKMAN! or asdf to manage your JDKs, IntelliJ IDEA can read the .sdkmanrc or .tool-versions file in your project and can configure the JDK automatically if you already have it installed.

If you’re using SDKMAN! and the JDK version specified in the .sdkmanrc file is not yet installed, an inlay hint will appear in the file, allowing you to download it directly from the IDE by running the relevant SDKMAN! command. This even works if you don’t have SDKMAN! installed, which means this functionality is also available for Windows users.

For more information on how to set up the JDK, see the documentation.

Setting the language level

IntelliJ IDEA supports Java 27 from day one. In the Project Structure, set the Language level to 27 – No new language features.

If you’re using preview features, set it to 27 (Preview) – Primitive types in patterns, instanceof, and switch (5th preview). Note that IntelliJ IDEA will highlight the usage of preview features in the editor, so that you are aware of exactly where you’re using preview features.

New stable features in Java 27

Java 27 introduced 4 new stable features. Let’s take a quick look.

JEP 523: Make G1 the default garbage collector in all environments

The Garbage-First (G1) garbage collector has been the default garbage collector since Java 9, with one exception: Machines with only one CPU or less than 1,792 MB of RAM fell back to Serial GC. This JEP makes G1 the default garbage collector for the HotSpot JVM in all environments, not just server environments, replacing the Serial collector.

Improvements were made to the G1 garbage collector (including JEP 522: G1 GC: Improve Throughput by Reducing Synchronization in Java 26) so that its performance is now sufficient to replace Serial. For applications in constrained environments that perform better with Serial, it can be explicitly enabled with the option `-XX:+UseSerialGC`.

JEP 527: Post-quantum hybrid key exchange for TLS 1.3

This JEP enhances the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms for TLS 1.3. This helps guard against “harvest now, decrypt later” attacks, where an adversary records encrypted traffic today with the intention of decrypting it once quantum computers are powerful enough.

JEP 534: Compact object headers by default

This JEP makes compact object headers the default object header layout in the HotSpot JVM.

By reducing object headers from 96 bits to 64 bits on 64-bit architectures, compact object headers reduce heap size, improve deployment density, and increase data locality.

Compact object headers were introduced as an experimental feature in Java 24 and became opt-in in Java 25. Since compact object headers are now the default, you no longer need to enable them using a command line option, like with JDK 25. 

Applications with large numbers of objects will benefit from this change, as using compact object headers reduces the JVM memory footprint. JetBrains IDEs are using this feature and have observed consistent memory savings with it enabled. Learn more.

JEP 536: JFR in-process data redaction

This JEP enhances the JDK Flight Recorder (JFR) by redacting command-line arguments and the initial values of environment variables and system properties in recordings before it leaves the process, so sensitive information does not leak.

Preview features in Java 27

Preview features give developers a chance to try new features and provide feedback before they become final. Preview features might go through multiple rounds, either with or without changes, before they are finalized and become a standard part of the language.

IntelliJ IDEA strives to support preview features, so you can experiment with them before they become standard. Because these features are always subject to change, IntelliJ IDEA only supports preview features for the current JDK. To enable preview features, set Language level to 27 (Preview) – Primitive types in patterns, instanceof, and switch (5th preview).

Java 27 contains four preview features and one incubator feature. The features themselves are the same as in Java 26, but some of them have been revised in Java 27. 

JEP 531: Lazy constants (third preview)

Lazy constants are objects that hold immutable data. As the name suggests, they are evaluated lazily. This offers advantages over final fields, which are evaluated eagerly. With lazy constants, fields are evaluated only when needed, which can improve startup time.

For a slightly more detailed explanation, see the section on Lazy Constants in Java 26 in IntelliJ IDEA.

Lazy constants were first introduced in Java 25 (as stable values) and underwent significant  changes in Java 26. The API has been revised further in Java 27.  

JEP 532: Primitive types in patterns, instanceof, and switch (fifth preview)

As described in Java 26 in IntelliJ IDEA, this feature enhances pattern matching to support all primitive types in pattern contexts, including instanceof and switch. The feature removes some of the existing limitations of pattern matching, making it possible to match, test, and safely convert primitive values in these constructs. Removing the need for unsafe manual casts (which might cause subtle bugs) and range checks leads to improved code safety and readability. This feature is still in preview in Java 27, with no changes from the Java 26 version.

A quick example

Let’s look at a quick example of using primitive types in switch expressions with guard patterns.

int itemDiscountPercentage(int items) {
   return switch (items) {
       case 2 -> 5;
       case 3, 4 -> 10;
       case int i when i >= 5 -> 20;
       default -> 0;
   };
}

We can add Javadoc to this method to explain how it works. As of Java 23 (JEP 467), Javadoc can be written in Markdown. If your project uses JDK 23 or later, IntelliJ IDEA will insert Markdown documentation comments by default when you use the context action Add Javadoc.

Sidenote: If you prefer to use traditional comments instead of Markdown, open Settings, go to Editor | Code Style | Java | Code Generation | Comment Code, and deselect the Prefer documentation line comments option.

IntelliJ IDEA can convert existing Javadoc to markdown using the context action Convert to Markdown documentation comment.

You can find a more detailed explanation of this feature in this section of Java 23 and IntelliJ IDEA.

JEP 533: Structured concurrency (seventh preview)

As described in Java 26 in IntelliJ IDEA, structured concurrency gives us better “idioms” for multithreaded code, which means the code more closely matches the user’s mental model. 

Structured concurrency treats groups of related tasks running in different threads as single units of work. This improves readability and observability, making concurrent code easier to understand and reason about. It also helps eliminate thread leaks and cancellation delays. 

For more details on structured concurrency and how it works together with other features from project Loom, please see my previous blog post, Project Loom in IntelliJ IDEA: Virtual Threads, Scoped Values, and Structured Concurrency.

As mentioned in that blog post, there is a live template for quickly scaffolding a StructuredTaskScope. You can pull up a list of available live templates in IntelliJ IDEA using the shortcut (⌘J on macOS / Ctrl+J on Windows and Linux). Alternatively, you can use command completion: Type .. – and a list of all commands relevant to your current context will appear. You can even type part of the name of the command (for example “live” for Show live templates), and the relevant command will show up as part of regular completion. 

The list of live templates is searchable, both by name and description. If we search for “structured”, we will find the live template sts.

For more information on command completion, see my previous blog post, Universal Entry Point: A Single Entry Point for Context-Aware Coding Assistance.

JEP 538: PEM encodings of cryptographic objects (third preview)

As described in Java 26 in IntelliJ IDEA, this JEP provides a preview API for encoding and decoding cryptographic objects (keys, certificates, and certificate revocation lists) to and from the Privacy-Enhanced Mail (PEM) format.

The API has undergone further changes in Java 27 compared to the previous version.

Incubator features in Java 27

Incubator modules are experimental APIs. They are explicitly non-final APIs and tools, made available for developers to try out. Unlike preview features, incubator features may change significantly, or even be removed in future releases. They are not intended for production use.

To use an incubator feature, you’ll need to explicitly add the module while you run the code, by adding the --add-modules command-line option for that specific module.

If you are running the code from IntelliJ IDEA, you can add command line options to the run configurations for your application. Select the run configuration for your program and click the three dots for More Actions. Select Edit to open the Run/Debug Configurations. Click the link Modify Options, and in the Add Run Options popup, select Add VM Options. A new field will appear with the hint VM Options. Add the command line option to that field.

JEP 537: Vector API (twelfth incubator)

As described in Java 26 in IntelliJ IDEA, this JEP introduces an API that allows developers to express vector computations that reliably compile to optimal vector instructions on supported CPUs. Vector operations enable more work to be performed in a single CPU cycle, which can result in significant performance gains.

As this is an incubator module, you’ll have to provide a command line option to add the module explicitly, as described above. To use the Vector API, add the following command line option: --add-modules jdk.incubator.vector.

There are no changes to the Vector API in Java 27, compared to Java 26. This feature will continue to incubate until the required features of Project Valhalla become available as preview features.

Other changes: Debugger improvements

Other than JEPs, JDK 27 contains bug fixes, like JDK-6960970. The debugger was very slow during stepping. This has been fixed in JDK 27, which means that stepping through the debugger is faster now. Our engineers have backported this fix to JetBrains Runtime (JBR) 25, so they can use it when stepping during debugging the code for IntelliJ IDEA itself. This shows that it is possible to backport this change to Java 25 and that the change works correctly. If you want to take advantage of this change, you can use JBR 25 or ask your vendor to backport this change.

Looking ahead

Features from Project Valhalla have started making their way into Java. Both value objects (JEP 401) and strict field initialization in the JVM (JEP 539) have been targeted to JDK 28 as preview features. This means that if you want to try out these features, you no longer have to download a special Valhalla distribution. You can download the JDK 28 EA (Early Access) version. This version is available for download from inside IntelliJ IDEA.

If you have already downloaded JDK 28 EA, you can point IntelliJ IDEA to your installation as well.

Conclusion

While not an LTS release, Java 27 brings security and performance improvements and continues to evolve several important preview features. IntelliJ IDEA supports Java 27 from day one and will continue to support the latest Java features. Please let us know if you have any feedback.

Starting with the 2026.2 release, there is one recommended entry point. In IntelliJ IDEA, WebStorm, and PhpStorm, opening a project that lives in WSL runs the IDE in what we call Native mode. The IDE stays a Windows application, while a small agent inside WSL handles files and processes on its behalf.

Below is how Native mode works, how our approach to WSL integration evolved to get here, and – since we tried three other approaches first – why we’re confident it’s the right foundation for your work.

What it takes to support WSL in an IDE

We’ll start with an idealized picture in which the IDE functions seamlessly inside WSL while being operated from Windows. In practical terms, “seamlessly” means you should be able to use any of the IDE’s capabilities – terminal, run and debug configurations, profiling, etc. – against a project that resides in a Linux environment. Not only that, but this must incur as little latency as possible for the coding experience to feel quick and natural, as if the project files and the IDE itself resided in a single operating-system environment.

We’ll trace how this challenge has been addressed, beginning with the earliest implementation, in which the IDE interacted with WSL through the 9P transport protocol. We will then cover Remote Development and WSLg before examining Native mode – the currently preferred mode for how IDEs work with WSL.

Toward native IDE execution in WSL

9P filesystem access and GeneralCommandLine

For the IDE to function, it needs access to the basics of a project, which are plain files. This is where the 9P filesystem protocol comes in. It provides the mechanism that allows Windows-side processes access files inside WSL. In practice, project-related file I/O performed by the IDE – scanning, indexing, archive access, and similar operations – is routed through the 9P-based filesystem layer to the Linux virtual machine.

Once file access is accounted for, the next challenge is process execution. While running on Windows, the IDE must be able to invoke tools inside WSL with the correct Linux paths, working directories, executables, environment variables, and arguments. The IDE-internal GeneralCommandLine class manages this by normalizing command execution in the WSL environment.

While this architecture enables the IDE to operate against WSL, it introduces significant trade-offs in both file access and process execution.

The 9P protocol is known to be problematic for several reasons:

• Limited symlink handling – 9P does not properly expose Linux symbolic links to Windows through \\wsl$. As a result, the IDE may detect an entry but be unable to resolve or index the linked directory tree. This affects pnpm workspaces, Python virtual environments, PHP Composer path repositories, and other environments that rely on symlinks.
• Microsoft Defender scans – on-access scanning over 9P can stretch WSL file reads by tens of seconds.
• Latency and degraded throughput – 9P-backed filesystem access adds latency, and throughput can degrade significantly, especially in workflows involving many small files. Core IDE operations such as indexing follow this pattern, generating numerous separate requests that cross the Windows/WSL VM boundary through 9P.

The situation was no less challenging on the GeneralCommandLine side. The pipeline added a maintenance burden, as developers had to account for WSL-specific execution semantics across the codebase.

As a consequence, the approach became increasingly difficult to scale and maintain, and it surfaced persistent issues with symlink handling and performance.

Running the IDE inside WSL with WSLg

What if, instead, the IDE itself resided inside WSL, close to the project it works with? This is where WSLg comes in. It provides a way to run Linux GUI applications whose visual output is integrated directly into the Windows desktop.

Here’s why we do not recommend the WSLg approach:

• From a product perspective, if the IDE is displayed on Windows, it is preferable for it to behave as a Windows-native application rather than as a Linux GUI application projected into the Windows desktop. This preserves greater control over the IDE experience and avoids dependence on an additional GUI-remoting layer.
• In a WSLg setup, the IDE may run on the native Wayland path, where JetBrains Runtime uses WLToolkit against WSLg’s Wayland compositor. This path carries known limitations in rendering, popups, window management, input methods, and desktop integration.

No first-class product experience was ever built around this setup. Although running the IDE through WSLg is technically viable, it has never been considered the preferred direction, and no dedicated out-of-the-box installation or onboarding flow was provided. It remains an ad hoc workaround rather than a supported IDE workflow.

The Remote Development approach

Another approach was Remote Development, which addressed the same fundamental challenges of file access and process execution from a different angle. Rather than extending the Windows-based IDE across the WSL boundary, it moved the IDE backend into WSL and kept only the client on Windows. This architecture solved the underlying integration problems more directly, but introduced a different set of trade-offs.

The main technical challenge of this configuration is establishing and maintaining communication between them while ensuring that the UI accurately reflects user actions and the IDE continues to function as a coherent whole. At the same time, placing the backend inside WSL provides the clear advantage of direct access to Linux files and processes.

In this setup, the two IDE parts communicate over the JetBrains RD protocol. The protocol is a structured, bidirectional stream of IDE models and events that keeps the thin client and the backend IDE logically in sync, while all heavy work, such as indexing, analysis, builds, debugging, VCS operations, and so on, happens on the backend.

The client, in its turn:

• Renders all windows and editors, and handles user input.
• Mirrors the project and editor state it receives from the backend over the RD protocol, and sends back edits, caret moves, refactoring commands, debug actions, and so on.
• Loads UI-level plugins.

The elephant in the room, however, is the cost of this split architecture. The IDE backend is a heavyweight component in its own right, requiring roughly 2 GB of additional disk space and time to download and install inside WSL. The split also introduces an inherent performance penalty, as UI-event state, user input, and other interaction data must travel continuously between the local client and the backend.

It also adds development overhead, as the code has to be split into client and server parts. Leaving specific modules undivided can cause delays and freezes in highly dynamic UIs. The associated engineering effort therefore becomes a constant and unavoidable cost.

Native mode and the IJent agent

The current design – now integrated into most of our IDEs – represents the culmination of this work and addresses many of the shortcomings of earlier approaches to WSL.

To provide access to the Linux filesystem, processes, and other environment resources without relying on 9P, GeneralCommandLine, or other second-class communication mechanisms, we developed a small agent named IJent. Because it is designed specifically for IDE scenarios, we can shape its behavior, protocol, and capabilities according to our requirements.

Together, the IDE and IJent form a client–server pair. This may resemble the Remote Development model, but the server component is much thinner and, at the same time, more versatile. Installing IJent into a WSL environment is merely one of several possible configurations; the same model can also apply to Docker and Dev Containers.

By choosing this particular technology stack, we address a broad set of concerns:

• Rust implementation – Rust keeps the executable slim. By avoiding Java/Kotlin for the agent, we eliminate additional runtime dependencies inside containers or WSL.
• Transport layer – Stdio gives us a portable, firewall-friendly transport across all environments. Hyper-V sockets on WSL offer a faster path, which is especially beneficial for large or numerous filesystem transfers.
• Correct filesystem semantics – IJent executes filesystem operations on behalf of the IDE inside the target environment. As a result, path resolution, including symbolic links, follows correct Linux semantics rather than being mediated through 9P. Third-party plugins also benefit from this model, since their file operations are routed through IJent.

EelApi: one interface for any environment

For the IDE to fully benefit from IJent, changes on the IDE side are also required. Enter EelAPI.

EelApi is an API designed to abstract away the distinction between local and remote environments for everyone writing IDE-related code – plugin authors and platform contributors alike. With EelApi, the underlying environment against which the IDE operates should no longer matter, removing the need to account for these concerns explicitly in code. In this sense, EelApi is platform-agnostic, and the IDE can remain unaware of whether it is working locally, in WSL, in Docker, or in a Dev Container.

In general, IJent implements the EelApi interface, providing the actual functionality that EelApi exposes to the IDE and plugins.

If you’re interested in a more detailed explanation of EelApi, together with a practical introduction to the topic, head over to the article The Dev Containers Story: Introducing EelApi for Plugin Authors.

What this means in practice

There are two ways to open a WSL project today:

• Opening the project directly gives you Native mode in IntelliJ IDEA, WebStorm, and PhpStorm, and more IDEs are adopting the IJent and EelApi architecture as we speak.
• The Remote Development entry point on the Welcome screen still works, but it is no longer the recommended way to open a WSL project.

We conducted performance tests in order to compare 9P mode and Native mode. The results show a clear performance gain in favor of the new approach:

Beyond performance, this architecture places development in WSL within the broader context of development in non-local environments, allowing them to be approached through the same underlying model. The same IJent agent already backs our work on Docker and Dev Containers.

Thank you for reading and for all the feedback that helped us reach this point. Tell us how Native mode holds up against your projects in the comments below.

At that point, the bug you were trying to catch is no longer the only problem. Now, you need to answer different questions:

• Which roles or authorities does the endpoint require?
• Should I just disable the security temporarily to debug the logic behind it, maybe?

Security inlays in IntelliJ IDEA are designed for that moment. Instead of updating SecurityConfig temporarily and restarting the app, or fiddling with the authentication in the HTTP test tool, you can inspect and adjust the runtime security right inside the IDE.

See What the Endpoint Requires

When a secured endpoint blocks a request, the first question is “which roles does the running app require right now for this endpoint?”

The inlay displays the role-based requirement for an endpoint – the hasRole / hasAuthority-shaped matchers that most HTTP authorization is built from. However, not every security rule can be displayed with a roles list. For example, rules defined in code in a custom AuthorizationManager show up as unknown – a single lock icon, without roles.

Seeing the actual endpoint security state is important in real Spring applications. Authorization can depend on multiple SecurityFilterChain beans, matcher order, active profiles, and conditionally registered configurations. Reading SecurityConfig classes you can find is not always the same as knowing what the running application requires.

If the roles list isn’t what you expected to see, you still need to read SecurityConfig classes anyway. So, the inlay provides a config link to the real security configuration code behind the endpoint.

Unlock the Endpoint for the Current Debug Session

When you figure out which roles the endpoint requires, the next question is: “Should I skip endpoint authorization, or resend the request with a specific authority set?” Both options are available within the unlock action in the inlay popup.

Read this before you click Unlock. Unlock acts on the running process itself, not just on requests sent from the IDE. Any client hitting that exact URI and method is affected: curl, Postman, a browser, etc. If the debugged app is reachable on your network, any request to that exact URI and method is treated as authenticated with the authorities you granted – for anyone. Unlock endpoints carefully, and re-lock or restart when you are done.

Since unlocking is a security-affecting action, it is worth mentioning what it opens and for how long:

• Scope – applies to the exact request URI and HTTP method. The concrete URI comes from the request you’re working with when you unlock – the failing request in your .http file, browser, or curl command. Unlocking GET /admin/users/42 in the IDEA HTTP Client leaves POST /admin/users/42 and GET /admin/users/99 blocked. Unlocking @GetMapping("/admin/users/{id}") in the controller code will unlock the endpoint for any {id} value.
• Layer – covers HTTP endpoint authorization only; method-level checks such as @PreAuthorize are evaluated separately (see “What Unlock Does Not Cover” below).
• Lifetime – lasts only for the running debug session, or until you lock the path again. Restarting the app clears every unlock. Both a full JVM restart and a Spring Boot DevTools in-process restart work. The unlocked paths and their authority sets live on the session and go with it.
• Persists – nothing in the app. The only thing kept is IDE-local: the username you last impersonated, per endpoint, to pre-fill on re-unlock.

So, depending on your tasks, you can do the following using the security indicator inlay:

Simple Unlock

Sometimes security is not what you are testing. You already know the endpoint is protected, but you need to reach the logic behind it. Unlocking treats the request as authenticated with the full set of roles that the endpoint requires, for that URI and method. Spring Security just sees an identity that passes and you can continue the debugging task you were doing. This is the right mode when the real tasks are:

• validate request or mapping logic in the controller;
• debug a service behind a protected route;
• a smoke test that is blocked by a local authentication setup;
• a bug reproduction you do not want to interrupt with config edits and restarts.

If the IDE cannot evaluate the roles list for the endpoint, this functionality is not available. For this case, use…

Unlock with custom authorities

The inlay popup menu also allows you to specify a username and a custom role list. Treat this as a way to test a specific authority set. It lets you check authority-based behavior behind the endpoint without creating a real account, changing test data, or going through a full SSO or token flow.

For example, you can enter the username admin with ROLE_ADMIN, ROLE_MANAGER authorities in the popup. Resend the request, and answer questions like:

• Does the controller return the expected data when the request has specified authorities?
• Is the problem in the controller logic, or in the authority set used for the request?
• How does downstream code – branching, data filtering, authority checks – behave for this exact authority set?
• Does the audit engine record a proper username – admin?

When you perform either of these actions, the request runs with an artificial Authentication in the SecurityContext, created inside the running application by the debugger with the username and roles you chose. Code that reads the authority set – via hasRole / hasAuthority checks, SecurityContextHolder.getContext().getAuthentication(), or a Principal / Authentication method parameter – sees the authorities provided by IntelliJ IDEA.

One thing to watch for: a controller parameter annotated with @AuthenticationPrincipal does not resolve for inlay-unlocked requests – it comes back null. This is a known bug, IDEA-389767, which is open and affects 2026.2 as of this writing – check it for the current status. (See “How Unlocking Works Under the Hood” below for why.)

Compared with the usual local workarounds – a permitAll dev profile, a mock authenticator, a commented-out filter – nothing rebuilds or restarts the app, and nothing stays in configuration code that could accidentally get into a production environment.

How Unlocking Works Under the Hood

Is unlocking a backdoor, or a CSRF bypass? Neither – unlock doesn’t disable or suspend anything. It treats the request as authenticated with the authorities you granted, for that exact URI and method, and lets Spring Security evaluate it from there.

If your app enforces CSRF tokens on state-changing requests, CsrfFilter runs earlier in the chain and still rejects a POST / PUT / DELETE with a missing or invalid token. So, you still need a valid token, or a CSRF-exempt setup, separately.

Unlocking is a debug-time feature. Please note that it’s an internal mechanism, not a public IDE API.

On application startup, the debugger places a hidden, non-suspending breakpoint at Spring Security’s own AuthorizationFilter – the exact spot where Spring decides whether a request is allowed. After Spring application context initialization, the IDE reads the effective HTTP authorization rules. Instead of parsing your source, the debugger reads the live SecurityFilterChain out of the running JVM to figure out what each endpoint requires. That is why the inlay shows the actual list of authorities at the HTTP layer. Clicking Unlock adds the URL, username, and roles to a set the IDE keeps for the debug session. The application code and security config are untouched.

The rest of the work happens per request, without pausing anything. When a request hits an “unlocked” URL, the execution flow passes the non-suspending breakpoint in the AuthorizationFilter. If the URL is in the “unlocked” list, the debugger adds a TestingAuthenticationToken instance to Spring’s SecurityContext. This auth object is already marked as authenticated, with the chosen username as principal and the “unlock” roles as granted authorities. Then the request goes on. Later the authorization engine reads the security context, sees the supplied authenticated principal, and evaluates it normally. For any URL you did not unlock, the breakpoint evaluation returns immediately and normal security applies.

The principal used in the auth object is the plain username String, not your app’s UserDetails or other custom principal type. That’s why a controller parameter annotated with @AuthenticationPrincipal (or any custom principal class) does not resolve for inlay-unlocked requests, as mentioned in the “Unlock the Endpoint for the Current Debug Session” chapter.

You can inject the auth object as a controller method parameter, since the artificial auth object is available through the SecurityContextHolder. So the following code should work fine:

@GetMapping("/active")

    ResponseEntity<List<Member>> getAllActive(Principal principal) {

        log.info("Auth Principal Name: {}", principal.getName());

        //...

    }

Please note that those parameters need to be declared as the base type for TestingAuthenticationToken: Principal or Authentication, not a concrete subtype. A parameter typed as JwtAuthenticationToken, for instance, throws an IllegalStateException at request time instead of resolving, because Spring MVC checks that the real principal – the injected TestingAuthenticationToken – is actually an instance of the declared type. That’s a more visible failure than @AuthenticationPrincipal‘s silent null, though the root cause is the same type mismatch. Code that depends on a concrete principal object type, token subtype, claims, credentials, or session-backed identity may still behave differently or even fail for unlocked endpoints.

Unlock hooks AuthorizationFilter, the filter behind authorizeHttpRequests and the AuthorizationManager API. This API is available since Spring Security 5.x and the non-deprecated path in 6.x. If your configuration still uses the older authorizeRequests / FilterSecurityInterceptor, that filter never runs, so unlock does not apply.

Security inlays are turned on by default, and only work while the Spring Debugger is active. You can turn them off with the spring.debugger.security.enabled flag in IntelliJ’s Registry (open it with Find Action → Registry…). Security inlays also work with a remote JVM, including a shared or staging environment. Please note that there is no log message and no actuator indicator if someone has unlocked an endpoint on the remote application. The only way to check is to look at the inlay in the editor of the attached IDE.

What Unlock Does Not Cover

Unlock works with HTTP endpoint security: rules like SecurityFilterChain URL matching, and requestMatchers() method calls. It only works on the Servlet stack, where the breakpoint is added to Spring Security’s AuthorizationFilter. It means Spring WebFlux is not supported. It uses a different class instead, AuthorizationWebFilter, which unlock does not hook (yet).

Right now, there is also no support for method-security annotations, such as:

• @PreAuthorize;
• @PostAuthorize;
• @Secured.

There is no inlay for them, no way to see what they require, and no unlock action that targets them directly.

However, the same injected Authentication is what a method security interceptor reads too. If a service method is guarded by @PreAuthorize and the authorities you injected on an unlocked endpoint satisfy it, that check passes.

Let’s have a look at the small example:

@RestController
class UserController {

    @GetMapping("/admin/users/{id}")
    public User getUser(@PathVariable Long id) {
        return userService.findUser(id);
    }
}

@Service
class UserService {

    @PreAuthorize("hasRole('ADMIN')")
    public User findUser(Long id) {
        // ...
    }
}

@Configuration
@EnableMethodSecurity
class SecurityConfig {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.authorizeHttpRequests(authorize -> authorize
                .requestMatchers("/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated());
        return http.build();
    }
}

When you unlock GET /admin/users/{id} as ROLE_ADMIN, the call from UserController into UserService.findUser also passes the @PreAuthorize check – not because unlock targets it directly, but because the method-security interceptor reads the same SecurityContext the breakpoint already populated.

One Unlock, Several Clients

A request can come from several places: an IntelliJ IDEA .http file, a curl script, a Postman collection, or a test suite hitting your locally debugged app. If the request is rejected, don’t spend time switching to another HTTP testing tool.

For requests sent from the built-in IntelliJ IDEA HTTP Client, the security inlay sits right near the request URL in an .http file, so you don’t even need to switch to the controller code. For external clients, you’ll need to open the controller code, unlock the endpoint, and re-run the same curl or Postman request.

A Note for Automated and AI Workflows

In IntelliJ IDEA 2026.2, unlock is available in the inlay in the editor or in the .http file – it is a manual, in-IDE action. There is no programmatic switch yet, so an external script or an AI agent cannot use it on its own. We’re planning an MCP tool and a related skill that would let an agent get the roles list and perform lock/unlock actions for a selected endpoint directly, without a human in the loop. That’s aimed at the next release, 2026.3.

Until then, unlock the endpoint once from the IDE to let an agent test it. It stays unlocked for the rest of the debug session, so the agent can keep replaying curl, .http, or test requests with no further clicks. The manual step is a one-time setup, so an agent iterating on downstream controller or service logic can run unattended after it.

Conclusion

Security inlays are designed to simplify your (developer’s) life. They show the real security rules for an endpoint, and let you pass them so you can debug more easily. You can see what the endpoint requires and unlock it if needed. The request is then treated as authenticated with the authorities you choose for the debug session. All of this happens without editing SecurityConfig or restarting the app.

By applying unlock, IDEA makes a temporary security change in the running app. It opens the exact URI and method you unlocked to every client that reaches it. If you unlocked a path pattern in the controller code, it opens all paths that match the pattern.

The path stays open until you lock it again or the debug session ends. Please use it carefully, especially on an app with network access.

A few limitations are worth mentioning:

• Servlet only – Inlays and unlock hook Spring Security’s AuthorizationFilter. That filter only exists on the Servlet stack, so WebFlux isn’t supported yet.
• Debug mode only – This feature requires an active debugger session, local or on a remote JVM.
• Principal / Authentication, not a concrete subtype – Declare a controller method parameter as Principal or Authentication. A parameter annotated with @AuthenticationPrincipal comes back null. A parameter typed as a concrete subtype, like JwtAuthenticationToken, throws an error instead, because Spring MVC checks that the injected object matches the declared type.

The inlays are part of the Spring Debugger plugin for IntelliJ IDEA Ultimate, available since the 2026.2 release.

Our featured writer, Aicha Laafia, takes a closer look at upcoming JEPs and shares her key findings on what may be next for Java. Let’s dive in!

Featured Content 

Aicha Laafia

Aicha Laafia is a Java software engineer at SQLI with a love for coding, an interest in sustainability, and a commitment to empowering women in tech. She is a Women Techmakers ambassador, an Oracle ACE Associate, and part of the JetBrains Community Contributors program. When she is not coding, she enjoys exploring delicious food, phone photography, and watching Formula 1.

September is here, and so is JDK 27. Nine JEPs if you count the previews, and nothing to rewrite unless you are using preview features. Honestly? That’s my favorite kind of release. You upgrade the version, and your app gets faster.

The features that change your numbers

Compact object headers are on by default (JEP 534). Headers shrink from 96 bits to 64, cutting heap usage by 10% – 20% and pushing throughput up by 5% – 10%. G1 also becomes the default garbage collector everywhere (JEP 523), even on the small machines that used to get Serial GC instead, so check your smallest containers before you upgrade. For the full tour, Sven Woltmann wrote a solid Java 27 breakdown, and if video is more your thing, Catherine Edelveis covers the whole release here.

Two security wins that protect you by default

JFR recordings collect environment variables and system properties, which is exactly where your tokens and passwords live, so Java 27 hides them for you (JEP 536). And TLS 1.3 now gets post-quantum key exchange (JEP 527), because attackers already save encrypted traffic, waiting for quantum computers to break it later. Java 27 makes sure they can’t!

Still on Java 8 or 11?

Don’t jump, hop. Start now, LTS by LTS, and read my article Jurassic JDK: Migrate or Extinct first. I covered everything I wish someone had told me before my first migration.

Enjoy this month’s Java Annotated Monthly!

Java News

See what’s new, changing, and coming next in the world of Java:

• Java News Roundup 1, 2, 3, 4 
• Project Valhalla’s First Preview: JEP 401 Redefines == for Java Objects
• JEP 540 Proposed to Target JDK 28 with a Simple JSON API
• JSON API, Valhalla Progress, LTS ❤️ PQC – Inside Java Newscast #114
• Inside Java Episode 67 “Keeping Up With the Java Release Train” [I/O]
• JDK 27 and JDK 28: What We Know So Far
• Announcing Oracle Jipher 10.37: FIPS 140-3 Cryptography for Java
• Evolving a Java MCP Server During MCP Specification Upgrades 

Java Tutorials and Tips

Sharpen your Java skills with practical tutorials, clever techniques, and tips worth trying: 

• Persistence Workflows with IntelliJ IDEA – Andrey Belyaev | IntelliJ IDEA Tech Talks
• Resilient Sync: Your IDE Keeps Helping even when your Build is Broken
• Inside Java Episode 65 “Embracing Virtual Threads with Helidon” [I/O]
• Introduction to Retrieval-Augmented Generation with Java and MongoDB
• The Power of JDK Flight Recorder: Efficient Profiling and Troubleshooting for Java Applications
• Security Baked Into the JVM: sixteen Subjects on the wire 
• Value Classes Still Need Compiler Sympathy
• Inside Java Episode 68 “Operator Overloading with Type Classes” [AtA]
• Why is Arrays.fill 265 times slower on G1GC?
• Beyond Virtual Threads: Structured Concurrency – Balkrishna Rawool | IntelliJ IDEA Tech Talks

Kotlin Corner

Step into Kotlin Corner for fresh updates:

• When Escape Routes Become Toll Roads: Mapping How Developers Move Between Programming Languages 
• KotlinLLM is Going Open Source 
• Introducing the Kotlin Benchmark for AI Coding Agents 

AI 

Catch up on the AI ideas, tools, and experiments shaping how developers build software:

• IntelliJ IDEA Goes LSP: Java and Kotlin Intelligence Comes to VS Code, Cursor, and Agentic Flows
• JetBrains Details its First Steps to Bring Rapidly Growing AI Spend under Control
• Jakarta Agentic AI Hits Its First Milestone
• MCP Goes Stateless, and Developers Ask Whether That Just Makes it an API Again
• Top 5 AI Features in IntelliJ IDEA
• Agent Skills in IntelliJ IDEA
• Lessons Learned from Fixing Flaky Tests with Claude 
• The reality of AI in the enterprise
• How to Use AI Agents in IntelliJ IDEA With ACP
• Java Enterprise Is Already Ready for the AI Era
• Spring Office Hours Podcast: S5E20 – The Developer’s Guide to AI with Danny Thompson
• How to accelerate agentic adoption 

Languages, Frameworks, Libraries, and Technologies

Explore what’s moving and shaking across languages, frameworks, libraries, and the wider tech landscape:

• This Week in Spring 1, 2, 3, 4
• Pods as Workers, Not Agents: Rethinking the Deployment Unit for AI Agents on Kubernetes
• Gradle Is Going Agentic
• When @Immutable Made All the Difference: A 3.2x Speedup with Hibernate Second-Level Cache 
• Vibe Coding, Maven, and the Dependencies You Didn’t Choose

Conferences and Events

Mark your calendar with the conferences, meetups, and events worth showing up for:

• Kansas City Developer Conference – Kansas City, USA, September 9–12
• JCConfTaiwan – Taipei, Taiwan, September 11
• Java Forum Nord – Hannover, Germany, September 22
• JUG Saxony Day – Radebeul, Germany, September 25
• Confitura – Warsaw, Poland, September 25–26
• GOTO Copenhagen – Copenhagen, Denmark, September 28 – October 2

Culture and Community

Check out these stories about what makes the developer community tick.

• The Five Stages of AI Maturity in Engineering Organizations – Where and Why Teams Get Stuck
• From Projects to Products: Turning Platforms into Products People Use
• When Escape Routes Become Toll Roads: Mapping How Developers Move Between Programming Languages
• Culture & Methods Trends 2026: The Human Side of AI Engineering
• More Incidents Don’t Necessarily Mean Less Reliability
• What Is Reasoning
• How Code in the Age of Artificial Intelligence Becomes Write-Only and Disposable
• The Human Edge: Why Brownfield Codebases Need Mob Programming, Not Just AI Vibes
• Fast and Hard Code

And Finally…

Check out the latest articles by the IntelliJ IDEA team:

• The Grails Plugin Has a New Home: Apache Grails
• Println Debugging Done Right
• Spring Boot Configuration Management Best Practices
• Project Loom in IntelliJ IDEA: Virtual Threads, Scoped Values, and Structured Concurrency

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 September 20. Remember to check out our archive of past JAM issues for any articles you might have missed!

You can update to this version from inside the IDE, using the Toolbox App, or by using snaps if you are a Ubuntu user. You can also download it from our website.

IntelliJ IDEA 2026.2.2 brings the following refinements:

• Loading a remote OpenAPI specification no longer fails. [IJPL-63202]
• The order of terminal tabs is now preserved after reopening a project. [IJPL-212254]
• Checkboxes in Markdown now have improved contrast for better visibility. [IJPL-93391]
• The vertical scrollbar is once again displayed correctly in the Markdown preview pane. [IJPL-251259]
• Opening directories containing a large number of .md files no longer causes the IDE to freeze. [IJPL-93385]
• Spring Modulith no longer incorrectly reports accessibility violations for types exposed through @NamedInterface in nested modules. [IDEA-376940]

To see the full list of issues addressed in this version, please refer to the release notes. 

If you encounter any bugs, please report them using our issue tracker. 

Happy developing!