IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog

Using Spring Data JDBC With Kotlin

Teodor Irkhin — Thu, 09 Apr 2026 11:46:14 +0000

This post was written together with Thorben Janssen, who has more than 20 years of experience with JPA and Hibernate and is the author of “Hibernate Tips: More than 70 Solutions to Common Hibernate Problems” and the JPA newsletter.

Spring Data JDBC provides a simple and predictable persistence model. It focuses on aggregate roots, constructor-based mapping, and clear rules for reading and writing data. If you enjoy working with explicit data flows and want full control over your SQL, Spring Data JDBC might be the perfect framework for your project.

And with Kotlin, everything becomes so much easier. Its focus on immutability, null safety, and concise data structures aligns nicely with Spring Data JDBC’s design. In this article, you will see how to model aggregates, store and retrieve data, use value objects, handle child entities, and define custom queries using Kotlin.

Kotlin’s strengths for JDBC-based persistence

Before looking at concrete examples, it helps to understand why Kotlin fits so well into this programming model.

Data classes keep your aggregates concise. They define constructor parameters, implement the equals(), hashCode(), and toString() methods, and encourage immutable states. Spring Data JDBC provides strong support for constructor-based mapping and handles immutable aggregates with ease, significantly reducing boilerplate code.

Kotlin’s type system also reduces many common mistakes. Nullability is explicit, so you can see immediately which fields may not contain a value. Constructor-based mapping becomes more reliable because there is no silent conversion of null values into empty strings or default primitives.

Lightweight value classes allow you to express domain concepts without adding noise. An email address, a customer number, or a price becomes a first-class concept in your model. And Spring Data JDBC can, of course, map them without requiring any additional boilerplate code or mapping annotations.

Kotlin also simplifies custom query projections, because data classes work very well with constructor mapping. Default parameters, named arguments, and collection operations make aggregate updates straightforward.

All these features create a natural fit for Spring Data JDBC and Kotlin.

Defining an aggregate root with Kotlin

An aggregate is a pattern introduced by domain-driven design (DDD) concepts. It consists of one or more entities that are handled as a unit when reading or writing them to the database. The aggregate root is the primary object of the aggregate. You address it when referencing the aggregate or when fetching it from the database.

Let’s start with a simple aggregate that only consists of the aggregate root. Each instance is stored as a record in your database whenever you decide to persist or update it. There is no hidden state and no proxying.

The following data class represents a person. The @Table annotation is optional, but it clearly marks the class as an entity. This helps IntelliJ IDEA to provide you with the most suitable tooling when building your persistence layer.

The @Id annotation marks the field as the object’s identifier. The @Sequence annotation is optional and tells Spring Data to retrieve a value from the database sequence when persisting a new object. And because this happens after you created a new Person object in your code, the ID field has to be nullable.

If you want, you can define all other fields as non-nullable.

@Table
data class Person(
    @Id
    @Sequence(sequence = "person_seq")
    val id: Long? = null,
    val firstName: String,
    val lastName: String
)

As you can see in the code snippet, you don’t need to provide any additional mapping annotations. By default, Spring Data JDBC maps the class to a database table with the same name and each field to a column with the same name. You can change this mapping by annotating your class with @Table and a field with @Column. But most teams try to avoid that to keep their entities easy to read and understand.

By default, Spring Data JDBC uses the primary constructor to create and hydrate entity instances. You can also annotate a constructor with @PersistenceCreator if you want Spring Data JDBC to use it instead. This is an excellent match for Kotlin’s data classes, because all non-primary-key fields can be immutable, mandatory, and have default values. This helps you avoid uninitialized properties and the need for no-argument constructors that you might be familiar with in Spring Data JPA and other persistence frameworks.

After you define the aggregate, you have to create a repository to manage it.

Creating repositories and defining queries

Spring Data JDBC uses repository interfaces to define data access operations. The simplest way to define a repository is to extend Spring Data JDBC’s CrudRepository.

interface PersonRepository : CrudRepository {}

This provides you with basic methods, including save(), findById(), and deleteById().

You can also add your own queries using Spring Data JDBC’s derived query methods. These are methods whose names describe the query that Spring Data JDBC should execute. The framework parses the method name, creates the appropriate SQL statement, and maps the query result.

And if you need more control over the executed query statement, you can define a method, annotate it with @Query, and provide your own SQL statement. Spring Data JDBC handles the rest!

Here are a few examples.

interface PersonRepository : CrudRepository {
    fun findByLastName(lastName: String): List

    @Query("select * from Person p where p.last_name = :lastName")
    fun getByLastName(lastName: String): List
}

You can also return Kotlin data class projections. This works well when you want to read specific columns but not the entire aggregate, or when you want to transform your data into a different structure.

The following PersonName data class and findPersonNameById repository method show a typical example.

data class PersonName(
    val id: Long,
    val name: String
)

interface PersonRepository : CrudRepository {
    @Query("select p.id, p.first_name || ' ' || p.last_name as name FROM Person p where p.id = :id")
    fun findPersonNameById(id: Long): PersonName
}

Spring Data JDBC executes the defined query and maps the query result to the constructor parameters of the PersonName class. This keeps the projection code clean and allows you to avoid manual mapping.

2025-12-09T21:59:12.572+01:00 DEBUG 7484 --- [SDJWithKotlin] [           main] o.s.jdbc.core.JdbcTemplate               : Executing prepared SQL statement [select p.id, p.first_name || ' ' || p.last_name as name FROM Person p where p.id = ?]
2025-12-09T21:59:12.595+01:00  INFO 7484 --- [SDJWithKotlin] [           main] c.t.j.k.s.SpringDataJdbcKotlinTests      : PersonName(id=401, name=Jane Smith)

Persisting and loading aggregates

Working with repositories is straightforward. Each call interacts directly with the database. There is no state tracking or implicit updates. This makes the behavior easy to understand and gives you full control over the executed statements.

@Service
@Transactional
class PersonService(private val personRepository: PersonRepository) {
    fun createNewPerson(firstName: String, lastName: String): Person {
        // add additional validations and/or logic ...
        return personRepository.save(
            Person(
                firstName = firstName,
                lastName = lastName
            )
        )
    }

    fun updateLastName(id: Long, lastName: String): Person {
        val person = personRepository.findById(id).orElseThrow()
        val updated = person.copy(lastName = lastName)
        return personRepository.save(updated)
    }
}

The only logic Spring Data JDBC provides when you call the save() method is a check to see if the identifier is null. If it is, the record is inserted. Otherwise, an update is executed. Since all fields are immutable, you’re always working with complete and consistent objects.

Using Kotlin value objects in your aggregate

Real-world aggregates often contain values that deserve their own type. Using Kotlin, you can model them using value classes, and Spring Data JDBC supports them out of the box.

If your value class only wraps one value, you should annotate it with @JvmInline. This activates a Kotlin-specific optimization removing the performance overhead of a wrapper class by replacing it with its inlined value at runtime.

@JvmInline
value class Email(val value: String)

data class Person(
    @Id
    @Sequence(sequence = "person_seq")
    val id: Long? = null,
    val firstName: String,
    val lastName: String,
    val email: Email
)

As you can see, Kotlin’s value and data classes make the code very easy to read and quick to write.

Doing the same in Java requires much more code, an additional mapping annotation and Spring Data JDBC’s embedded entity concept.

@Table
public class Person {

    @Id
    @Sequence(sequence = "person_seq")
    private Long id;

    private String firstName;

    private String lastName;

    @Embedded.Nullable
    private Email email;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public Email getEmail() {
        return email;
    }

    public void setEmail(Email email) {
        this.email = email;
    }
}

public class Email {

    private String email;

    public Email(String email) {
        this.email = email;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

Java doesn’t know value classes. Spring Data JDBC tries to compensate for this by introducing the concept of an embedded entity.

You define an embedded entity by creating a Java class with a set of properties. In this example, that’s the Email class with its email property. To use the Email class as a property type, you have to annotate it with @Embedded. Spring Data JDBC then applies the same mapping we covered in the example demonstrating Kotlin’s value class. It maps the email field to a database column with the same name, enabling you to use it in all your queries.

So, it looks like you have to write more code and use an embedded entity in Java to get the same result as you got with a simple value class in Kotlin. But it’s actually worse than that. In Kotlin, you can annotate your simple value classes with @JvmInline and get the previously described optimizations. These don’t exist in Java. As a result, your embedded class mapping not only requires more code – it also carries a much greater performance overhead.

Now, let’s get back to our Kotlin-based examples.

Spring Data JDBC maps the value object based on its wrapped value and doesn’t require any additional mapping annotations.

You can even use the value class as a parameter type in your derived or custom queries.

interface PersonRepository : CrudRepository {
    fun findByEmail(email: Email): Person?
}

2025-12-09T22:03:49.340+01:00 DEBUG 14665 --- [SDJWithKotlin] [           main] o.s.jdbc.core.JdbcTemplate               : Executing prepared SQL statement [SELECT "person"."id" AS "id", "person"."email" AS "email", "person"."last_name" AS "last_name", "person"."first_name" AS "first_name" FROM "person" WHERE "person"."email" = ?]
2025-12-09T22:03:49.363+01:00  INFO 14665 --- [SDJWithKotlin] [           main] c.t.j.k.s.SpringDataJdbcKotlinTests      : Person(id=401, firstName=Jane, lastName=Smith, email=Email(value=a@b.com))

Modeling one-to-many relationships

Aggregates can contain collections of child entities. Spring Data JDBC stores each of these entity types in separate tables.

data class Company(
    @Id
    var id: Long,
    val name: String,
    val employees: List
)

data class Employee(
    @Id
    var id: Long,
    var name: String
)

When you read the aggregate, Spring Data JDBC always fetches the entire aggregate with all child entities. And it handles all write operations the same way. When persisting or updating an aggregate, it writes the entire aggregate with all its entities to the database. This fits well with Kotlin’s immutable list types, but requires some attention when defining your aggregates to avoid performance issues.

Transactions and practical considerations

Spring Data JDBC integrates with Spring’s transaction management. A transactional boundary ensures that all write operations within the aggregate are applied consistently.

Kotlin reduces many typical pitfalls. Properties must be initialized, nullability is clear, and immutable data helps avoid accidental side effects. When updating an aggregate, you create a new instance with the correct state as opposed to modifying an existing one. This results in a predictable and maintainable persistence layer.

Conclusion

Spring Data JDBC offers a clear and simple approach to relational persistence. You work with aggregates that are written and read as complete units, and you always know which statements are executed. Kotlin supports this style through immutable data structures, value classes, nullability rules, and concise syntax.

If you design your aggregates carefully and treat each instance as a complete snapshot of its state, you can build applications that remain easy to understand and maintain. The combination of Spring Data JDBC and Kotlin gives you a persistence stack that stays simple even as your application grows.

To learn more about persistence with Kotlin, check out our two previous articles in this series:

About the author

Thorben Janssen

Java Annotated Monthly – April 2026

Irina Mariasova — Mon, 06 Apr 2026 11:10:42 +0000

It’s safe to say March was defined by one thing: Java 26. In this issue of Java Annotated Monthly, we’ve curated a rich selection of articles to help you get the full picture of the release. Marit van Dijk joins us as the featured guest author, bringing her expertise to help you navigate the changes with confidence. Alongside our Java 26 coverage, you’ll find our regular roundup of AI developments, Spring updates, Kotlin news, industry trends, and community reads that caught our eye.

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.

Marit regularly presents at international conferences and shares her expertise through webinars, podcasts, blog posts, videos, and tutorials. She’s also a contributor to the book 97 Things Every Java Programmer Should Know (O’Reilly Media).

March held a lot of interesting things for Java. First of all, there was the Java 26 release on March 17. You can read all about Java 26 in IntelliJ IDEA on the blog, and find more links on Java 26 in the Java sections below.

Also in March, JavaOne took place in Redwood Shores, USA. During the community keynote, our colleague Anton Arhipov talked about 25 years of IntelliJ IDEA. In case you missed it, we also did a Duke’s Corner podcast and a Foojay podcast on the same topic. And of course, the IntelliJ IDEA documentary was released this month. Also at JavaOne, we announced that Koog is coming to Java, if you want to try JetBrains’ Koog AI agent with Java instead of Kotlin.

IntelliJ IDEA 2026.1 was just released. Of course we have Java 26 support from day one, as well as improvements to the debugger for virtual threads, support for new Kotlin features, Spring Data and Spring Debugger features, new AI features, and more. You can read all about it on the blog or watch our release video.

The release of Java 26 also means that Piotr Przybył and I updated our talk, Learning modern Java the playful way, for Java 26. You can watch the recording from Voxxed Days Amsterdam, or catch us at multiple events around Europe.

Java News

Check out all the Java news highlights in March:

Java Tutorials and Tips

You can never have too many tips for getting more out of Java:

Kotlin Corner

Stay sharp with the latest Kotlin news and practical tips:

AI

Plenty of AI reads this month. Pick what catches your eye:

Languages, Frameworks, Libraries, and Technologies

Spring updates and more tech news, all in one place:

Conferences and Events

Pick your next events to attend:

Spring I/O – Barcelona, Spain, April 13–15; Come say hi at the JetBrains booth and join the community run!

Java Day Istanbul – Istanbul, Türkiye, April 17–18; Anton Arhipov is a speaker.
JCON EUROPE – Cologne, Germany, April 20–23; Marit van Dijk will talk about learning modern Java the playful way.
Great International Developer Summit – Bengaluru, India, April 21–24; Join Siva Katamreddy’s talk on Spring AI + MCP.
Devoxx France – Paris, France, April 22–24; Check out the talks by Anton Arhipov and Marit van Dijk.
Devoxx Greece – Athens, Greece, April 23–25; Marit van Dijk is a speaker.
Voxxed Days Bucharest – Bucharest, Romania, April 28–29; And if you haven’t caught Marit van Dijk during this busy month of hers, here’s the last chance to hear her speak in April.

Culture and Community

Your go-to section to slow down and think about the industry, self-growth, and more:

And Finally…

Top picks from the IntelliJ IDEA blog:

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 April 20. Don’t forget to check out our archive of past JAM issues for any articles you might have missed!

Using Spring Data JPA with Kotlin

Teodor Irkhin — Mon, 30 Mar 2026 11:30:47 +0000

Spring Data JPA is based on the Jakarta Persistence specification and was originally designed for Java. That often raises the question of whether it is a good fit for Kotlin projects.

The short answer is yes!

You can use Spring Data JPA with Kotlin without any issues and enjoy Kotlin’s compact syntax and language features, like null safety and extension functions, when writing your business code.

And doing all of that is so quick and easy could explained in this short blog post. Let’s use Spring Data JPA with Kotlin to define and use a simple persistence layer.

Required dependencies

The easiest way to get started is to use the “New Project” wizard in IntelliJ. Once you select Kotlin and Spring Data JPA, the basic setup is done for you. That includes configuring the Kotlin no-arg and all-open plugins. They ensure that your Kotlin classes fulfill Jakarta Persistence’s requirements for non-final classes and parameterless constructors. You also get the kotlin-reflect dependency, which is required by Spring.

On the next page, you can select the Spring Boot Starter modules and other dependencies you want to use. In this example, that’s Spring Data JPA and the PostgreSQL database driver.

Adding Kotlin to an existing project

If you already have a Java-based Spring Boot project with the required dependencies, you can simply add a Kotlin class to it. Starting with version 2026.1 Intellij IDEA automatically adds the plugins plugin.spring and plugin.jpa to your build configuration and configure the all-open plugin.

In case you’re using an older IDEA version, you have to add the following configuration yourself.

plugins {
   kotlin("plugin.spring") version "2.2.20"
   kotlin("plugin.jpa") version "2.2.20"
}

allOpen {
   annotation("jakarta.persistence.Entity")
   annotation("jakarta.persistence.MappedSuperclass")
   annotation("jakarta.persistence.Embeddable")
}

Database and logging configuration

After defining your project’s dependencies, you need to set up the database connection in your application.properties file, and you can provide your preferred logging configuration.

The following settings connect to a local PostgreSQL database and activate detailed Hibernate logging. The logging configuration instructs Hibernate to log the executed SQL statements and all bind parameter values. This information is extremely helpful during development and debugging, but it generates a lot of output. So, please make sure to use a different logging configuration in production.

spring.datasource.url=jdbc:postgresql://localhost:5432/postgres

spring.datasource.username=postgres
spring.datasource.password=postgres

logging.level.root=INFO
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.orm.jdbc.bind=TRACE

Modelling entities

You can then start modeling your entities in Kotlin. The Jakarta Persistence specification defines a few requirements for entity classes. As we explained in a recent article on common best practices, some of these requirements don’t align well with Kotlin’s data classes. But you will not run into any issues and enjoy Kotlin’s concise syntax if you define your entity classes as regular Kotlin classes and annotate the fields you want to persist.

It’s a general best practice to avoid exposing your entity classes and their technical dependencies in your API. Most teams introduce a second non-entity representation of their data for that. Using Kotlin, you can easily model those classes as a data class. Doing that requires additional mapping code to convert your data between the different formats. You could, of course, do that in your business code. But it’s much more comfortable to add a set of converter functions to your entity class or select the data class directly from the database. You will see an example of the second approach later in this article. Let’s concentrate on the entity class for now.

Here is a simple Person entity. It maps the person’s first and last name, along with a many-to-one relationship to the company they work for.

The PersonData class represents the same information. You can use it in your API without exposing any technical details of your persistence layer. To make using this class as comfortable as possible, the Person entity class provides 2 functions with the required mapping code.

@Entity
class Person(
    @Id
    @GeneratedValue
    var id: Long? = null,

    var firstName: String? = null,

    var lastName: String? = null,

    @ManyToOne(fetch = FetchType.LAZY)
    var company: Company? = null,

    @Version
    var version: Integer? = null
) {
    fun createPersonData(): PersonData {
        return PersonData(
            id = id!!,
            firstName = firstName ?: "",
            lastName = lastName ?: "",
            version = version
        )
    }

    companion object {
        fun createPersonFromData(data: PersonData): Person {
            return Person(
                id = data.id,
                firstName = data.firstName,
                lastName = data.lastName,
                version = data.version
            )
        }
    }
}

data class PersonData(
    val id: Long,
    val firstName: String,
    val lastName: String,
    val version: Int
)

The functions

The Company entity follows the same approach:

@Entity
class Company(
    @Id
    @GeneratedValue
    var id: Long? = null,

    var name: String = "default",

    @Version
    var version: Integer? = null
)

After you modeled your entity classes, you can start defining your repositories.

Designing and using a repository

Spring Data JPA’s repository abstraction works the same way in Kotlin as it does in Java. You extend one of the provided repository interfaces, such as JpaRepository or CrudRepository, and Spring Data provides you with an implementation.

These repositories define a set of standard methods for fetching entities by primary key, persisting new entities, and removing existing ones. They also integrate with Spring’s transaction handling, so that you can use the @Transactional annotation on your business or API layer to define the transaction handling.

Here is an example of a simple PersonRepository definition. It inherits all standard methods defined by the JpaRepository. Let’s see how to add your own query methods in one of the following examples.

interface PersonRepository : JpaRepository {}

To make it even easier, IntelliJ IDEA can create the repository for you automatically. Just start typing repository name in the service and IDEA will suggest creating it:

With this repository in place, you can focus on your business logic. That’s especially convenient in Kotlin because constructor injection and concise function definitions keep your classes short and focused.

@Component
@Transactional
class PersonController (
   private val personRepository: PersonRepository) {
   fun createNewPerson(person : Person): Person {
       // add additional validations and/or logic ...
       return personRepository.save(person)
   }
}

In this example, Spring injects a PersonRepository instance and joins an active transaction or starts a new one before entering the createNewPerson method. If it started a new transaction, it also commits it after completing this method call. And the PersonRepository, together with the Jakarta Persistence implementation, provides the required code to create and execute a SQL INSERT statement that stores the provided Person object in the database.

2025-11-16T16:02:53.988+01:00 DEBUG 10104 --- [SDJWithKotlin] [           main] org.hibernate.SQL                        : select next value for person_seq
2025-11-16T16:02:54.012+01:00 DEBUG 10104 --- [SDJWithKotlin] [           main] org.hibernate.SQL                        : insert into person (company_id,first_name,last_name,version,id) values (?,?,?,?,?)
2025-11-16T16:02:54.014+01:00 TRACE 10104 --- [SDJWithKotlin] [           main] org.hibernate.orm.jdbc.bind              : binding parameter (1:BIGINT) <- [null]
2025-11-16T16:02:54.014+01:00 TRACE 10104 --- [SDJWithKotlin] [           main] org.hibernate.orm.jdbc.bind              : binding parameter (2:VARCHAR) <- [John]
2025-11-16T16:02:54.014+01:00 TRACE 10104 --- [SDJWithKotlin] [           main] org.hibernate.orm.jdbc.bind              : binding parameter (3:VARCHAR) <- [Doe]
2025-11-16T16:02:54.014+01:00 TRACE 10104 --- [SDJWithKotlin] [           main] org.hibernate.orm.jdbc.bind              : binding parameter (4:INTEGER) <- [0]
2025-11-16T16:02:54.015+01:00 TRACE 10104 --- [SDJWithKotlin] [           main] org.hibernate.orm.jdbc.bind              : binding parameter (5:BIGINT) <- [2]

You might know all of this from using Spring Data JPA with Java. Kotlin does not change any of this behavior, and you also get all the benefits from using Kotlin when implementing your business logic.

Let’s take a look at another example.

Fetching and updating an existing entity follows the same pattern. The updateLastName function loads the entity by its primary key and changes the lastName. That’s all you have to do. The Jakarta Persistence implementation finds that modification during its next dirty check and updates the database automatically.

@Component
@Transactional
class PersonController (
   private val personRepository: PersonRepository) {
   fun updateLastName(id : Long, lastName : String): Person {
       var person = personRepository.findById(id).orElseThrow()
       person.lastName = lastName
       return person
   }
}

As you can see, Kotlin’s concise syntax helps keep the business logic easy to read, and Spring handles all the boilerplate code for you. That makes implementing your application very comfortable.

Adding your own queries

In addition to the standard methods provided by Spring Data JPA’s repositories, you need to define queries that fetch the data used in your business code. You can do that in 2 ways, both of which work fine with Kotlin.

The first and most convenient option is to use derived query methods. Spring analyzes the method name, derives the corresponding JPQL query, and binds the method parameter values. This is a good choice when your query is simple and only requires one or two bind parameters.

You can add a derived query method directly to your repository. Or In IDEA, you can start typing a desired method name and use autocompletion to have it automatically added to your repository.

You can see a typical example in the following code snippet. The findByLastName method fetches all Person entities with a lastName equal to the provided one.

interface PersonRepository : JpaRepository {
   fun findByLastName(lastName: String): List
}

If your query becomes more complex, you should instead annotate your repository method with a @Query annotation. That allows you to write your own JPQL query and gives you full control over the executed statement. You can use joins, grouping, or any other JPQL feature you need.

Here you can see the same query statement as in the previous example. But this time, using a @Query annotation instead of Spring Data’s derived query feature.

interface PersonRepository : JpaRepository {
   @Query("select p from Person p where p.lastName = :lastName")
   fun getByLastName(lastName: String): List
}

When you call one of these methods, Spring Data JPA uses Jakarta Persistence’s EntityManager to instantiate a Query, set the provided bind parameters, execute the query, and map the result to a managed Person entity object.

2025-11-16T16:47:20.949+01:00 DEBUG 16193 --- [SDJWithKotlin] [           main] 
org.hibernate.SQL                        : select 
p1_0.id,p1_0.company_id,p1_0.first_name,p1_0.last_name,p1_0.version from person p1_0 
where p1_0.last_name=?
2025-11-16T16:47:20.952+01:00 TRACE 16193 --- [SDJWithKotlin] [           main]
org.hibernate.orm.jdbc.bind              : binding parameter (1:VARCHAR) <- [Doe]

But entities are not the only projection you can use. For many use cases, a read-only DTO projection that only fetches the required information is more efficient. And Kotlin’s data classes are a great way to model such a DTO.

If you only want to show the first and last names of multiple people along with the company they work for, you could use the following PersonWithCompany data class.

data class PersonWithCompany(
    val firstName: String,
    val lastName: String,
    val company: String
)

In the next step, you can define a repository method that returns a List of those objects. If you annotate that method with a @Query annotation and provide a JPQL query that returns 3 fields with matching names, Spring Data JPA automatically maps each record to a PersonWithCompany object.

interface PersonRepository : JpaRepository {
   @Query("select p.firstName, p.lastName, c.name as company from Person p join p.company c")
   fun findPersonsWithCompany(): List
}

As you can see in the log output, using a data class as your query projection combines the convenience of Kotlin data classes in your business code with the performance benefits of fetching only the required information from the database.

2025-11-16T16:59:42.260+01:00 DEBUG 22541 --- [SDJWithKotlin] [           main]
org.hibernate.SQL                        : select p1_0.first_name,p1_0.last_name,c1_0.name from 
person p1_0 join company c1_0 on c1_0.id=p1_0.company_id
2025-11-16T16:59:42.278+01:00  INFO 22541 --- [SDJWithKotlin] [           main] c.t.j.k.s.SDJWithKotlinApplicationTests  : PersonWithCompany(firstName=Jane,
lastName=Doe, company=Mighty Business Corp)

Provide your own repository method implementations

If you need more flexibility than Spring Data JPA’s @Query annotation provides, you can also add your own method implementations to a repository. You do that by creating an interface that defines only the methods you want to implement, letting your repository extend that interface, and providing an implementation of that interface. This is called a fragment repository.

In this example, the PersonFragmentRepository defines the searchPerson method that expects a PersonSearchInput parameter.

interface PersonFragmentRepository {
   fun searchPerson(searchBy : PersonSearchInput): List?
}

data class PersonSearchInput(
   val firstName : String?,
   val lastName : String?,
   val worksForCompany : String?
) {}

In the next step, you have to implement the PersonFragmentRepository. The name of your class should be the interface name with the postfix Impl. Spring Data then automatically detects this class, wires it into your repository, and delegates all calls to the searchPerson method to your class.

The goal of the following searchPerson implementation is to check which fields of the PersonSearchInput object are set and consider only those fields in the query’s WHERE clause. This is a typical implementation for complex search dialogs, where users can choose which information to search for.

override fun searchPerson(searchBy: PersonSearchInput): List? {
    val cBuilder = em.criteriaBuilder
    val cQuery = cBuilder.createQuery(Person::class.java)
    val person = cQuery.from(Person::class.java)
    val wherePredicates = mutableListOf()

    searchBy.firstName?.let {
        wherePredicates.add(cBuilder.equal(person.get("firstName"), searchBy.firstName))
    }
    searchBy.lastName?.let {
        wherePredicates.add(cBuilder.equal(person.get("lastName"), searchBy.lastName))
    }
    searchBy.worksForCompany?.let {
        val company = person.join("company")
        wherePredicates.add(cBuilder.equal(company.get("name"), searchBy.worksForCompany))
    }

    cQuery.where(*wherePredicates.toTypedArray())
    return em.createQuery(cQuery).resultList
}

As you can see in the code snippet, the searchPerson method uses Jakarta Persistence’s Criteria API to define a query based on the fields set on the provided PersonSearchInput object.

It first gets a CriteriaBuilder and uses it to create a CriteriaQuery that returns Person objects. It then defines the FROM clause and creates a List of Predicates. For each field of the PersonSearchInput object that’s not null, an equal predicate gets added to the wherePredicates List.

Thanks to Kotlin’s concise syntax and null handling, defining those Predicates is straightforward. Only the handling of the company name requires a little attention. If that field is set, you have to add a join to the Company entity before you can define the equal predicate.

You can then use the wherePredicates List to define the WHERE clause, execute the query, and return the result.

After you define the PersonFragmentRepository and implement it, you can use it in your repository definition. Let’s add it to the PersonRepository, which you already know from previous examples. It now extends Spring Data JPA’s JpaRepository and the PersonFragmentRepository.

interface PersonRepository : JpaRepository, PersonFragmentRepository {
    fun findByLastName(lastName: String): List

    @Query("select p from Person p where p.lastName = :lastName")
    fun getByLastName(lastName: String): List

    @Query("select p.firstName, p.lastName, c.name as company from Person p join p.company c")
    fun findPersonsWithCompany(): List
}

When you use this PersonRepository in your business code, Spring Data JPA provides the implementations of all methods defined by the JpaRepository. It also generates the implementations of the 3 query methods. Only the calls to the searchPerson method get delegated to your PersonFragmentRepositoryImpl class.

Summary

As you’ve seen in this article, Kotlin works well with Spring Data JPA. You can model your entities and define repositories in the same way you would in a Java application. Kotlin’s concise syntax often makes these parts of your code easier to read and maintain without changing any persistence behavior. If you follow the established Jakarta Persistence best practices for Kotlin, you get a smooth development experience and an efficient persistence layer.

To learn more about persistence with Kotlin, check out two other articles in this series:

About the author

Thorben Janssen

AI-Assisted Java Application Development with Agent Skills

Siva Katamreddy — Thu, 26 Mar 2026 13:21:10 +0000

Agent-assisted development is quickly becoming a common mode of software development. New techniques are emerging to help LLMs generate code that matches your preferences and standards.

One common approach is to create an AGENTS.md, CLAUDE.md, or GEMINI.md file with project details, build instructions, and coding guidelines. The AI agent loads this file into context on every request.

This has two drawbacks:

It consumes tokens on every request, increasing cost.
Loading too much context into an LLM degrades its effectiveness.

Agent Skills is a new initiative that solves both problems by managing context progressively and extending AI agent capabilities on demand.

What are Agent Skills?

Agent Skills is an open standard introduced by Anthropic, to extend AI agent capabilities with specialized knowledge and workflows.

Consider a use case where you want an AI to generate presentations using your company’s slide template and design guidelines. You can package those assets (the PPT template, font files, and design rules) into a skill. The agent then uses that skill to generate slides that match your standards automatically.

A skill is a folder containing a SKILL.md file. This file includes metadata (name and description at minimum) and instructions that tell an agent how to perform a specific task. Skills can also bundle scripts, templates, and reference materials.

skill-name/
├── SKILL.md          # Required: instructions + metadata
├── scripts/          # Optional: executable code
├── references/       # Optional: documentation
└── assets/           # Optional: templates, resources

The format of a SKILL.md file is:

---
name: name-of-the-skill
description: Skill description.
license: Apache-2.0
metadata:
  author: author/org
  version: "1.0"
compatibility: Requires git, docker, jq, and access to the internet
---

Skill Content

In a SKILL.md file, name and description are required fields, and you can add optional fields like licence, metadata, compatibility, etc. You can explore more about the Skill Specification here.

How do Agent Skills manage context?

At startup, agents load only the metadata (name and description) of installed skills. When you ask the agent to perform a task, it finds the relevant skill and loads only that SKILL.md into context.

This progressive loading keeps context minimal and pulls in additional information only when needed, unlike a monolithic CLAUDE.md that loads everything upfront.

What can be a skill?

Skills extend AI capabilities across a wide range: from coding guidelines for a specific library, to step-by-step workflows with reference documents and helper scripts.

For example, you can create a skill that:

Specifies which library APIs to use and which anti-patterns to avoid.
Bundles reference documentation in a references/ directory.
Includes helper scripts in a scripts/ directory.

Case Study: Implementing Spring Data JPA Pagination

Suppose you ask an AI agent to implement a Spring Boot REST API endpoint that returns a paginated list of Post entities along with their Comment collections.

Without guidance, the agent is likely to produce one of these common mistakes:

N+1 SELECT problem — lazy-loading comments trigger a separate query per post.
In-memory pagination — using JOIN FETCH with pagination loads all rows into memory, then paginates in the application layer.

You can check out the sample code from the GitHub repository https://github.com/sivaprasadreddy/agent-skills-demo

Let us see how an AI Agent might generate code when asked to implement a REST API endpoint to return paginated posts along with comments.

Without any specific guidelines or skills, the AI Agent generated the following implementation:

@RestController
@RequestMapping("/api/posts")
class PostController {
   private final PostService postService;

   PostController(PostService postService) {
       this.postService = postService;
   }

   @GetMapping
   PagedResult getPosts(
           @RequestParam(name = "page", defaultValue = "1") int pageNo,
           @RequestParam(name = "size", defaultValue = "10") int pageSize) {
       return postService.getPosts(pageNo, pageSize);
   }

}


@Service
@Transactional(readOnly = true)
public class PostService {
   private final PostRepository postRepository;

   public PostService(PostRepository postRepository) {
       this.postRepository = postRepository;
   }

   public PagedResult getPosts(int pageNo, int pageSize) {
       Sort sort = Sort.by(Sort.Direction.ASC, "id");
       Pageable pageable = PageRequest.of(pageNo <= 0 ? 0 : pageNo - 1, pageSize, sort);
       Page postPage = postRepository.findAllWithComments(pageable).map(PostDto::from);
       return PagedResult.from(postPage);
   }

}

If you run the application and invoke the GET /api/posts endpoint, you will get the results, but in the logs you will find the below WARNING:

HHH000104: firstResult/maxResults specified with collection fetch; applying in memory

This essentially means, Hibernate will load all the entities into memory and then apply pagination. This will result in poor performance and even OutOfMemory exceptions if there are a large number of rows in the posts table.

A Spring Data JPA skill prevents both issues by giving the agent explicit guidelines and a working code example.

Spring Data JPA Agent Skill

Create a spring-data-jpa/SKILL.md file with the following content:

---
name: spring-data-jpa-skill
description: Implement the persistence layer using Spring Data JPA in Spring Boot applications.
---

Follow the below principles when using Spring Data JPA:

1. Disable the Open Session in View (OSIV) filter: 
spring.jpa.open-in-view=false
2. Disable in-memory pagination: 
spring.jpa.properties.hibernate.query.fail_on_pagination_over_collection_fetch=true

3. Avoid the N+1 SELECT problem: use JOIN FETCH to load associated child collections in a single query.
4. Avoid in-memory pagination: when loading a paginated list of parent entities with child collections:
	* First, load only the parent IDs using pagination
	* Then, load the full entities with their child collections using JOIN FETCH for those IDs
	* Assemble the final Page from the paginated IDs and the loaded entities


## Pagination with child collections example:

PostRepository.java

public interface PostRepository extends JpaRepository {

   @Query("select p.id from Post p order by p.id")
   Page findPostIds(Pageable pageable);

   @Query("select distinct p from Post p left join fetch p.comments where p.id in :ids")
   List findAllByIdInWithComments(@Param("ids") Collection ids);
}


PostService.java

@Service
public class PostService {
   private final PostRepository postRepository;

   public PostService(PostRepository postRepository) {
       this.postRepository = postRepository;
   }

   @Transactional(readOnly = true)
   public Page findPosts(Pageable pageable) {
       Page idsPage = postRepository.findPostIds(pageable);
       if (idsPage.isEmpty()) {
           return Page.empty(pageable);
       }
       List posts = postRepository.findAllByIdInWithComments(idsPage.getContent());
       return new PageImpl<>(posts, pageable, idsPage.getTotalElements());
   }
}

How to use Agent Skills?

Agent Skills work with Claude Code, Codex, Gemini CLI, JetBrains Junie, and other agents. Install a skill at the project level or user level depending on your preference.

Agent	Project-Level	User-Level
Junie	`.junie/skills/`	`~/.junie/skills/`
Claude Code	`.claude/skills/`	`~/.claude/skills/`
Codex	`.agents/skills/`	`~/.agents/skills/`
Gemini CLI	`.gemini/skills/`(or)`.agents/skills/`	`~/.gemini/skills/`(or)`~/.agents/skills/`

To use the Spring Data JPA skill with Claude Code:

Copy the spring-data-jpa/ directory into {project-root}/.claude/skills/.
Ask Claude Code to implement a paginated REST API endpoint.
Claude Code discovers the skill automatically and follows the guidelines.

As you can see, Claude Code automatically discovered the Spring Data JPA skill and generated the following implementation following the guidelines given in the skill.

@Service
public class PostService {
   private final PostRepository postRepository;

   public PostService(PostRepository postRepository) {
       this.postRepository = postRepository;
   }

   @Transactional(readOnly = true)
   public Page findPosts(Pageable pageable) {
       Page idPage = postRepository.findPostIds(pageable);
       if (idPage.isEmpty()) {
           return Page.empty(pageable);
       }
       List posts = postRepository.findAllByIdInWithComments(idPage.getContent());
       return new PageImpl<>(posts, pageable, idPage.getTotalElements());
   }
}

With this implementation, only the Post IDs of the desired page will be loaded first, and then a list of posts along with their comments will be fetched in a separate query. This will fix the pagination in-memory issue.

Using Agent Skills with Junie

You can use the JetBrains Junie Agent to generate code which automatically loads the necessary skills from .junie/skills and directory.

The Junie agent loaded spring-data-jpa skill based on the given task and applied the guidelines. You can also observe that Junie automatically runs the relevant tests to verify the generated code is working or not and iterate until the tests are passed.

In the sample repository https://github.com/sivaprasadreddy/agent-skills-demo, you can find the following branches to try out the spring-data-jpa Agent Skill:

main: Starting point to try implementing the mentioned usecase without any skills.
in-memory-pagination-issue: Usecase implementation generated by AI that results in in-memory pagination issue.
skills: With spring-data-jpa skill to try implementing the mentioned usecase.

Summary

If the AI agent is generating code with any anti-patterns or not following team coding standards and conventions, instead of fixing issues one-by-one with follow-up prompts, consider creating a skill to provide those as guidelines.

To explore more on Agent Skills, please refer to the following resources:

IntelliJ IDEA 2026.1 Is Out!

Maria Kosukhina — Wed, 25 Mar 2026 14:28:29 +0000

IntelliJ IDEA 2026.1 is here, and it comes packed with an array of new features and enhancements to elevate your coding experience!

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.

As always, all new features are brought together on the What’s New page, with detailed explanations and demos.

Explore the What’s New page

In addition to the What’s New page, our developer advocates got together to discuss and demonstrate the key updates. If you prefer watching to reading, check it out.

IntelliJ IDEA 2026.1 brings built-in support for more AI agents, including Codex, Cursor, and any ACP-compatible agent, and delivers targeted, first-class improvements for Java, Kotlin, and Spring. The release also advances IntelliJ IDEA’s mission to provide support for the latest languages and tools from day one.

Please note that some AI features may work differently or be unavailable in your region. Learn more.

Any agent, built-in:

ACP Registry: Browse and install AI agents in one click.
Git worktrees: Work in parallel branches and hand one off to an agent while you keep moving in another.
Database access for AI agents: Let Codex or Claude Agent query and modify your data sources natively.

Intelligence in the platform:

Quota-free next edit suggestions: Propagate changes throughout a given file with IDE-driven assistance.
Spring runtime insight: Inspect injected beans, endpoint security, and property values without pausing execution.
Kotlin-aware JPA: Detect and fix Kotlin-specific pitfalls in Jakarta Persistence entities.

First-class language support:

Java 26: Enjoy day-one support, including preview features.
Kotlin 2.3.20: Enjoy day-one support, including experimental features.
C/C++ in IntelliJ IDEA: Access first-class C/C++ coding assistance for multi-language projects.
Support for JavaScript without an Ultimate subscription.

Productivity and environment:

Expanded command completion, now with AI actions, postfix templates, and config file support.
Better performance for large-scale TypeScript projects.
Native Dev Container workflow: Open containerized projects as if they were local.

Along with new features, 2026.1 delivers numerous stability, performance, and usability improvements across the platform. These are described in a separate What’s Fixed blog post.

As always, your feedback plays an important role in shaping IntelliJ IDEA. Tell us what you think about the new features and help guide future improvements.

Join the discussion on X, LinkedIn, or Bluesky, and if you encounter any issues, please report them via YouTrack.

For full details of the improvements introduced in version 2026.1, refer to the release notes.

Thank you for using IntelliJ IDEA. Happy developing!

What’s fixed in IntelliJ IDEA 2026.1

Dmitriy Smirnov — Wed, 25 Mar 2026 10:48:22 +0000

Welcome to the overview of fixes and improvements in IntelliJ IDEA 2026.1.

In this release, we have resolved over 1,000 bugs and usability issues, including 334
reported by users. Below are the most impactful changes that will help you work with greater confidence every day.

Performance

We continue to prioritize reliability, working to improve application performance, fix freezes, optimize operations, and cover the most common use cases with metrics. Using our internal tools, we identified and resolved 40 specific scenarios that caused UI freezes.

However, internal tooling alone cannot uncover every issue. To identify additional cases, we enabled automatic error and freeze reporting in EAP builds. By collecting this data, we gain a real, unfiltered picture of what’s going wrong, how often it happens, and how many users are affected. This allows us to prioritize fixes based on real impact rather than guesswork.

As always, we prioritize your privacy and security. When using EAP builds, you maintain full control and can disable automatic error and freeze reporting in Settings | Appearance & Behavior | System Settings | Data Sharing. Thank you for helping us build better tools!

Terminal

Version 2026.1 enhances your productivity by streamlining the experience offered by the terminal, a crucial workspace for developer workflows involving CLI-based AI agents.

First, we fixed the Esc behavior – it is now handled by the shell instead of switching focus to the editor, so it does not break the AI-agent workflow. Additionally, Shift+Enter now inserts a new line, making it easier to write multi-line prompts and commands directly. This behavior can be disabled in Settings | Advanced Settings | Terminal.

We also improved the detection of absolute and relative file paths in terminal output, allowing you to open files and folders with a single click in any context. When you encounter compilation or build errors, or submit a task to an AI coding agent, you can jump directly to the referenced file and review or fix issues faster.

Link navigation is activated by holding Ctrl (or Cmd on macOS) and clicking – just like in external terminals.

JVM language support

Better Kotlin bean registration support

Kotlin’s strong DSL capabilities are a perfect fit for Spring Framework 7’s BeanRegistrar API. In 2026.1, we’ve made working with programmatic registration as productive as annotation-based configuration.

The IDE ensures complete visibility into your application structure thanks to the Structure tool window, providing better endpoint visibility, intuitive navigation with gutter icons, integrated HTTP request generation, and path variable support.

New Kotlin coroutine inspections

To help maintain code quality, we’ve introduced a set of new inspections for the Kotlin coroutines library, covering common pitfalls.

Read more about coroutine inspections in this article.

Scala

Working with sbt projects inside WSL and Docker containers is now as smooth as working with local projects. We’ve also improved code highlighting performance and sped up sbt project synchronization.

To reduce cognitive load and provide a more ergonomic UI, we’ve redesigned the Scala code highlighting settings. A new Settings page consolidates previously scattered options, making them cleaner, more intuitive, and easier to access.

You can now disable built-in inspections when compiler highlighting is sufficient, or configure compilation delay for compiler-based highlighting. Settings for Scala 2 and Scala 3 projects are now independent, and the type-aware highlighting option has been integrated with the rest of the settings.

You can read more about these updates this article.

Spring

Spring support remains a core focus for IntelliJ IDEA. We are committed to maximizing reliability and reducing friction in your daily development.

In this release, we made a dedicated effort to address issues related to running Spring Boot application from the IDE. There are now even fewer reasons to run your application in the terminal – just run it in the IDE and use the debugger when you need deeper insights.

Spring Boot 4 API versioning support

This is a new Spring Boot feature, and we keep improving its support based on your feedback. In this version, we added .yml files support for version configuration, fixed false positives and added a couple of useful inspections, so you get an instant feedback about issues without running the app.

Flyway DB Migrations

To ensure a reliable and distraction-free experience, the IDE now verifies migration scripts only when a data source is active, eliminating false-positive errors when the data source is disconnected.

At the same time, Flyway scripts got correct navigation to the table definitions, and SQL autocompletion for any files and tables defined in them.

User interface

With IntelliJ IDEA 2026.1, we’ve continued to prioritize ultimate comfort and an ergonomic UI, ensuring your workspace is as accessible and customizable as your code.

The long-awaited ability to sync the IDE theme with the OS is now available to Linux users, bringing parity with macOS and Windows. Enable it in Settings |Appearance & Behavior | Appearance.

The code editor now supports OpenType stylistic sets. Enjoy more expressive typography with your favorite fonts while coding. Configure them via Editor |Font, and preview glyph changes instantly with a helpful tooltip before applying a set.

Windows users who rely on the keyboard can now bring the IDE’s main menu into focus by pressing the Alt key. This change improves accessibility for screen reader users.

Version control

We continue to make small but impactful improvements that reduce friction and support your everyday workflow.

You can now [coming in 2026.1.1 update] amend any recent commit directly from the Commit tool window – no more ceremonies involving interactive rebase. Simply select the target commit and the necessary changes, then confirm them – the IDE will take care of the rest.

In addition to Git worktrees, we’ve improved branch workflows by introducing the Checkout & Update action, which pulls all remote changes.

Furthermore, fetching changes can now be automated – no need for a separate plugin. Enable Fetch remote changes automatically in Settings | Git.

In-IDE reviews for GitLab merge requests now offer near feature parity with the web interface. Multi-line comments, comment navigation, image uploads, and assignee selection when creating a merge request are all available directly in the IDE, so you can stay focused without switching to the browser.

The Subversion, Mercurial, and Perforce plugins are no longer bundled with the IDE distribution, but you can still install them from JetBrains Marketplace.

Databases

We’ve enhanced the Explain Plan workflow with UI optimizations for the Query Plan tab, an additional separate pane for details about the execution plan row, inner tabs that hold flame graphs, and an action to copy the query plan in the database’s native format.

JetBrains daemon

IntelliJ IDEA 2026.1 includes a lightweight background service – jetbrainsd – that handles jetbrains:// protocol links from documentation, learning resources, and external tools, opening them directly in your IDE without requiring you to have the Toolbox App running.

Sunsetting of Code With Me

As of version 2026.1, Code With Me will be unbundled from all JetBrains IDEs and will instead be available as a separate plugin on JetBrains Marketplace. Version 2026.1 will be the last IDE release to officially support Code With Me as we gradually sunset the service.

Read the full announcement and timeline in our blog post.

Enhanced AI management and analytics for organizations

We are working hard to provide development teams with centralized control over AI and built-in analytics to understand adoption, usage, and cost. As part of the effort, we’ve introduced the JetBrains Console. It adds visibility into how your teams use AI in practice, including information about active users, credit consumption, and acceptance rates for AI-generated code.

The JetBrains Console is available to all organizations with a JetBrains AI subscription, providing the trust and visibility required to manage professional-grade development at any scale.

That’s it for this overview.

Let us know what you think about the fixes and priorities in this release. Your feedback helps us steer the product so it works best for you!

We’d also love to hear your thoughts on this overview and the format in general.

Update to IntelliJ IDEA 2026.1 now and see how it has improved. Don’t forget to join us on X , Bluesky, or LinkedIn and share your favorite updates.

Thank you for using IntelliJ IDEA!

Core JavaScript and TypeScript Features Become Free in IntelliJ IDEA

Julia Shashkova — Thu, 19 Mar 2026 11:43:34 +0000

Modern Java development often involves web technologies. To make this workflow more accessible and smoother, we’re making some core JavaScript, TypeScript, HTML, and CSS features – previously included with the Ultimate subscription only – available for free in IntelliJ IDEA v2026.1.

JavaScript, TypeScript, HTML, CSS, and React Support

Enjoy a comprehensive set of features for building modern web applications:

Basic React support, including code completion, component and attribute navigation, and React component and prop rename refactorings.

Full syntax highlighting for JavaScript, TypeScript, HTML, and CSS, ensuring better readability and usability of frontend code inside the IDE.
Reliable code completion to write code faster and with fewer errors across both backend and frontend parts of your web application.

Advanced import management automatically handles JavaScript and TypeScript imports as you code, adds missing references when pasting code, and cleans up unused ones with Optimize Imports – helping you save time, reduce errors, and keep your codebase clean.
Smooth code navigation via dedicated gutter icons for Jump to… actions, recursive calls, TypeScript source mapping, and more.

Code Intelligence and Code Quality

Improve and maintain your web code with built-in intelligence and quality tools:

Core web refactorings: Make changes to your code with reliable Rename refactorings and actions (Introduce Variable, Introduce Constant, Change Signature, Move Members, and more).
Quality control: Identify potential issues early with built-in inspections, intentions, and quick fixes, and get improvement suggestions as you code.
Code cleanup: Keep your codebase clean with JavaScript and TypeScript duplicate detection, making it easier to spot and eliminate redundant code.

Integrated workflows

Now it’s easier to manage, maintain, and secure your web projects from within a single environment.

Create new web projects quickly by using the built-in Vite generator.
Keep your codebase consistent and clean with integrated support for Prettier, ESLint, TSLint, and StyleLint.
Execute NPM scripts directly from package.json.
Monitor your project dependencies and identify known security vulnerabilities early.

Enjoy building your web applications with IntelliJ IDEA, and happy developing!

If you need more advanced tools (dedicated debugger, test runners, test UI tooling, support for all frontend frameworks including Angular, Vue, advanced refactorings, and more) for full-stack application development, you can try them with the Ultimate subscription trial. The trial provides 30 days of full access – no credit card required.

IntelliJ IDEA’s New Kotlin Coroutine Inspections, Explained

Irina Mariasova — Thu, 19 Mar 2026 10:00:58 +0000

This article was written by an external contributor.

Marcin Moskała

Marcin is a highly experienced developer and Kotlin instructor, founder of Kt. Academy, an official JetBrains partner specializing in Kotlin training. He is also a Google Developers Expert and a well-known contributor to the Kotlin community. Marcin is the author of several widely recognized books, including Effective Kotlin, Kotlin Coroutines, Functional Kotlin, Advanced Kotlin, Kotlin Essentials, and Android Development with Kotlin.

Website

Every technology has its misuses, and different ecosystems use different approaches to prevent them. In the Kotlin ecosystem, I believe the philosophy has always been to make APIs so good that correct usage is simple and intuitive, while misuse is harder and more complicated. This differs from JavaScript, which has plenty of legacy practices (like using == instead of ===, or var instead of let/const) and relies more on warnings. However, not everything can be enforced by good design, and Kotlin also uses warnings to guide developers in writing better code.

Today, IntelliJ IDEA introduces a set of new inspections for the Kotlin coroutines library. I’ve seen these issues in many codebases and addressed them through my books, articles, and workshops. These patterns often show up, so let’s walk through why they are problematic and how to handle them correctly.

Note: These inspections are also available in Android Studio. You can check how IntelliJ IDEA versions map to Android Studio versions here.

`awaitAll()`and `joinAll()`

Available since IntelliJ IDEA 2025.2

If you use map { it.await() }, IntelliJ IDEA will suggest awaitAll(). If you use forEach { it.join() }, it will suggest joinAll(). Why? These alternatives are cleaner, and awaitAll() is also more efficient and better represents waiting for multiple tasks, as it waits for all elements concurrently rather than one after another.

awaitAll() also behaves more efficiently in the presence of exceptions. Imagine awaiting 100 coroutines, and the fiftieth throws an exception. awaitAll() will immediately rethrow the exception, unlike map { it.await() }, which would wait for the first 49 coroutines before throwing the exception. In most cases, this behavior cannot be observed because of other exception propagation mechanisms.

`currentCoroutineContext()` over `coroutineContext`

Available since IntelliJ IDEA 2025.2

All suspending functions can access the context of the coroutine in which they are called. Traditionally, this was done via the coroutineContext property. The problem is that CoroutineScope, which is implicitly available in coroutine starters, such as launch, coroutineScope, and runTest, has a property with the same name. This can be confusing and lead to issues. Consider the following example:

This code tests the mapAsync function and checks whether it correctly propagates context from the caller to the transformation. It is incorrect. Within the transformation, we could read the caller context from the coroutineContext, but not in this situation. This lambda is defined inside runTest, and the coroutineContext property from CoroutineScope (provided by runTest) takes priority over the top-level coroutineContext property. This kind of mistake is quite common, which is why the currentCoroutineContext() function was introduced to read the context of the coroutine that runs a suspending function. You should use it instead of coroutineContext.

`runBlocking` inside a suspending function

Available since IDEA 2025.2

Using runBlocking inside suspending functions is a serious issue. It blocks the calling thread, which defeats the purpose of coroutines.

So what can you use instead? That depends on what you want to achieve. In most cases, you don’t need it. If you need to create a coroutine scope, use coroutineScope { … }. If you need to change context, use withContext(ctx) { … }.
Watch out for situations where a suspending function calls a regular function that uses runBlocking. Opt for making this function suspend to avoid making a blocking call.

Unused `Deferred`

Available since IntelliJ IDEA 2025.3

This inspection appears when you use async without ever using its result. In such cases, you should use launch instead. This is the key difference between launch and async: async returns a result and is expected to await this result, while launch produces no result.

Because of this, exception handling differs. async doesn’t call CoroutineExceptionHandler because it is expected to throw an exception from await and propagate it this way.

`Job` used as an argument in a coroutine starter

Available since IntelliJ IDEA 2025.3

I’ve been looking forward to this inspection for years! Using Job as an argument to a coroutine starter causes issues, and it’s something I’ve seen in many projects. I covered this anti-pattern in my book and workshops, but it still appears quite often. This inspection should help clarify the correct approach. Let’s look at why Job shouldn’t be used as an argument for a coroutine.

The key misunderstanding here is that Job cannot be overridden by an argument. If you use any other context, it will be used in the coroutine and its children, but not Job. Every coroutine creates its own job. A job contains a coroutine’s state and relations – it cannot be shared or enforced from outside. The Job that is used as an argument isn’t going to be a job of this coroutine. Instead, it overrides Job from the scope and becomes a parent. This breaks structured concurrency.

For example: Using withContext(SupervisorJob()) { … } behaves very differently from supervisorScope { … }.

supervisorScope creates a child coroutine of the caller of this function, and it uses a supervisor job (it doesn’t propagate its children’s exceptions). On the other hand, withContext(SupervisorJob()) creates a regular coroutine, which is a child of SupervisorJob and has no relation to the caller.

Consider the code below. An exception in the first launch propagates to withContext (which uses regular Job), cancels the other child coroutines, and is then rethrown. SupervisorJob() has no effect. In some cases, it can even be harmful, as it breaks structured concurrency. If the caller of withContext(SupervisorJob()) is cancelled, that cancellation won’t propagate, which will result in a memory leak.

import kotlinx.coroutines.*

val handler = CoroutineExceptionHandler { _, e ->
   println("Exception:  ${e.message}")
}

fun main(): Unit = runBlocking(handler) {
   // DON'T DO THAT!
   withContext(SupervisorJob()) {
       launch {
           delay(1000)
           throw Error("Some error")
       }
       launch {
           delay(2000)
           println("AAA")
       }
   }
  println("Done")
}
// (1 sec)
// Exception in thread "main"...

Using supervisorScope would prevent this problem:

import kotlinx.coroutines.*

val handler = CoroutineExceptionHandler { _, e ->
   println("Exception:  ${e.message}")
}

fun main(): Unit = runBlocking(handler) {
  supervisorScope {
      launch {
          delay(1000)
          throw Error("Some error")
      }
      launch {
          delay(2000)
          println("AAA")
      }
  }
  println("Done")
}
// (1 sec)
// Exception:  Some error
// (1 sec)
// AAA
// Done

A Job used as an argument breaks the relationship with the caller. In the case below, updateToken won’t be related to the caller of getToken:

suspend fun getToken(): Token = coroutineScope {
   val token = tokenRepository.fetchToken()
   launch(Job()) { // Poor practice
       tokenRepository.updateToken(token)
   }
   token
}

This is generally discouraged, as it breaks structured concurrency. The standard approach would be to sequentially call updateToken:

suspend fun getToken(): Token {
   val token = tokenRepository.fetchToken()
   tokenRepository.updateToken(token)
   return token
}

If we really want to detach updateToken from getToken, a better practice would be to start the launch on a different scope, like the backgroundScope we define in our application for background tasks. With this approach, the new coroutine is still attached to a scope, just a different one:

suspend fun getToken(): Token {
   val token = tokenRepository.fetchToken()
   backgroundScope.launch { // Acceptable
       tokenRepository.updateToken(token)
   }
   return token
}

`suspendCancellableCoroutine` instead of `suspendCoroutine`

Available since IntelliJ IDEA 2025.3

To suspend a coroutine, use suspendCancellableCoroutine. Its predecessor, suspendCoroutine, does not support cancellation and should be avoided.
suspendCancellableCoroutine is a low-level API rarely used in application code, but often used by libraries that support suspending calls.

Suspicious implicit `CoroutineScope` receiver

Available since IntelliJ IDEA 2025.3, but this inspection is disabled by default and must be enabled manually.

Implicit receivers within lambdas can be confusing. In the above example, async calls are executed on the scope created by coroutineScope because collectLatest doesn’t provide its own scope. This can lead to memory leaks. When a new value reaches collectLatest, it should cancel processing of the previous one. In this example, it cannot cancel the async coroutines, as they are attached to coroutineScope, not to collectLatest. To avoid this, define coroutineScope inside collectLatest, not outside it. This inspection highlights such cases to prevent these issues.

Simpler operations for flow processing

Available since IntelliJ IDEA 2026.1 (currently in EAP)

You may already know these from collection or sequence processing:
If you use filterNotNull after map, you’ll get the suggestion to use mapNotNull. If you use filter { it is T }, the IDE will suggest using filterNotNull.
These suggestions are now also available for flows!

Summary

IntelliJ IDEA continues to help you write better code – not only by advancing its AI tools and agents, but also by improving the core development experience. There are still many inspections I would love to see in the IDE, but the current set already brings significant value.

IntelliJ IDEA 2025.3.4 is Out!

Julia Shashkova — Tue, 17 Mar 2026 17:25:08 +0000

We’ve just released IntelliJ IDEA 2025.3.4. This update introduces full support for Java 26 along with several notable improvements.

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 improvements:

Resolved an issue where running an HTTP request could trigger a different request in the same file. [IJPL-66727]
Local changes refresh in large Perforce projects now works as expected. [IJPL-236557]
The Dependencies tab now opens correctly when using the Analyze Cyclic Dependencies feature. [IJPL-206236]

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

Happy developing!

Java 26 in IntelliJ IDEA

Marit van Dijk — Tue, 17 Mar 2026 14:17:33 +0000

The Java release cadence means we get a new Java version every six months. Java 26 was released on March 17, 2026. At JetBrains, we are committed to supporting the latest technologies in IntelliJ IDEA and adding useful enhancements for both stable and preview features. In this blog post, we will give you an overview of what Java 26 delivers and how it is supported in IntelliJ IDEA.

Java 26 delivers ten JEPs, of which five are final. There are no new stable language features in this release, but there are meaningful performance improvements and new library additions. In addition, several preview features continue to mature.

We are also happy to share that a JetBrains colleague contributed a small but useful improvement to the Java platform.

Before diving in, let’s start by setting up IntelliJ IDEA to use Java 26.

Using Java 26 in IntelliJ IDEA (setup)

Java 26 support is available in IntelliJ IDEA.

To use Java 26, you will need to download the JDK. You can do so from inside IntelliJ IDEA or by using tools like SDKMAN!

To download a JDK 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 26, and in the Vendor field, select the vendor you want to use.

Note that you can also download early access builds from inside IntelliJ IDEA. For example, Java 26 also introduced a new build of Project Valhalla, which is also available for download.

Download JDK 26 Valhalla Early Access

IntelliJ IDEA already has support for value classes from Project Valhalla, as demonstrated in the What’s New In IntelliJ IDEA 2025.3 video:

What’s New In IntelliJ IDEA 2025.3 – Java 26 Valhalla Early Access value type support

If you use SDKMAN! or asdf to manage your JDKs, IntelliJ IDEA can read the .sdkmanrc or .tool-versions file in your project and configure the JDK automatically when you open the file. For example, if you are 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.

Run sdk install java 26

If it is already installed but not yet configured for the project, there will be an inlay hint Set as project JDK. Click the inlay hint to set the mentioned JDK version for the project. Once set, there will be an inlay hint Project JDK (26). Click the link to open the Project Structure popup where the SDK is set.

Set project SDK using .sdkmanrc

Make sure to configure IntelliJ IDEA to use the right language level. To use Java 26 stable features, set Language level to 26 – No new language features. As mentioned, Java 26 introduces no new stable language features, hence this description.

Language Level: 26 – No new language features

To try out preview features, set Language level to 26 (Preview) – Primitive types in patterns (4th preview). Setting the right language level means that IntelliJ IDEA will show support for this language level in the editor, including inspections and quick-fixes. Usage of preview features will be highlighted as such, as you might not want to use preview features in production code yet.

Language Level: 26 (Preview) – Primitive types in patterns (4th preview)

When you set the language level to Java 26 (either stable or preview), IntelliJ IDEA will show you all relevant inspections. To see which inspections were added in the last version of IntelliJ IDEA, open Settings | Editor | Inspections, click on the Filter Inspections button, and select Show New Inspections in IDEA 2026.1.

New Inspections in IDEA 2026.1

A full list of inspections is available on Inspectopedia. In upcoming releases of IntelliJ IDEA, we will continue to add more inspections for Java language support, based on current and new language features.

New stable features in Java 26

Let’s take a quick look at the features Java 26 introduces.

JEP 516: Ahead-of-Time Object Caching with Any GC

Java continues to improve startup time and warmup performance, as part of Project Leyden. JEP 516 extends the HotSpot JVM’s ahead-of-time (AOT) cache to work with any garbage collector, including the low-latency ZGC, by storing cached Java objects in a GC-agnostic format and loading them sequentially into memory at startup.

JEP 517: HTTP/3 for the HTTP Client API

Update the HTTP Client API, introduced in Java 11, to support the HTTP/3 protocol, to make it possible for libraries and applications to interact with HTTP/3 servers with minimal changes to the code. This allows applications using the HTTP Client API to benefit from improvements offered by the HTTP/3 protocol, such as potentially faster handshakes, more reliable transport, and avoidance of network congestion issues. The HTTP/3 protocol is already supported by most web browsers and almost 40% of all websites.

JEP 522: G1 GC: Improve Throughput by Reducing Synchronization

This JEP improves application throughput for applications using the G1 garbage collector by reducing the synchronization required between application threads and GC threads.

JEP 500: Prepare to Make Final Mean Final

JDK 26 introduces warnings when deep reflection is used to mutate a final field, aiming to prepare developers for a future release where final truly means final, making Java programs both safer and potentially faster. Applications that rely on this pattern can update their code ahead of the eventual restriction, or selectively opt back in where truly needed.

JEP 504: Remove the Applet API

The Applet API, deprecated for removal since JDK 17, has been removed. Neither modern browsers nor recent JDK releases still support applets.

Preview features in Java 26

With Java’s release cadence of six months, new language features are often released as preview features. This gives developers a chance to try out new features and provide their feedback before these features become final. A preview feature may go through multiple rounds, either with or without changes, before it is finalized as a standard part of the language.

IntelliJ IDEA strives to support preview features, allowing you to experiment with them before they become final. Because of how these features work, IntelliJ IDEA is committed to only supporting preview features for the current JDK. To enable preview features, set Language level to 26 (Preview) – Primitive types in patterns (4th preview).

Java 26 contains four preview features and one incubator feature. There are several changes to the preview features in Java 26, compared to Java 25.

JEP 530: Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

This feature enhances pattern matching to support all primitive types in pattern contexts, including instanceof and switch. This feature lifts some of the existing limitations in 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, this feature improves code safety and readability. This feature is previewed again, with some changes since Java 25, which add some constraints (see JEP for details).

For a quick example of using primitive types in switch expressions with guard patterns, see Java 24 and IntelliJ IDEA. For a longer explanation of the feature, see the section Primitive Types in Patterns, instanceof, and switch (Preview Feature) in Java 23 and IntelliJ IDEA. Note that there are some changes to this feature in the latest preview.

For more background information on this feature, watch the following video:

JEP Explained. JEP 455: Primitive Types in Patterns, instanceof, and switch

JEP 526: Lazy Constants (Second Preview)

As Java programmers, we are aware that we should strive for immutability, as it offers many benefits. Since an immutable object can be in only one state, it can be safely shared across multiple threads. The current way to manage immutability is to declare fields final. However, final fields must be set eagerly, either during construction for instance fields or during class initialization for static fields. This initialization leads to longer startup times and might not even be necessary if the fields are not actually used.

Lazy constants offer greater flexibility as to the timing of their initialization. They are, as the name implies, initialized lazily. A lazy constant is a java.lang.LazyConstant object holding a single immutable value that is set only when first needed. The JVM treats them as true constants and applies the same performance optimizations.

To be eligible for constant folding (the process of simplifying constant expressions at compile time), a lazy constant must be stored in a final field. IntelliJ IDEA 2026.1 adds an inspection and quick-fix to make a LazyConstant final.

Make LazyConstant final

There are some changes to this feature compared to Java 25, mainly focusing on high-level use cases, removing low-level methods, and renaming the feature accordingly – from stable values to lazy constants.

JEP 525: Structured Concurrency (Sixth Preview)

Structured concurrency gives us better “idioms” for multithreaded code, which expresses the synchronous way of thinking. This makes concurrent code easier to understand and reason about. In addition, it helps to eliminate thread leaks and cancellation delays. It treats a group of related tasks running in different threads as a single unit of work, improving observability, cancellation, and error handling in concurrent code.

IntelliJ IDEA has a live template sts to add structured concurrency to your code. If you know a live template exists, you can use it by name.

Insert live template sts for structured concurrency

IntelliJ IDEA 2026.1 includes some improvements to the debugger regarding virtual threads. Virtual threads are grouped into containers representing their scopes, making it easy to see which threads are virtual and which are platform threads. Any virtual thread without its own container is placed under the Root container. This grouping is new and gives you a clear view of the structure in structured concurrency.

Get Thread Dump with Debugger

For background information on structured concurrency, watch the following video:

JEP Explained. JEP 480: Structured Concurrency

Note that there have been changes to this preview feature since the video was recorded.

JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)

This JEP provides a preview API for encoding and decoding cryptographic objects to/from the Privacy-Enhanced Mail (PEM) format. The second preview contains some changes compared to the previous version.

Incubator features in Java 26

Incubator features are experimental APIs made available for developers to try out and provide feedback on. Unlike preview features, incubator APIs may change significantly or even be removed in future releases and are not intended for production use.

To use an incubator feature, you’ll need to explicitly add the module while you run it. To use Vector API, add the following: --add-modules jdk.incubator.vector.

If you are running your program from IntelliJ IDEA, you can add this 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 option --add-modules jdk.incubator.vector to that field.

Add VM Options

JEP 529: Vector API (Eleventh Incubator)

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.

This eleventh incubator contains no substantial changes compared to the previous version. The Vector API will continue to incubate until the necessary features from Project Valhalla are available, at which point it will be adapted and promoted to preview.

For background information on Vector API, watch the following video:

JEP Explained. JEP 469: Vector API

Contributions to the Java platform

When we spot an opportunity to make Java safer or less error-prone, we, of course, try to provide useful features in IntelliJ IDEA to help you write better code. But we also try to contribute improvements back to the platform.

Our colleague Tagir Valeev – author of 100 Java Mistakes and How to Avoid Them – contributed two new default methods to java.util.Comparator: min(T, T) and max(T, T). These make it straightforward to find the lesser or greater of two objects using a given comparator, without needing verbose workarounds. You can find more details in JDK-8356995. We are happy to see this change accepted into the platform!

Conclusion

Java 26 may not be an LTS release, but it brings meaningful performance improvements, useful library additions, and continues to evolve several important preview features. IntelliJ IDEA supports Java 26 from day one, so you can start taking advantage of everything this release has to offer right away.

IntelliJ IDEA will continue to support the latest Java features. As always, please let us know if you have any feedback.

Koog Comes to Java: The Enterprise AI Agent Framework From JetBrains

Vadim Briliantov — Tue, 17 Mar 2026 09:57:20 +0000

Adding AI agents to your enterprise backend shouldn’t mean compromising your architecture. If your core systems are built in Java, orchestrating LLMs shouldn’t require you to introduce separate Python microservices or rewrite your stack.

Today, we are launching Koog for Java. Originally built to keep pace as JetBrains scaled up its own activities, Koog replaces unpredictable, ad hoc prompt changing with structured, observable, and fault-tolerant agent workflows.

Now, one of the JVM’s most powerful agent frameworks comes with a fully idiomatic Java API. Your Java teams can build reliable AI agents directly inside your existing backends, with fluent builder-style APIs, thread pool executors, and native Java abstractions – completely free of Kotlin-specific friction.

What you get with Koog for Java

The Java API provides access to all of Koog’s features:

Multiple workflow strategies (functional, graph-based, and planning): Control exactly how your agent executes tasks.
Spring Boot integration: Drop Koog into your existing Spring applications.
Support for all major LLM providers: Use your preferred models from OpenAI, Anthropic, Google, DeepSeek, Ollama, and more.
Fault tolerance with Persistence: Recover from failures without losing progress or repeating expensive LLM calls.
Observability with OpenTelemetry: Get full visibility into agent execution, token usage, and costs, with Langfuse and W&B Weave support out of the box
History compression: Reduce token usage and optimize costs at scale
And much more!

Read on to see what building agents in Java with Koog looks like.

Simple setup

AI agents work by connecting large language models (LLMs) with functions from your application, which are generally referred to as “tools”. The LLM decides which tools to call and when, based on the task you give it. Building an agent in Java starts with defining these tools. Annotate your existing Java methods with @Tool and add descriptions so the LLM understands what each function does:

public class BankingTools implements ToolSet {
    @Tool
    @LLMDescription("Sends money to a recipient")
    public Boolean sendMoney(
        @LLMDescription("Unique identifier of the recipient")
        String recipientId,
        Integer amount
    ) {
        return true; // Your implementation here
    }

    @Tool
    @LLMDescription("Account balance in $")
    public Integer getAccountBalance(String userId) {
        return 1000000; // Your implementation here
    }
}

Next, create an agent using the builder API. You’ll need to configure which LLM providers to use (OpenAI, Anthropic, etc.), set a system prompt that defines the agent’s role, and register your tools:

// Connect to one or more LLM providers
var promptExecutor = new MultiLLMPromptExecutor(
    new OpenAILLMClient("OPENAI_API_KEY"),
    new AnthropicLLMClient("ANTHROPIC_API_KEY")
);

// Build the agent
var bankingAgent = AIAgent.builder()
    .promptExecutor(promptExecutor)
    .llmModel(OpenAIModels.Chat.GPT5_2)  // Choose which model to use
    .systemPrompt("You're a banking assistant")  // Define the agent's role
    .toolRegistry(
        ToolRegistry.builder()
            .tools(new BankingTools())  // Register your tools
            .build()
    )
    .build();

// Run the agent with a user task
bankingAgent.run("Send 100$ to my friend Mike (mike_1234) if I have enough money");

When you run this agent, it will:

Check the account balance using getAccountBalance()
If there’s enough money, call sendMoney() with the right parameters
Return a response to the user

This connects your Java application’s functionality with a fully autonomous AI agent that can reason about which actions to take.

Predictable workflows with custom strategies

The simple example above lets the LLM decide everything – which tools to call and in what order. But for production systems, you often need more control. What if you want to ensure certain operations happen before others? Or limit which tools are available at each step? Or implement verification loops?

Koog provides different approaches to defining agent workflows: functional (code-based), graph-based, and planning-based.

Functional strategies let you orchestrate individual agentic steps in code. Think of it like writing a regular Java method, but each step can involve LLM calls and tool executions. You split large tasks into smaller subtasks, each with its own prompt, limited set of tools, and type-safe inputs/outputs:

var functionalAgent = AIAgent.builder()
    .promptExecutor(promptExecutor)
    .functionalStrategy("my-strategy", (ctx, userInput) -> {
        // Step 1: First, identify the problem
        // Only give the agent communication and read-only database access here
        ProblemDescription problem = ctx
            .subtask("Identify the problem: $userInput")
            .withOutput(ProblemDescription.class)  // Type-safe output
            .withTools(communicationTools, databaseReadTools)  // Limited tools
            .run();

        // Step 2: Now solve the problem
        // Give the agent database write access only after problem identification
        ProblemSolution solution = ctx
            .subtask("Solve the problem: $problem") // Use output from step 1
            .withOutput(ProblemSolution.class)
            .withTools(databaseReadTools, databaseWriteTools)
            .run();

        // Verify the solution and try to fix it until the solution is satisfying
        while (true) {
            var verificationResult = ctx
                .subtask("Now verify that the problem is actually solved: $solution")
                .withVerification()
                .withTools(communicationTools, databaseReadTools)
                .run();

            if (verificationResult.isSuccessful()) {
                return problemSolution;
            } else {
                problemSolution = ctx
                    .subtask("Fix the solution based on the provided feedback: ${verificationResult.getFeedback()}")
                    .withOutput(ProblemSolution.class)
                    .withTools(databaseReadTools, databaseWriteTools)
                    .run();
            }
        }

    })
    .build();

This approach gives you the flexibility of code while still using AI agents for individual steps. Notice how you control the order of operations and which tools are available at each step. You can check the full runnable example here.

Graph strategies define workflows as finite state machines with type-safe nodes and edges. Unlike functional strategies, graph strategies separate the logic (nodes and edges) from its execution. This enables powerful features like fine-grained persistence – if your agent crashes, it can resume from the exact node where it stopped, not from the beginning:

var graphAgent = AIAgent.builder()
    .graphStrategy(builder -> {
        // Define the overall graph structure
        var graph = builder
            .withInput(String.class)
            .withOutput(ProblemSolution.class);

        // Define workflow elements: individual nodes (steps) and subgraphs
        var identifyProblem = AIAgentSubgraph.builder()
            .withInput(String.class)
            .withOutput(ProblemDescription.class)
            .limitedTools(communicationTools, databaseReadTools)
            .withTask(input -> "Identify the problem")
            .build();

        var solveProblem = … // subgraph for solving a problem
        
        var verifySolution = … // subgraph for verifying a solution
        
        var fix = ...// subgraph for fixing a problem

        // Connect the nodes with edges to define execution flow
        graph.edge(graph.nodeStart, identifyProblem);
        graph.edge(identifyProblem, solveProblem);
        graph.edge(solveProblem, verifySolution);

        // Conditional edges: if verification succeeds, finish; otherwise, attempt a fix
        graph.edge(AIAgentEdge.builder()
        	.from(verifySolution)
        	.to(graph.nodeFinish)
        	.onCondition(CriticResult::isSuccessful)
        	.transformed(CriticResult::getInput)
        	.build());

        graph.edge(AIAgentEdge.builder()
        	.from(verifySolution)
        	.to(fix)
        	.onCondition(verification -> !verification.isSuccessful())
        	.transformed(CriticResult::getFeedback)
        	.build());

        graph.edge(fix, verifySolution);

        return graph.build();
    })
    .build();

Graph strategies are ideal when you need persistence, complex branching logic, or want to visualize your agent’s workflow. You can share the visualization and discuss it with your ML colleagues:

Each node is type-safe, ensuring that the outputs from one node match the expected inputs of the next. You can find the full example here.

Planning strategies use goal-oriented action planning (GOAP) or LLM-based planning. Instead of defining the exact execution order, you define:

Available actions with their preconditions (when they can run)
Effects (what they change in the agent’s state)
A goal condition (what the agent should achieve)

The planner automatically figures out the optimal order for executing actions to reach the goal. This is powerful for complex scenarios where multiple paths might work, or when requirements change dynamically. See a detailed example here.

Persistence for fault tolerance

AI agents often handle complex, multi-step tasks that can take seconds or even minutes. During this time, servers can crash, network connections can fail, or deployments can happen. Without persistence, your agent would have to start all over again, wasting time and money on repeated LLM calls.

Koog’s persistence feature saves agent state to disk, S3, or a database after each step. If something fails, the graph-based agent can resume from exactly where it stopped, not from the beginning. It will restore at the last individual node and preserve all progress made before the failure:

// First, configure where to store checkpoints
// Can be Postgres, S3, local disk, or your own implementation
var storage = new PostgresJdbcPersistenceStorageProvider(
    dataSource = dataSource,
    tableName = “banking_agent_checkpoints”
)

// Install the Persistence feature on your agent
var recoverableAgent = AIAgent.builder()
    // ... other agent configuration
    .install(Persistence.Feature, config -> {
        config.setStorage(storage);
        config.setEnableAutomaticPersistence(true);  // Auto-save after each step
    })
    .build();

// First run - starts fresh
recoverableAgent.run("Help me with my account", "user-session-0123");

// If a crash happens mid-execution...

// Second run with same session ID - automatically recovers and continues
recoverableAgent.run("Help me with my account", "user-session-0123");

The session ID ties checkpoint data to a specific user session (like a user ID or request ID). This lets you run multiple agent instances simultaneously without conflicts.

Observability with OpenTelemetry

When running agents in production, you need visibility into what they’re doing. Which tools did they call? How many tokens did each LLM request use? Where are the bottlenecks? Where did costs come from?

Koog integrates with OpenTelemetry to provide this visibility. Connect to backends like Langfuse or W&B Weave to see detailed traces of agent execution, including nested events (nodes, tool calls, and LLM requests), token counts, costs, and timing information:

var observableAgent = AIAgent.builder()
    // ... other agent configuration
    .install(OpenTelemetry.Feature, config -> {
        // Export telemetry data to your observability backend
        config.addSpanExporter(OtlpGrpcSpanExporter.builder()
            .setEndpoint("http://localhost:4317")  // Your OpenTelemetry collector
            .build());
    })
    .build();

Once configured, every agent run automatically generates detailed traces that you can explore in your observability tool.

History compression

As agents work on complex tasks, their conversation history grows with every LLM call and tool invocation. This history is sent with each subsequent request to provide context. But longer context means:

Slower LLM responses
Higher costs (you pay per token)
Eventually hitting context window limits

Koog’s history compression solves this by intelligently summarizing or extracting key information from the history, reducing token usage while preserving what’s important:

var agentWithCompression = AIAgent.builder()
    .functionalStrategy("compressed", (ctx, userInput) -> {
        var response = ctx.requestLLM(userInput);
        // Your agent logic...

        // When history gets long, compress it
        ctx.compressHistory();
    })
    .build();

You can customize how compression works:

HistoryCompressionStrategy.WholeHistory – compress entire history into a summary.
HistoryCompressionStrategy.FromLastNMessages(100) – only compress the last N messages.
HistoryCompressionStrategy.Chunked(20) – compress in chunks of N messages.
RetrieveFactsFromHistory – extract specific facts from history (e.g. “What’s the user’s name?” or “Which operations were performed?”).

You can also implement your own history compression strategy.

Managing Java threads

In a typical Java application, you want fine-grained control over thread pools. Maybe you have a dedicated pool for CPU-bound work and another for I/O operations. Koog lets you specify a separate ExecutorService for each part of an agent’s execution:

var threadControlledAgent = AIAgent.builder()
    .promptExecutor(promptExecutor)
    .agentConfig(AIAgentConfig.builder(OpenAIModels.Chat.GPT5_2)
        .strategyExecutorService(mainExecutorService)      // For agent logic
        .llmRequestExecutorService(ioExecutorService)      // For LLM API calls
        .build())
    .build();

This separation lets you optimize resource usage – for example, using a larger pool for I/O-bound LLM requests while keeping a smaller pool for strategy execution logic.

Try Koog for Java

Koog for Java brings enterprise-grade agent engineering to your Java applications with an API that feels natural and idiomatic. Whether you’re building simple tool-calling agents or complex multi-step workflows with persistence and observability, Koog provides the abstractions you need.

Get started here: https://docs.koog.ai/

Sunsetting Code With Me

Ekaterina Ryabukha — Mon, 16 Mar 2026 08:51:40 +0000

Code With Me has been part of JetBrains IDEs for years, providing real-time collaborative coding and pair programming directly inside your development environment. It enabled teams to share a workspace, tackle issues together, and learn from one another without leaving the IDE.

Today, we’re announcing plans to gradually sunset Code With Me.

In this post, we’ll explain why we’re making this change, what the sunset timeline looks like, and what it means for existing users. We’ll also outline how the transition will work and answer common questions in the FAQ below to help make the process as smooth as possible.

Why we’re making this change

Demand for built-in pair programming and real-time collaboration tools like Code With Me peaked during the pandemic and has since shifted, with many teams adopting different collaboration workflows. At the same time, maintaining Code With Me alongside the evolving IntelliJ Platform requires ongoing engineering investment.

After reviewing usage trends and the long-term direction of our IDEs, we’ve decided to discontinue Code With Me. This will allow us to focus our efforts on areas that deliver the most value to developers and align with how teams collaborate today.

Timeline and what to expect

2026.1 release

Code With Me will be unbundled from all JetBrains IDEs and made available as a separate plugin via JetBrains Marketplace.
2026.1 will be the last IDE release to officially support Code With Me.
No new features will be developed from this point forward.

Transition period (2026.1 → Q1 2027)

The plugin will continue to function on supported IDE versions.
Security updates will be provided during this period.
Public relay infrastructure will remain operational.

Final shutdown (Q1 2027)

The public relay infrastructure will be turned off.
The service will be fully deactivated.

What this means for existing Code With Me users

We understand that Code With Me is part of some teams’ workflows, and we want to make this transition as smooth as possible.

If you currently use Code With Me:

You can continue installing and using the plugin from JetBrains Marketplace throughout the transition period outlined above.
It will work on supported IDE versions, with security updates provided until the final sunset date in Q1 2027.
Existing subscriptions will remain active until support ends. New sales and renewals will be discontinued.
Our Support team will remain available during the transition to assist with any questions or compatibility concerns.

Depending on your workflow, you may find that general-purpose collaboration tools cover your needs. If your primary use case is remote access to development environments, our remote development features, which have been improved significantly in recent releases, may be a better fit.

For more details, see the FAQ below. If you have questions or feedback, please leave a comment or contact our Support team.

Looking ahead

As we invest in the future of our tools, we remain focused on delivering tools that support modern software development and bring the greatest value to developers and teams.

We’re grateful to everyone who used Code With Me, shared feedback, and contributed to its journey. Your input has helped shape the product. Thank you!

The JetBrains team

FAQ

Below, we have compiled answers to the most common questions about the discontinuation of Code With Me and the migration options available.

What is the last IDE release to support Code With Me?

2026.1 will be the last IDE release to officially support Code With Me.

Will I still be able to use Code With Me after the 2026.1 release?

Yes, you will be able to use Code With Me on all supported IDE versions for at least one year until Q1 2027. After that, our public relays will be shut down, and public sessions won’t be available anymore.

What alternatives are available for Code With Me users?

Does this decision affect remote development within JetBrains IDEs?

No. The discontinuation of Code With Me does not affect JetBrains IDEs’ remote development functionality.

We continue to actively invest in and evolve our remote development capabilities as part of the IntelliJ Platform. Remote development remains a strategic focus area, and progress in this direction will continue.

What will happen to my Code With Me license?

You can continue using Code With Me on supported IDE versions until the end of your current subscription term. Code With Me subscriptions will not renew.

For more details about your specific subscription, please contact our Support team.

I’m using Code With Me Enterprise. What does this mean for me?

If you are using Code With Me as part of a JetBrains IDE Services (Enterprise) agreement, your current contract terms remain valid during the supported period.

As we approach the end of the sunset period, renewal of Code With Me Enterprise will no longer be available. For contracts with specific provisions or custom arrangements, we will work individually to define the appropriate transition path.

If you have questions about how this change affects your agreement, please contact your JetBrains representative.

What should I do if I recently purchased an Code With Me license?

Our standard refund policy applies to recent purchases. If you have questions about your eligibility for a refund, please contact JetBrains support.

Where can I find more information or assistance?

For any further questions or support inquiries, please visit our Support page or reach out to us directly. We sincerely appreciate the Code With Me community’s support and look forward to continuing to provide the best solutions within our JetBrains IDEs.

IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog

Using Spring Data JDBC With Kotlin

Kotlin’s strengths for JDBC-based persistence

Defining an aggregate root with Kotlin

Creating repositories and defining queries

Persisting and loading aggregates

Using Kotlin value objects in your aggregate

Modeling one-to-many relationships

Transactions and practical considerations

Conclusion

About the author

Thorben Janssen

Java Annotated Monthly – April 2026

Featured Content

Marit van Dijk

Java News

Java Tutorials and Tips

Kotlin Corner

AI

Languages, Frameworks, Libraries, and Technologies

Conferences and Events

Culture and Community

And Finally…

Using Spring Data JPA with Kotlin

Required dependencies

Adding Kotlin to an existing project

Database and logging configuration

Modelling entities

Designing and using a repository

Adding your own queries

Provide your own repository method implementations

Summary

About the author

Thorben Janssen

AI-Assisted Java Application Development with Agent Skills

What are Agent Skills?

How do Agent Skills manage context?

What can be a skill?

Case Study: Implementing Spring Data JPA Pagination

Spring Data JPA Agent Skill

How to use Agent Skills?

Using Agent Skills with Junie

Summary

IntelliJ IDEA 2026.1 Is Out!

What’s fixed in IntelliJ IDEA 2026.1

Performance

Terminal

JVM language support

Better Kotlin bean registration support

New Kotlin coroutine inspections

Scala

Spring

Spring Boot 4 API versioning support

Flyway DB Migrations

User interface

Version control

Databases

JetBrains daemon

Sunsetting of Code With Me

Enhanced AI management and analytics for organizations

Core JavaScript and TypeScript Features Become Free in IntelliJ IDEA

JavaScript, TypeScript, HTML, CSS, and React Support

Code Intelligence and Code Quality

Integrated workflows

IntelliJ IDEA’s New Kotlin Coroutine Inspections, Explained

Marcin Moskała

awaitAll()and joinAll()

currentCoroutineContext() over coroutineContext

runBlocking inside a suspending function

Unused Deferred

Job used as an argument in a coroutine starter

suspendCancellableCoroutine instead of suspendCoroutine

Suspicious implicit CoroutineScope receiver

Simpler operations for flow processing

Summary

IntelliJ IDEA 2025.3.4 is Out!

Java 26 in IntelliJ IDEA

Using Java 26 in IntelliJ IDEA (setup)

New stable features in Java 26

Preview features in Java 26

`awaitAll()`and `joinAll()`

`currentCoroutineContext()` over `coroutineContext`

`runBlocking` inside a suspending function

Unused `Deferred`

`Job` used as an argument in a coroutine starter

`suspendCancellableCoroutine` instead of `suspendCoroutine`

Suspicious implicit `CoroutineScope` receiver