• Property files
• Environment variables
• System properties
• Command-line arguments

In this article, we’ll explore the best practices for managing Spring Boot application configuration.
A well-designed configuration strategy should ensure that:

• Configuration remains separate from the application code.

• The application fails to start when the required configuration is missing or invalid.

• Default values can be overridden for each deployment environment.

• Sensitive values are supplied by a dedicated secrets management system.

Configuration properties classification

Typically, Spring Boot application configuration falls into three categories:

• Application defaults: Safe, non-secret values such as third-party service URLs, timeouts, and retry limits. Store these with the application.

• Deployment configuration: Values that identify an environment, such as database hosts, queue names, and external service URLs. Supply these through the deployment platform.

• Secrets: Passwords, API keys, certificates, and private keys. Store these in a dedicated secrets system.

For example, application.properties can provide application default configuration properties:

app.promotion-service.base-url=http://localhost:8181
app.promotion-service.timeout=3s
app.promotion-service.retries=3
logging.level.com.jetbrains=DEBUG
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.open-in-view=false

A default value should be safe for every environment in which it may be used. Properties such as database URLs and credentials should never be hard-coded in the application code. If a required value has no safe default, validate its presence during startup.

Use @ConfigurationProperties for binding application properties

Spring applications can access configuration values through Environment, @Value, or @ConfigurationProperties.

Use Environment when property names must be resolved dynamically or infrastructure code needs direct access to property sources.

Use @Value for isolated values:

PromotionService(
  @Value("${app.promotion-service.base-url}") String baseUrl,
  @Value("${app.promotion-service.timeout}") Duration timeout,
  @Value("${app.promotion-service.retries}") int retries) {
    this.baseUrl = baseUrl;
    this.timeout = timeout;
    this.retries = retries;
}

Scattered @Value expressions make property names difficult to discover, validate, and refactor. A dedicated configuration type using @ConfigurationProperties supports all these features.

For related configuration properties, prefer @ConfigurationProperties. It provides:

• Type-safe binding and conversion
• Relaxed binding between property names and Java members
• Group-level validation
• IDE completion and navigation through generated metadata

For example, if we are integrating with a third-party REST API, we may want to configure the service base URL, timeout, and number of retries.

app.promotion-service.base-url=${PROMOTION_SERVICE_URL}
app.promotion-service.timeout=${PROMOTION_SERVICE_TIMEOUT:3s}
app.promotion-service.retries=3

In the above configuration, we are setting base-url value from the environment variable PROMOTION_SERVICE_URL and timeout value from the PROMOTION_SERVICE_TIMEOUT environment variable with a default value of 3 seconds.

Spring Boot supports setter-based binding. You can bind properties to a class that uses setters as follows:

@ConfigurationProperties(prefix = "app.promotion-service")
public class PromotionSvcProperties {

    private String baseUrl;
    private Duration timeout;
    private int retries;

    // Setters and getters
}

Register configuration types using @ConfigurationPropertiesScan:

@SpringBootApplication
@ConfigurationPropertiesScan
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

The @ConfigurationPropertiesScan annotation scans for @ConfigurationProperties annotated components and registers them as Spring beans.

Now we can inject PromotionSvcProperties into other Spring beans and access property values.

Prefer Records for @ConfigurationProperties binding

Typically, configuration is normally established during startup and remains unchanged for the lifetime of the application.

For most application configurations, a Java record is the preferred option. It provides immutability out of the box so that their values won’t be modified even by mistake in contrast to class-based binding where you can accidentally invoke a setter:

@ConfigurationProperties(prefix = "app.promotion-service")
public record PromotionSvcProperties(
        String baseUrl,
        Duration timeout,
        int retries) {
}

Spring Boot’s relaxed binding maps canonical kebab-case names such as base-url to the baseUrl field.

Sometimes we may want to bind properties to a bean provided by a third-party library, and we can’t change their source code to add @ConfigurationProperties annotation.

To bind configuration properties directly to a third-party class, declare it as a @Bean and annotate the bean method with @ConfigurationProperties:

@Configuration
public class ClientConfiguration {

    @Bean
    @ConfigurationProperties(prefix = "third-party.client")
    public ThirdPartyClientProperties clientProperties() {
        return new ThirdPartyClientProperties();
    }
}

You can configure the third-party.client properties as follows:

third-party.client.base-url=https://api.example.com
third-party.client.connect-timeout=5s
third-party.client.read-timeout=30s

If the third-party class is immutable or not supports setter binding, create your own properties class and use it to construct the third-party object:

@ConfigurationProperties(prefix = "third-party.client")
public record ClientProperties(
    URI baseUrl,
    Duration connectTimeout,
    Duration readTimeout
) {}


@Configuration
@EnableConfigurationProperties(ClientProperties.class)
class ClientConfiguration {

    @Bean
    ThirdPartyClient thirdPartyClient(ClientProperties properties) {
        return new ThirdPartyClient(
                properties.baseUrl(),
                properties.connectTimeout(),
                properties.readTimeout()
        );
    }
}

The wrapper approach is generally preferable because it avoids coupling your application configuration directly to the third-party library’s class structure.

Fail fast, fail early: validate configuration during startup

Configuration errors should be detected on application startup and fail fast if a configuration is missing or invalid. Add @Validated to a @ConfigurationProperties bean and apply Jakarta Bean Validation constraints to its properties.

@Validated
@ConfigurationProperties(prefix = "app.promotion-service")
public record PromotionSvcProperties(
 @NotBlank String baseUrl,
        @NotNull Duration timeout,
        @Min(1) @Max(5) int retries,
        @NotNull @Valid SyncProperties sync) {

    public record SyncProperties(@NotEmpty String cron) {
    }
}

With spring-boot-starter-validation on the classpath, binding or validation failures stop application startup. Validate required values, numeric ranges, nested groups, and other application-level constraints.

Use wrapper types when absence must be distinguished from a Java default. For example, an Integer annotated with @NotNull can identify a missing value, while an int defaults to 0.

Understand property precedence

Spring Boot combines multiple property sources. When the same property appears in more than one source, the source with higher precedence supplies the effective value.

The following simplified order shows the sources most commonly used in application deployments, from lowest to highest precedence:

application.properties/yaml (low-precedence)
           ↓
profile-specific configuration files
           ↓
OS environment variables
           ↓
Java system properties
           ↓
command-line arguments    (high-precedence)

Spring Boot configuration loading precedence matters when troubleshooting a value that differs from the expected configuration value.

Environment variables are widely supported by operating systems, container runtimes, and cloud platforms. Spring Boot derives environment variable names from canonical property names by replacing dots with underscores, removing dashes, and converting the result to uppercase:

app.payment-timeout     -> APP_PAYMENT_TIMEOUT
spring.datasource.url   -> SPRING_DATASOURCE_URL

Determining the effective value of a property can be challenging when it is defined in multiple configuration sources. IntelliJ IDEA can display resolved configuration values as editor inlay hints. Selecting a hint identifies the property source that supplies the value and indicates whether it is overridden by another source, such as an environment variable or a system property.

IntelliJ IDEA also provides navigation between property declarations, @ConfigurationProperties members, and property usages. For custom configuration properties, this support is enhanced by the metadata generated by spring-boot-configuration-processor.

Store secrets in a dedicated system

Do not store passwords, API keys, certificates, or private keys in source control. Use a system such as HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault, or an equivalent platform service.

Ensure that secrets are excluded from logs, error messages, configuration metadata, and publicly accessible management endpoints.

NOTE: In non-production environments, the Actuator env endpoint can help identify the source of an effective property. It should not be exposed publicly because configuration may contain sensitive information.

Recommended configuration management

There is no single configuration-management approach that works for every application. Choose a strategy based on the application’s architecture, deployment environment, and complexity.

Monolith

For a monolithic application, keep shared defaults in the application, use profile-specific files only where necessary, and supply deployment-specific overrides through environment variables. Store sensitive values in a dedicated secret manager.

Containerized workloads

For workloads running in a container platform such as Kubernetes, keep sensible defaults in the application and provide deployment-specific configuration through ConfigMaps. Store secrets separately in a dedicated secret-management system.

Microservices

For a microservices architecture, consider Spring Cloud Config Server to centralize configuration, governance, and versioning. Continue to manage secrets through a dedicated secret-management system.

Summary

Effective application configuration starts with sensible defaults, type-safe @ConfigurationProperties, and startup validation. Keep environment-specific values outside the application, understand property-source precedence, and store secrets in a dedicated secret-management system.

The right configuration strategy should reflect the application’s architecture and deployment environment.

During local development and debugging remotely, IntelliJ IDEA helps reveal the effective configuration by showing resolved property values and their sources, highlighting overrides, and providing navigation between configuration files and bound Java properties.

The key idea is the boundary. IntelliJ IDEA remains the environment where you navigate the project, inspect code, and review changes. Across the ACP connection, each agent maintains its own models, behavior, authentication, and agent-side tools.

This makes the replaceable unit larger than an LLM. An ACP-compatible agent includes the full harness around the model: its planning logic, tools, model-routing behavior, and observability. Because ACP standardizes the boundary between the IDE and the agent, you can swap one agent for another smoothly, without changing how IntelliJ IDEA integrates with it. 

ACP in a nutshell

ACP is often described as the LSP (Language Server Protocol) for coding agents. The analogy works because the integration problem is similar.

Before the LSP, supporting each language meant writing a separate editor integration. The LSP replaced that matrix with a single contract.

ACP applies the same idea to the connection between an editor or IDE and a coding agent. Any ACP-compatible agent can connect without requiring a bespoke plugin or  private API for each pairing.

ACP originated from a collaboration between JetBrains and Zed, with both JetBrains IDEs and Zed targeted as clients from the start.

For local agents, IntelliJ IDEA starts a subprocess and communicates with it via JSON-RPC over standard input and output. During initialization, the IDE and the agent negotiate protocol versions and capabilities. Once connected, prompts flow to the agent, while progress updates, file operations, and permission requests return to the IDE.

Agents can still behave differently under that shared contract. During initialization, each one declares the optional capabilities it supports. Plans, modes, slash commands, session loading, terminal operations, and other features can differ between agents.

ACP carries the interaction between IntelliJ IDEA and the agent. Additional tools and context can reach the agent through MCP (Model Context Protocol), including user-configured servers and the integrated IntelliJ MCP server.

Start with an available agent

IntelliJ IDEA ships with several agents that require no manual ACP configuration, including Codex, Claude Agent, and Junie. Choose one and describe the task you want it to handle.

Each agent has its own workflow style, which may include a planning mode, slash commands, or a particular authentication flow. ACP lets IntelliJ IDEA host that interaction through a shared contract while preserving those differences.

Ask the agent to make a small change. After it edits a file, AI Chat shows the changed file in the conversation. Click it to open the diff in the editor beside the chat and inspect exactly what changed.

That edit-and-review loop is the part worth keeping. If you switch agents later, having the loop inside the IDE prevents you from having to move the project or review changes in a separate tool.

Install an agent from the ACP Registry

The ACP Registry contains additional ACP-compatible agents, together with the metadata IntelliJ IDEA needs to install them.

In IntelliJ IDEA, open Settings | Tools | AI Assistant | Agents and then choose an agent from the registry. The current ACP documentation describes the complete installation flow.

The agent’s configuration view also lets you expose the MCP servers configured in AI Assistant, the integrated IntelliJ MCP server, or both.

IntelliJ IDEA downloads the agent files when you apply the settings. The first session may ask you to authenticate using a method supported by that agent.

The registry also supplies the metadata used for updates and uninstallation. These operations remain in the Agents settings, so adding an agent does not require maintaining another IDE plugin.

Each registry agent retains its own license, service, credentials, and privacy terms. Check these details before granting repository access.

Connect a custom agent with acp.json

Registry agents are intended for broad distribution. An internal agent, however, often has a narrower role and should stay inside the company.

If an internal agent implements ACP, register it in ~/.jetbrains/acp.json. IntelliJ IDEA provides an Add Custom Agent action that creates and opens this file, but you can also edit the file directly.

The configuration below registers a hypothetical company migration agent:

{
  "agent_servers": {
    "Company Migration Agent": {
      "command": "/opt/company/bin/migration-agent",
      "args": ["acp"]
    }
  }
}

Each key under agent_servers becomes the agent’s display name. The command value must contain the full path to the executable that IntelliJ IDEA will start. Place the arguments required to activate that agent’s ACP mode in args; the exact values come from the agent’s documentation.

Use env when the process needs environment variables. Many agents expect you to authenticate through their CLI first and reuse credentials stored in the agent’s user configuration. If an agent accepts an API key through env, follow its documentation and avoid committing the file or its secrets to a repository.

Save acp.json and then select the configured agent in IntelliJ IDEA.

If any ACP-compatible agents are already installed on the machine, the IDE will detect them and offer to add them to the configuration.

Why use more than one agent?

Teams may want different agents for different kinds of work. ACP gives those agents a common way to connect to IntelliJ IDEA:

• Connecting an ACP-compatible agent through `acp.json` avoids developing and maintaining a separate IntelliJ IDEA plugin.
• Navigation, editing, and diff review remain in IntelliJ IDEA while developers choose the agent for the work.
• If an agent’s service or model provider is unavailable, developers can switch to another configured agent and continue working in the same IntelliJ IDEA project.

Keep the IDE, choose the agent

Use an agent already available in IntelliJ IDEA, install one from the ACP Registry, or register an internal agent in acp.json.

ACP turns the coding agent from an IDE commitment into a replaceable choice you can revisit at any time.

Some of those features are easy to miss because they are built into existing IDE actions: editing code, generating code in place, explaining selected code, working with stack traces, writing commit messages, and choosing which model or agent should handle a task. This overview focuses on five AI features in IntelliJ IDEA that are worth knowing about, with a few additional capabilities explained at the end. The list starts with one that can help before you even open the chat.

1. AI completion

You change a line, and the IDE points out the next line that needs to be changed to match. Rename a field, and it walks you to the other places that reference it, one keystroke at a time. Press Tab to jump to the spot, and Tab again to accept the edit. Ordinary completion guesses what should follow directly under your cursor. This type looks a step ahead, at the edit you haven’t made yet.

It runs on JetBrains’ own models, tuned for coding, and it stays out of your way. Fix the spacing after one comma in a parameter list, and it will offer to fix every other comma in the file. On a larger scale, this is also where full-method generation is handled – the editor has enough local shape to fill in a method body without turning the task into a chat session.

The feature is easiest to understand in small edits. Change one line, and IntelliJ IDEA suggests the next related change in the file.

2. In-editor code generation

Press Ctrl+\ anywhere in a file, type what you want in plain words, like “turn this loop into a stream” or “give me a builder for this class”, and the code appears right there at the cursor. The code lands in place, and you never have to switch to a chat to copy an answer back out of a conversation.

For a small, well-scoped change, the convenience is that the prompt starts where the edit happens. You type the instruction in the editor, review the generated code in place, and keep moving.

The generated code appears as an in-editor diff, so you can accept it, reject it, or refine the prompt. If the first version misses a constraint, add more context, ,like  “Keep the method name” or “use Optional instead of null”. IntelliJ IDEA regenerates the code with the extra information and shows the new diff in the same place.

It is the hidden gem in the list – a general-purpose prompt you can invoke at the cursor for small, arbitrary edits, without opening the AI chat or copying code back into the file.

3. AI Actions

AI Actions is the menu for people who never want to have a conversation with our model. Select a piece of code, press Alt+Enter, and choose from a variety of useful actions – no chat required.

Explain Code takes a regex you didn’t write, a SQL query someone left you, or a cron expression, and tells you in plain English what it does. Generate Unit Tests opens the tests in a diff, so you can argue with them before they land in your project. Generate Documentation writes the doc comment for a public method. These actions keep you in the file. Point at your chosen code, pick an action, and get an actionable response immediately.

4. Bring your own agent

At some point, the task stops being a single editor action. It needs file changes, tests, and a diff you can review. Through the Agent Client Protocol (ACP), you connect an external coding agent and drive it from the same place where you already inspect files, diffs, tests, and problems. Think of ACP as the LSP for agents: one protocol, so the IDE doesn’t need a custom integration for every new agent that appears next month. JetBrains’ own agent, Junie, shows up in the same registry as the third-party agents and receives no special treatment.

You ask the agent to change one endpoint. It proposes the steps, edits the service and the test, runs the test command, and leaves you with a diff you can open from the chat before accepting anything. That is the IDE part of the story. The agent can act, but the review still happens where you already review code.

Skills sit next to that. A skill is a reusable capability you set up once: triaging a CI failure, working through PR comments, converting Java to Kotlin, or nudging an agent away from the usual Spring Data JPA pagination mistake. You add skills from the + menu in the chat, and supported agents can use them without you having to retype the same long set of instructions every time.

That is where the IDE demonstrates its worth. The agent can make a series of edits, but you can inspect each one as it appears – open the affected files, check test outputs, and review diffs before accepting anything. The chat, code, and review stay in the same window, making it easier to stay in control while the agent handles the mechanical work.

5. Bring Your Own Key

Once agents are in the IDE, the next decision is more straightforward – which provider your organization allows the IDE to call. Bring Your Own Key (BYOK) enables you to add the API key or endpoint for any provider your team already uses.

A configured key can sit behind the AI chat and selected IDE features, such as commit message generation, depending on what features the provider and model support. For some teams, the ability to use a provider that has already passed internal review matters more than support for the one at the top of the current model leaderboard. 

You can configure your keys in Settings | Tools | AI Assistant | Providers & API keys. Choose a provider under Third-party AI providers, enter the key or endpoint, and test the connection. Once it is connected, the provider’s models will appear in the AI chat’s model selector.

Beyond the top five

Aside from the top five headline features, a couple of smaller capabilities are still worth knowing about because they appear where the IDE already has context.

When the stack trace is already in the console

The run console is where optimism goes for a reality check. When your app throws an error and the stack trace lands there, the Explain with AI action is on hand. The IDE reads the trace and then gives you a likely cause and a suggested fix. That is a better use of thirty seconds than pasting the top line into a search engine and opening three tabs from 2017.

When the staged diff needs a sentence

Generate Commit Message reads your staged diff and writes the message for you. Edit it, commit, and move on. It is a small feature, but it is exactly the kind you keep using once you know it exists.

The part you may have missed

The AI Chat window is still here, and has gotten more interesting with agents and skills. The easy-to-miss part is the layer of AI-powered productivity features around it: edits suggested as you type, code generated at the cursor, explanations for selected code and stack traces, and commit messages written from the staged diff.

The final effect is boring in the best way: IntelliJ IDEA, doing a little more than it used to, without making a ceremony out of it.

If you tried AI Assistant a year ago and mostly remember the chat, this is the part you may have missed.

If you are new to Agent Skills, I recommend reading AI-Assisted Java Application Development with Agent Skills first.

IntelliJ IDEA and other JetBrains IDEs include AI Assistant, which helps developers with AI agentic development. AI Assistant provides an elegant and secure way to use and manage Agent Skills.

If you missed the announcement, see Introducing the Skill Manager and Skill Repository.

In this article, we will explore:

• How to install Agent Skills via the Skills Manager.
• Managing skills with the Skill Repository.
• Installing skills globally, per project, or per agent.
• Adding your own Skill Repository.

Skills Manager

AI Assistant supports a wide range of AI agents through ACP (Agent Client Protocol).

The Skills Manager in AI Assistant lets you view the list of available skills and install them.

If you have already installed Agent Skills globally, the Skills Manager detects them and helps you install them as IntelliJ IDEA agent skills.

You can install a skill globally, at the project level, or per agent.

Skill Repositories

The Skill Repository lets you manage a list of locations where your verified skills are stored.

By default, JetBrains provides a Skill Repository hosted at https://github.com/JetBrains/skills.

These skills are verified by JetBrains for security vulnerabilities.

It is essential to check for security issues before using agent skills downloaded from the internet. A better approach is to maintain an organization-wide Skill Repository, verified by your team, and add it to the Skill Repository list.

Agent Skills in action

Based on the prompt description, the AI agent automatically detects and uses relevant agent skills.

For example, I installed spring-boot-skill, and when I asked the AI agent to write tests for Spring Boot REST API endpoints, it used the spring-boot-skill.

You can also explicitly invoke an agent skill using $skill-name [prompt] with Codex or `/skill-name [prompt]` with Claude.

Agentic Debugging using Debugger Skill

IntelliJ IDEA also includes the bundled ij-debugger skill, which teaches AI agents such as Junie, Claude, and Codex how to use the IDE’s debugger. It is particularly useful when source code analysis and logs are not enough. For example, when an incorrect value appears only at runtime, execution follows an unexpected branch, or you need to inspect variables, expressions, threads, and call stacks. The agent can start and control a debugging session, manage breakpoints, step through the code, and collect runtime evidence to identify the root cause. See Install the debugger skill to make it available to your agent.

To debug your code, describe the problem in natural language and provide any useful details, such as how to reproduce it or where you suspect the issue occurs.

For example, “A pet whose name differs only by case is not detected as a duplicate. Start a debug session, set a breakpoint in Owner.getPet(), and find out why.”

The agent sets the necessary breakpoints, runs the application, inspects the call stack and runtime values, evaluates its hypotheses, and reports its findings. Because it controls the standard IntelliJ IDEA debugger, you can follow the investigation in the Debug tool window and take over at any time.

For more details, see Agentic debugging.

Summary

AI Assistant’s Skills Manager makes agent skills part of your regular IDE workflow. You can discover, install, and manage skills without leaving IntelliJ IDEA, then make them available globally, for a specific project, or only to a particular AI agent. The AI agent can automatically select a relevant skill from your prompt, while explicit invocation gives you control when you need it.

Just as importantly, the Skill Repository provides access to skills verified by JetBrains for security vulnerabilities. Teams can also add their own repositories containing internally reviewed skills. This makes it easier to benefit from reusable agent capabilities while maintaining control over which skills developers use in their projects.

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

Here are the most notable updates:

• Markdown shell scripts now execute in the correct order. [IJPL-92206]
• Undo now works correctly after applying Optimize imports on the fly. [IDEA-285011] 
• Dragging a terminal tab after using the Move to Editor action no longer restarts the terminal session. [IJPL-165734]
• The IDE no longer throws exceptions caused by the new Resolve Conflicts mechanism for Mercurial projects.[IJPL-249379]
• Java code formatting now correctly respects the Smart tabs setting. [IDEA-388356]

To find out more details about the issues resolved, please refer to the release notes.

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

Happy developing!

There are many advanced debugging techniques, and while they all have their use cases, println debugging is still the #1 choice, whether you’re doing it manually or with the help of coding agents.

Inserting a println statement to inspect a program’s state is one of the first things novice developers do, even before they hear the word “debugging”. Years later, simple debug logging remains one of the most useful tools for diagnosing all sorts of problems in real codebases. And now, it’s also one of the favorite tools of coding agents.

Better foundation + modern workflows

The technique can be improved without losing its original simplicity. In fact, IntelliJ IDEA’s logpoints have long been a more capable superset of println debugging: While performing the same function, they can also be conditional, print stack traces, use hit counters and caller filters, be grouped, saved for later, and much more. If you try to imagine the most unusual debugging use case, chances are IntelliJ IDEA’s logpoints already have a feature for it (for example, did you know they can beep?).

In 2026.2, we’re taking logpoints further with several improvements focused less on specific use cases and more on strengthening the foundation:

• Instrumentation instead of debugger-side evaluation: IntelliJ IDEA now instruments your code directly for conditional and logging breakpoints, removing the bottleneck that other Java debuggers have.
• Agent compatibility: We’ve revised logpoints so they can be used reliably by AI agents. Together with a new bundled skill, this gives agents the guidelines and handles they need to control the debugging session and use all the logpoint features of the IDE.
• New UI and navigation: The new UI makes logpoints easier to set up. In addition, the console now tracks which println or logpoint produced each logging entry, letting you navigate there.

All these features are supported in both local and remote JVM debug sessions. 

Let’s look more closely at each of them.

A short demo

For this demo, I set up a mini gRPC server/client scenario, in which we’re supposed to debug the server side. For those new to logpoints, the next post in this series will feature a detailed tutorial based on this project. For now, let’s examine the new features.

In this particular case, suspending the app with a regular breakpoint is useless. If we try to do so, the timeout expires quickly, and execution follows the cancellation path, hiding the state we were going to inspect.

So, instead of using a breakpoint, let’s log the state, preferably with a coding agent doing it for us:

The agent not only sets the logpoints but also executes the run configurations, summarizes the resulting logs, finds the bug, and cleans up after itself.

Since IntelliJ IDEA tracks which logpoints belong to the agent, the agent cannot accidentally change yours. It does have full control over its own logpoints, though, including toggling them and modifying any properties that you can. When changing state is necessary for reproducing the bug, IntelliJ IDEA lets agents do that, but the skill steers the agent to avoid side effects and prefer logpoints whenever possible.

Here’s a short video showing how that works:

Run from the terminal

In the example above, we’re running the agent through the AI chat, but the same works equally well with agents in the built-in terminal or outside the IDE. Once the skill is installed, it becomes available in the agent of your choice:

The workflow is the same, this time with Claude Code:

Setting logpoints manually

Setting logpoints manually now takes a single click: Select the expression to log, and then click in the gutter between any two executable lines. If the expression is not in front of you in the editor, you can enter a custom expression afterwards:

To find out which piece of code produced a specific line in the console, click the line and then select Open:

IntelliJ IDEA will show the Open button that brings you to the corresponding code in the editor. Additionally, if it comes from an instrumented logpoint, the IDE will show the stack trace of how it got there – you get the same information as with the Log stack trace option, but now without cluttering the console with noisy messages.

How much faster have logpoints become?

Many benefits of logpoints are shared across debuggers:

• Logpoints do not require source changes.
• They are easy to turn on and off.
• They let you inspect code that would otherwise be inconvenient to modify.

IntelliJ IDEA’s implementation has many advantages beyond the basics, but performance is what stands out in this release.

If you’ve ever put a conditional or logging breakpoint in a hot path, you’ve seen the cost. With the traditional JPDA/JDWP breakpoint model, every hit suspends the application, evaluates the condition/log expression, and then resumes execution. For occasional hits this is fine, but in hot paths, this standard model becomes a bottleneck.

The overhead of traditional Java logpoints is not just a nuisance. The delay could hide a latency-sensitive failure, make a race condition disappear, or throttle the application load in a way that masks the problem. There’s a real risk that you would be debugging behavior introduced by the debugger itself.

Some time ago, I wrote about ways to work around this. Luckily, IntelliJ IDEA 2026.2 makes these hacks obsolete by instrumenting the debugged code for conditional and logging breakpoints. This chart shows the results of our internal benchmarking:

In our test set, the improvement is around 30x, making logpoints usable again in timing-sensitive code. You keep the same logpoint workflow, and so do agents, now with the performance of a regular print statement.

The best part is, you don’t need to do any setup to enjoy this speedup. IntelliJ IDEA will automatically detect logpoints that can be instrumented and do so behind the scenes in the same debug session, with no restart required.

Summary

Logpoints are still the same simple idea that makes println debugging great: Obtain the right bit of information and put it in the most accessible place. And with the new pieces, this technique becomes even more useful for both developers and AI agents.

More agent skills and debugger capabilities are on the way. If there is a debugging workflow you would like agents to handle, tell us in the comments under this post. And if you have a concrete feature request for IntelliJ IDEA, please file it in our YouTrack so it doesn’t go unnoticed.

Happy debugging!

Let’s go! 

Featured Content 

Donald Raab

Donald Raab is a Java Champion and creator of the open source Java library Eclipse Collections. He is an international Java and open source conference speaker. Don is the author of the book Eclipse Collections Categorically: Level Up Your Programming Game and was a contributing author to 97 Things Every Java Programmer Should Know from O’Reilly Media. He was a member of the JSR (Java Specification Request) 335 Expert Group, and has served on the JCP (Java Community Process) Executive Committee for two financial services firms. Donald was the winner of the JCP Member/Participant of the Year Award for 2025. He blogs regularly on his website.

If there is one blog post you read this month, then I hope it will be The Official Java Documentary by Stuart Marks.

The importance of telling our Java stories

We all have stories to tell, but they sometimes only get told when we tell them. Jim Grisanzio shared an archive of 77 Duke’s Corner Podcasts, which is a literal treasure trove of Java stories. I am ecstatic to see Java Champions like Rustam Mehmandarov blogging again. Write more please!

In Level Up Your Programming Game With a Java Book and Smalltalk, I tell the story of creating an open source Java library and writing a Java book inspired by my experience as a former Smalltalk developer.

Memory efficiency is back, and it’s coming for your allocations

In Why You Should Tune Code Before Your Garbage Collector, Peter Lawrey explains why optimizing memory allocation might make a bigger difference than your choice of garbage collector. As I like to say, the easiest garbage to collect is the garbage you didn’t create.

I’ve written a lot in the past four months about memory efficiency in Java. In Save Memory in Java by Making Memory Efficiency Your Top Priority, you will find many of the blog posts I have written recently about this topic. I’ve been teaching Java developers how to write code like it’s 2004 again, but with all the cool new Java language features.

Java News

Catch up on the latest updates:

• Java News Roundup 1, 2, 3, 4 

Java Tutorials and Tips

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

• The Java Story: A Film About All of Us
• The Java Story | The Official Documentary
• ZGC: A Decade of Redefining Java Performance
• Nulling Out References Won’t Help Your Garbage Collector 
• Why We Moved Our Timefold Java Worker Pods from AMD to ARM64
• Jeffrey Microscope for Generating Flame Graphs in Java
• A Bootiful Podcast: Java Developer Advocate Billy Korando on Java 27 and Beyond
• Resumable file uploads with plain Jakarta EE and TUS protocol
• Valhalla, Now! 
• To Cache or Not to Cache Virtual Threads 
• Pairing In-Process and Hosted Embeddings for Java MCP Tool Development 
• New Between-Quarters Security Updates for Java: What CSPUs Mean for Your Release Pipeline

Kotlin Corner

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

• Kotlin Comes to BlueJ
• In Conversation With the Golden Kodee Winners
• Demystifying Exposed: The Intelligent SQL Library for Kotlin
• Introducing the Kotlin Benchmark for AI Coding Agents
• The History of Kodee, Kotlin’s Mascot
• Kotlin Turns 15: Celebrate the Kotlin Effect
• KotlinLLM is Going Open Source 
• Dissecting Kotlin: 2026 | Huyen Tue Dao 
• How I Learned to Stop Worrying and Love Value Semantics (in Kotlin) | Marat Akhin 
• Run, Kotlin, Run! | Marc Reichelt
• The State of Amper | Joffrey Bion
• Local Lifetimes for Kotlin | Ross Tate
• Eval-Driven Development: The Fine Line Between Agentic Success and Failure | Urs Peter
• Building Enterprise Ready AI with Koog | Vadim Briliantov 

AI 

Explore smarter AI workflows and see how they reshape development:

• 95% of AI Projects Fail. Here’s Why. – Josh Long | The Marco Show
• Can You Use Java for AI? Why Java Is Better Positioned Than You Think
• Software Design in the Agentic Age: Place Your Bets
• 2026 State of the Art: Are Developers Being Replaced by AI?
• Of Skills and Loops with AI Assistance
• Agentic AI Architecture
• The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation
• Making Sense of Google Agentic Dev Tools
• A Bootiful Podcast: Russ Miles on Safer, More Productive Interactions with AI
• AI Solutions with Spring AI 2.0
• Are non-functional requirements the missing guardrail for AI-generated code?
• Better Models: Worse Tools 

Languages, Frameworks, Libraries, and Technologies

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

• This Week in Spring 1, 2, 3, 4
• Spring AI 2 + Ollama: Local LLM, No API Keys
• Spring Office Hours Podcast: S5E19 – Docker, Compose, Testcontainers, Oh My!
• A Bootiful Podcast: Sébastien Deleuze on the latest-and-greatest in Spring AI and Spring Framework
• The Kubernetes Approach to AI-Assisted Maintainership Prioritises Human Accountability
• Spring Office Hours Podcast: S5E18 – The Latest from OpenAI, Anthropic and Spring AI 2.0
• The Joyful Journey from Spring Boot to Quarkus
• Six and a half ridiculous things to do with Quarkus
• Toward a Durable Spring PetClinic
• The Self-Building Agent: A LangChain4j Experiment

Conferences and Events

While taking a break from offline conferences, get ready for IntelliJ IDEA’s event this September.

Culture and Community

Learn more about what is shaping the developer community:

• The Future of Engineering: Mindsets That Matter When Code Isn’t Enough
• First, ten
• Foojay Podcast #100: Java Podcasters on Why They Started, What Broke, and What They Learned
• A return to two-pizza culture 

And Finally…

Check out what’s new in IntelliJ IDEA this July: 

• IntelliJ IDEA Goes LSP: Java and Kotlin Intelligence Comes to VS Code, Cursor, and Agentic Flows

• What’s New in IntelliJ IDEA 2026.2
• What’s fixed in IntelliJ IDEA 2026.2
• IntelliJ IDEA TechTalks – check out the new bi-weekly podcast.
• IntelliJ Scala Plugin 2026.2 Is Out!
• Reverse Engineering with Hibernate 7.4 and 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 August 20. Don’t forget to check out our archive of past JAM issues for any articles you might have missed!

For this manual work, they might only need a basic, narrow set of features that IDEs provide, like navigating to declarations, finding references, some simple code completion, or renaming.

These features are generally covered by the Language Server Protocol (LSP), which allows programming language support to be implemented once and then reused by any LSP-capable IDE or editor. 

Even agents can make use of LSP servers today, leading to faster and more deterministic results and, eventually, reduced token consumption. 

In response to these changes, we’ve been working hard at JetBrains to offer IntelliJ IDEA’s smart language features for Java and Kotlin in an LSP format.

Today, we’re happy to announce that IntelliJ IDEA’s Java and Kotlin intelligence is available in a preview extension for third-party editors, starting with VS Code and its forks (such as Cursor).

We have also been running internal trials and experiments with a select few external customers, and the results have shown that the same LSP functionality can significantly improve terminal-based agentic workflows, like with Claude Code or Codex. We will share the very promising results of these experiments soon.

Introducing the VS Code extension

The Java & Kotlin by IntelliJ IDEA extension is now available, powered by IntelliJ IDEA’s Java and Kotlin language technology. It brings a focused set of capabilities to VS Code-based editors, including:

• Java, Kotlin, and mixed-language project support.
• Debugging (DAP-based).
• Smart code completion, navigation, and code analysis.
• Refactorings and editor assistance.
• Support for Maven, Gradle, and Bazel.
• Fast and reliable performance, even for large projects and monorepos.

You can find the full list of features in our documentation.

Getting started

You can install the Java & Kotlin by IntelliJ IDEA extension from the Visual Studio Marketplace and the Open VSX registry.

Install from Visual Studio Marketplace

Install from Open VSX registry

After installation, open your Java or Kotlin projects in VS Code or Cursor. 

The extension will start analyzing your projects, import the ones that have Maven, Gradle, or Bazel build files, and then enable Java and Kotlin language features in the editor for you.

Compatibility notice

Java & Kotlin by IntelliJ IDEA includes code analysis features and quick-fixes that overlap with Red Hat’s and Oracle’s extensions for Java. To avoid confusion, we recommend disabling those extensions while testing.

Licensing

During the preview phase, the extension is free to use. Each build renews the evaluation period and is limited to 30 days.

After the preview  period, using the extension will require an IntelliJ IDEA Ultimate subscription. 

The same license will let you use IntelliJ IDEA’s Java and Kotlin capabilities whether you are working in the IntelliJ IDEA desktop IDE, in VS Code-based editors, or in other supported environments. You can review the pricing options here.

Note: For pure Kotlin projects, you can use the Kotlin LSP, which we continue to develop and maintain. The Kotlin LSP’s source code is Apache 2.0 licensed. You can use it for free, either directly or via its extensions (Visual Studio Marketplace, Open VSX registry), with no subscription required.

What’s next

The VS Code extension is just one milestone in a longer development journey to bring the intelligence of IntelliJ IDEA to our users wherever they are. 

We strongly believe the best way to do Java and Kotlin development is inside IntelliJ IDEA. At the same time, we recognize that teams may have practical reasons to work in other environments, with other editors and tools. Wherever you choose to work, we want you to benefit from IntelliJ IDEA’s Java and Kotlin intelligence.

To this end, we’re already working on supporting fully agentic, terminal-based workflows. In the near future, we’ll share our initial results (think: reduced token consumption), and we’ll give you a chance to try out our agent plugins when they’re ready.

Feedback and support

We are eager to hear what you think. 

Please share feedback with us about what works well, what doesn’t, and which capabilities you would like to see next.

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

Your feedback during this preview phase will directly shape the extension as we move toward a stable 1.0 release.

Thank you!

Get the extension: Visual Studio Marketplace

Get the extension: Open VSX registry

This is useful when the database already exists, especially in legacy systems or large projects where creating entity classes manually can be slow and error-prone.

Until now, these features were provided by the separate Hibernate Tools project. Starting with Hibernate 7.4, the core Hibernate Tools modules are part of the Hibernate repository. Maven and Gradle (and even Ant) users can now access reverse engineering through the Hibernate build plugins. This is especially useful for database-first projects, where the schema already exists and the application needs an initial set of persistence artifacts.

IntelliJ IDEA also provides Reverse Engineering features that can help developers generate JPA entities from an existing database, generate Flyway or Liquibase migrations from JPA/JDBC entities, and much more.

In this article, let us explore both Hibernate 7.4 and IntelliJ IDEA Reverse Engineering capabilities and understand which tool to use in which scenario.

You can check out the sample code for this article in this GitHub repository.

Hibernate 7.4 Reverse Engineering

Hibernate 7.4 can inspect an existing database and generate artifacts such as:

• JPA entity classes
• Hibernate mapping files
• DAO-style helper classes
• Database schema SQL scripts

In the sample project, the reverse engineering workflow is configured using the Maven plugin with reverse engineering customization specified in hibernate-reverse-engineering.xml as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering SYSTEM
        "https://hibernate.org/dtd/hibernate-reverse-engineering-3.0.dtd">
<hibernate-reverse-engineering>
    <type-mapping>
        <sql-type jdbc-type="NUMERIC" hibernate-type="big_decimal"/>
        <sql-type jdbc-type="OTHER" hibernate-type="pg-uuid"/>
    </type-mapping>

    <table-filter match-name=".*" package="com.jetbrains.entities"/>
    <table-filter match-name="flyway.*" exclude="true"/>

    <table name="products" class="Product">
        <primary-key property="id">
            <generator class="sequence">
                <param name="sequence_name">product_id_seq</param>
            </generator>
        </primary-key>
        <!-- other config -->
    </table>

    <!-- other tables config -->
</hibernate-reverse-engineering>

This configuration lets us customize type mappings, package names, table filters, class names, and primary key generation. 

Configure the hibernate-maven-plugin in pom.xml as follows:

<properties>
   <!-- update the version to the newer version of Hibernate -->
   <hibernate.version>7.4.0.CR1</hibernate.version> 
</properties>

<plugin>
    <groupId>org.hibernate.orm</groupId>
    <artifactId>hibernate-maven-plugin</artifactId>
    <version>${hibernate.version}</version>
    <configuration>
        <revengFile>hibernate-reverse-engineering.xml</revengFile>
    </configuration>
    <executions>
        <execution>
            <id>generate-entities</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>hbm2ddl</goal>
                <goal>hbm2java</goal>
                <goal>hbm2dao</goal>
            </goals>
        </execution>
    </executions>
</plugin>

The hbm2java goal generates JPA entity classes from database metadata, while hbm2ddl can generate database schema SQL. The hbm2dao goal can generate DAO-style helper classes with methods to perform CRUD operations on entities.

To generate the artifacts, run:

$ ./mvnw generate-sources

This Maven goal generates JPA entities and DAO classes in target/generated-sources, and schema.ddl file in target/generated-resources directories.

Regeneration and Version-Controlled Workflows

Generated code is rarely the final version of an application model. After the first generation, developers often add validation annotations, helper methods, domain logic, fetch strategies, and other project-specific changes.

If these files are regenerated later, manual changes can be overwritten. This is why a regeneration workflow may not be ideal when developers edit generated entities directly.

However, regeneration is not always a drawback. Some teams prefer to keep the reverse engineering configuration in source control and make generation part of the build. In this setup, the output is reproducible, works in CI/CD, and does not depend on a specific IDE.

For example, a CI check can regenerate the artifacts and fail if the generated files are different from the committed version.

This workflow also works well with versioned database migrations. Migration scripts can remain the source of truth for schema history, while Hibernate reverse engineering generates Java artifacts from the current database schema.

Hibernate also has a built-in schema update mechanism, and the reverse-engineered output can be further customized with custom RevengineeringStrategy, so the underlying model doesn’t have to be a rigid, one-size-fits-all script either.

IntelliJ IDEA Reverse Engineering

IntelliJ IDEA provides a more interactive and flexible reverse engineering workflow. Instead of creating and maintaining a reverse engineering XML file, we can connect to a database from the IDE, select the tables, and generate JPA entities directly.

More importantly, IntelliJ IDEA supports progressive synchronization between the database schema and the code. When the database changes, the IDE can help sync those changes into existing entity classes without forcing a full regeneration. This helps preserve manual modifications that were made after the initial generation.

That difference matters in real projects. Entity classes often become part of the domain model, not just generated database mirrors. Being able to evolve generated entities safely is more valuable than repeatedly recreating them.

This functionality is provided by the IntelliJ IDEA Ultimate, so you need a subscription. It is not available in IntelliJ IDEA Community Edition or in other IDEs (yet), and it cannot be run as a command-line step in a build pipeline.

More Feature-Rich and Flexible

IntelliJ IDEA’s reverse engineering provide additional features apart from generating JPA entities from tables. The IDE supports related workflows such as:

• Generating JPA entities from an existing database schema
• Synchronizing database changes into existing entity classes
• Preserving manual changes during incremental updates
• Generating Flyway migrations from JPA entities
• Generating Liquibase migrations from JPA entities
• Supports Spring Data JDBC entities in addition to JPA

To learn more about these features, explore the following articles:

• How to Use Flyway for Database Migrations in Spring Boot Applications
• Spring Data JDBC Made Easy with IntelliJ IDEA

This makes IntelliJ IDEA a better fit for day-to-day development, especially when the schema and code evolve together. It provides a guided workflow, visual database integration, and incremental updates without requiring a build-time generation configuration for every change.

Choosing the Right Workflow

Hibernate 7.4 reverse engineering is a strong option when we want a repeatable, build-driven process. It works well for generating the initial version of entities and schema SQL from an existing database, especially in automated workflows.

IntelliJ IDEA is more suitable when we want an iterative workflow. It helps developers  progressively synchronize code and database changes without losing manual entity customizations. It also supports additional workflows around migrations and Spring Data JDBC, making it more feature-rich and flexible for application development.

Summary

Both approaches solve the same core problem of generating Java persistence artifacts from an existing database schema, but they are designed for different situations.

Use Hibernate 7.4 Reverse Engineering when:

• You want the generation to be part of the build process to generate entities, DAOs, .hbm files based on the current database schema.
• You need this to work in any IDE, or from the command line, or in a CI/CD pipeline, since it runs through Gradle or Maven.
• You are comfortable regenerating entities, DAOs, and .hbm files from a version-controlled reveng.xml file rather than editing generated code by hand.

Use IntelliJ IDEA Reverse Engineering when:

• You want an interactive and visual way to generate entities without writing any XML configuration.
• Your database schema changes over time, and you need to keep the entity classes in sync without losing the custom logic you have already added.
• You are working with Spring Data JDBC in addition to JPA, or you need to generate Flyway or Liquibase migration scripts.
• You have an IntelliJ IDEA Ultimate subscription and don’t need reverse engineering to run outside the IDE (for example, in a CI/CD pipeline)

IntelliJ IDEA is generally a strong choice for day-to-day development because it lets you evolve the database and the Java model together, as long as you have an Ultimate subscription and don’t need the step to run outside the IDE. It understands what already exists in your code and can merge schema changes into it, rather than replacing everything from scratch. 

If your team needs this to run in any IDE or as part of a CI/CD pipeline, or if you prefer a version-controlled, reproducible generation step, Hibernate 7.4’s build-tool-based reverse engineering is the better fit.

If you are starting a brand-new project from an existing database, either approach can give you a solid starting point. From there, the right choice mostly comes down to your team’s workflow and tooling constraints.

This version brings updates designed to streamline your workflows and help you confidently adopt the latest innovations across the Java ecosystem. 

You can download this 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.

Explore the What’s New page for a complete overview of the key new features, including detailed explanations and demos.

Explore the What’s New page

In addition, our developer advocates have recorded a walkthrough video covering all the release highlights. Check it out!

IntelliJ IDEA 2026.2 adds day-one support for Java 27 and the latest Kotlin 2.4 language features, helping you stay up to date with the newest JVM technologies. This release also streamlines Spring development with improved database migration workflows and richer Spring Security insights, while making debugging more powerful with new logpoints and enhanced navigation from runtime output to source code.

Here are the key highlights of this release:

AI upgrades:

• Native GitHub Copilot integration
• Agent skills
• AI completion support for third-party providers

Productivity-enhancing features:

• Logpoints
• Dependency completion
• Early Gradle 10 support and migration assistance
• Streamlined Git conflict resolution flow
• Docker Compose improvements

Support for new technologies:

• Java 27
• Kotlin 2.4 Stable features
• Spring support improvements 
• Terraform testing framework 
• TypeScript 7.0 

Version 2026.2 also delivers numerous stability, performance, and usability improvements across the platform. These are described in a separate What’s Fixed blog post.

Let us know what you think about the new features in this release, as your feedback helps us shape the product so it works even better for you.

Update to IntelliJ IDEA 2026.2 now to try out these new features. Don’t forget to join us on X, Bluesky, or LinkedIn, and be sure to share your favorite updates.

Thank you for using IntelliJ IDEA!

This release brings more than 1,300 bug fixes and usability improvements, and it addresses 140 freezes and other performance issues identified through internal diagnostics and user reports. Below is a recap of the most impactful updates.

Performance

Responsiveness remains a top priority. IntelliJ IDEA 2026.2 includes fixes for more than 140 freezes and other performance issues.

When editing Markdown files, the IDE is now much more responsive, improving the experience of writing specifications for agents

Projects opened natively in WSL or Docker environments should stall less often.

Editor file saves are now asynchronous. Writing a file to disk no longer blocks the UI thread, reducing the likelihood of freezes during save operations. If you develop IDE plugins, please refer to this dedicated blog post for migration guidance.

The custom file chooser now loads directories using asynchronous I/O and lazily expandable nodes, reducing UI freezes and making navigation more responsive in large or remote directory structures. The custom file chooser is primarily used in WSL, Dev Containers, and remote development environments, but you can also use it more broadly by disabling the Use native file chooser dialog option in Advanced Settings on Windows or macOS.

The loading of Spring configuration metadata is also faster and more stable. We resolved issues that could cause excessive memory consumption, endless metadata collection loops, and exceptions during Spring Boot configuration analysis.

Spring

To ensure readability and help you better understand code written by others, whether humans or agents, we are doubling down on fixes related to code resolution, navigation, and usage detection.

Note that some of these improvements are planned for the IntelliJ IDEA 2026.2.1 update.

Spring Boot configuration properties

IntelliJ IDEA now handles more configuration patterns correctly in application.properties files, YAML files, annotations, test configurations, Kotlin classes, Java records, nested objects, maps, lists, and custom configuration classes. Resolution, highlighting, completion, navigation, and @ConfigurationProperties mapping have all been improved.

See YouTrack issue IDEA-370087 for the full list of fixes.

Spring Security 2026.2.1

IntelliJ IDEA recognizes more ways to define request matchers, including paths supplied as arrays, the requestMatchers(RequestMatcher...) overload, and matchers created with PathPatternRequestMatcher.pathPattern(...). For example, the IDE will recognize and highlight new RegexRequestMatcher(pattern, method) as a regular expression. SpEL expressions in @PreAuthorize and other security annotations will correctly understand all usages of this.

New inspections will help identify ordering problems in a SecurityFilterChain, warning you, for example, when requestMatchers() are placed after anyRequest().

See YouTrack issue IDEA-391028 for the complete list of improvements.

Spring Cache 2026.2.1

Support for Spring Cache annotations, including @Cacheable, @CachePut, @CacheEvict, and @Caching, is becoming more accurate, with better SpEL expression validation and proper usage detection for methods referenced only through a #root.target expression

Additionally, inspections for conflicting @Cacheable and @CachePut, for # prefixes missing from root or result, and others no longer produce false positives.

See YouTrack issue IDEA-390707 for the full list of fixes.

Spring Events 2026.2.1

Improvements to the Spring Events support provide more reliable navigation between event publishers and listeners, including ApplicationListener implementations that listen for a base event type, events published through generic methods, custom generic events implementing ResolvableTypeProvider, and publishEvent calls made through method references

New inspections warn you when an @EventListener method listens for an early Spring Boot lifecycle and detect potentially incorrect combinations of @TransactionalEventListener and @Transactional that can otherwise fail only at runtime.

See YouTrack issue IDEA-390826 for the full list of improvements.

Thymeleaf

IntelliJ IDEA’s Thymeleaf support is now more reliable across expressions, tags, attributes, JavaScript inlining, completion, and property resolution. The IDE recognizes more expression forms, including inline output, bracket-based map access, nested selections, and T() references, while eliminating false warnings for common Thymeleaf and Layout dialect constructs. JavaScript expressions inside <script th:inline="javascript"> are handled correctly, numeric property keys now resolve as expected, and the Empty tag inspection can be disabled for Thymeleaf templates.

See YouTrack issue IDEA-370051 for the complete list of updates.

Kotlin

Server-side

We’re continuing to close the gaps between the Java and Kotlin support in Spring-based server-side projects.

IntelliJ IDEA can now configure Kotlin support for Lombok and other annotation processors through kapt automatically, reducing the amount of manual project setup required. These changes should make mixed Java and Kotlin projects more predictable.

Kotlin completion in Java code

IntelliJ IDEA’s Java code completion now also suggest Kotlin extension functions and companion object members. More complete and better sorted suggestions make working in mix-language codebases easier.

Removal of K1

With K2 adoption now above 99% across IntelliJ IDEA and Android Studio, we have removed the remaining K1-mode options and relevant code from the product.

Editor and navigation

The Markdown integration now supports standard footnotes, allowing the proper use of [^label] syntax. This resolves a long-standing feature request and makes it easier to work with technical documentation, articles, and other reference-heavy content directly in the IDE.

The IDE now knows how to keep your bookmarks when you switch Git branches. If you want to have your bookmarks preserved, disable the Enable bookmark context restoration on branch switching option in Settings | Advanced Settings.

When searching for classes, files, or symbols in Search Everywhere, IntelliJ IDEA now remembers the scope you selected, such as Project Files, Project and Libraries, or a custom scope. The same selection is restored automatically the next time you start a search.

Double-press shortcuts, such as Shift+Shift for Search Everywhere and Ctrl+Ctrl for Run Anything, are now fully customizable in Settings | Keymap.

User interface

Islands theme color coding

Colors assigned to scopes, such as test files or non-project files, remain visible when the tab is active, making it easier to identify the type of file you are currently editing at a glance.

Bundled plugins

Deprecation of the Machine Learning Code Completion (Ranking) plugin

The Machine Learning Code Completion plugin, which improved ranking, is being deprecated and will no longer be bundled with IntelliJ IDEA.

As AI completion, next edit suggestions, and coding agents have become the main forms of intelligent development assistance, the benefits of ML-based completion ranking have declined significantly.

The plugin remains available from JetBrains Marketplace, so you can install it separately and continue using it where needed.

Unbundling of the Task Management and Time Tracking plugins

The Task Management and Time Tracking plugins have also been removed from the default IntelliJ IDEA distribution.

Both plugins saw relatively low usage, and unbundling them helps keep the standard installation leaner. Their functionality has not changed, and both plugins can still be installed directly from JetBrains Marketplace.

More relevant plugin search results

Plugins will be easier to find, as searching for them in Settings | Plugins now produces better-ranked results.

Previously, all plugins containing the search text in either their name or description could appear in an arbitrary order, but now name matches are prioritized.

Conclusion

Let us know which fixes make the biggest difference in your workflow and where you still encounter friction. Your reports, feedback, and sample projects help us understand which issues have the greatest impact and what we should prioritize next.

Try IntelliJ IDEA 2026.2 and share your favorite improvements with us on X, Bluesky, or LinkedIn.

Thank you for using IntelliJ IDEA!

Hello everyone,

The new release of IntelliJ IDEA introduces a few new features for Scala developers that we’ve been working on for some time, as well as a number of fixes and improvements. We hope that they will make your Scala experience even better than before.

Build tool support

The logic behind sbt tasks in run/debug configurations has been reworked and now allows for a wider range of sbt commands. This enabled us to fix an issue where passing multiple parameters to an sbt command was either interpreted as a single parameter or caused the command name to be treated as an additional parameter. To work around this, developers had to run the task in the sbt shell instead. The new logic is much simpler: We no longer modify the user input. Instead, the input is expected to be a valid sbt command, e.g. tasks must be separated with semicolons, and we do not unquote the input.

Additionally, we’ve fixed a bug in the sbt shell where sync failed after waiting for user input. Also, previously, sbt import would not work if the .jvmopts file contained key-value pairs separated by a whitespace, such as --add-exports java.base/sun.nio.ch=ALL-UNNAMED – we’ve fixed this, too.

Separate ScalaTest tests can now be run through Bazel. Previously, this functionality was implemented on the Bazel side, but with the introduction of the new official JetBrains Bazel plugin, it made more sense to move it to the Scala plugin. And, by the way, this is an external contribution from one of our users!

WSL and Docker

Starting with IntelliJ IDEA 2026.2, WSL and Docker support covers not only sbt projects, but also BSP projects and projects built with other BSP-based tools, such as Mill, Scala CLI, and Bloop. On top of that, we’ve stabilized WSL support and fixed several bugs where sbt imports and re-running tests used to fail in WSL.

Scala 3

The new release includes full support for Clause Interleaving (SIP-47), which is a standard feature as of Scala 3.6. This allows IntelliJ IDEA to support previously impossible combinations of type parameters and regular parameters. This is illustrated in the getOrElse method declaration below, where it is necessary to know the instance of the key parameter to properly calculate the type bound of the default parameter:

The update method in that code example also shows that we now support dependent parameter types belonging to the same clause. Previously, the example would have worked only if key and value had been placed in separate, single-parameter clauses.

On the error-highlighting front, we’re working on improving support for match types in the built-in highlighting. This new release supports type-level operations, as shown in the code example below. We’re working on expanding this support to cover some missing corner cases.

We’ve also fixed a bug where calling a synthetic companion object could not be resolved, and another one where a wrong number of indents could lead to changed semantics.

Code completion

In v2026.2, we introduce support for Scala in a recently added IntelliJ IDEA feature, command completion. You are likely already familiar with the behavior where, if you type a dot (.) after a symbol (be it a class, a method, or a value name), IntelliJ IDEA opens a code completion window. Now, if you type two dots quickly one after another, another popup will appear with suggestions for commands that might be useful in the situation. You can learn more from our blog post dedicated to command completion or watch the screen recording below.

Other improvements

Additionally, we’ve improved the handling of @throws directives and of link references in ScalaDoc. The @Language injection annotation is now recognized on apply methods in case classes and implicit classes, and we’ve fixed an issue with how single tests are discovered in mUnit. Further improvements include a new version of the quick-fix for using scala.compiletime.uninitialized instead of null in null-initialized variables, as well as improved handling of nullable variables.

As always, we welcome your feedback. Please report any issues you find in YouTrack. If you have any questions, feel free to ask us on Discord.

Happy developing!

The Scala team at JetBrains