We’re collaborating with LinkedIn to make it easier for you to showcase your expertise with JetBrains IDEs on the world’s largest professional network. You can now connect your IDE to LinkedIn and let your real tool usage speak for itself.

Connect your IDE

IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, Rider, GoLand, CLion, RustRover, and RubyMine are already supported via a free plugin, while support for DataGrip is coming soon.

In this blog post, we’ll explain what LinkedIn connected apps are, what they mean for your profile, and how to get started.

What this is about

Building on early collaboration with Descript, Duolingo, Lovable, Relay.app, and Replit, LinkedIn is expanding the range of apps you can feature on your LinkedIn profile, turning real-world product usage into a credible, visible signal of practical tool experience. We’re glad to join forces with them to bring this to JetBrains IDE users.

“We’re building new ways for members to show real, credible proof of what they’re capable of, right on their LinkedIn profile. And for the brands behind these tools, there’s no better endorsement than a customer who’s actively using and loving your product.”
– Dan Shapero, CEO of LinkedIn

Connected apps let you link the tools you use in your daily work directly to your LinkedIn profile, where they appear prominently, helping you stand out to your professional network. Once connected, each app generates a simple statement based on how you actually use it. Unlike manually added skills, this is based on real usage and updates automatically as your experience evolves.

How to get started

Open your JetBrains IDE, go to Settings | Plugins, search for the LinkedIn Connected Apps plugin under the Marketplace tab, and install it. 

Once installed, the plugin starts collecting data locally about how you use your IDE. Depending on your usage history, you may receive an initial statement right away, which will then be updated once the plugin has collected enough data to better reflect your real IDE expertise.

Your IDE usage data stays on your machine. When you are ready, you can connect your LinkedIn account and share your IDE expertise badge there. If you keep the plugin installed, your badge will update automatically as your IDE usage evolves.

The plugin is free for all JetBrains IDE users.

What’s included in this release

This is the first version of the integration, delivered as a standalone plugin rather than being built directly into the IDE. It covers IntelliJ IDEA, PyCharm, WebStorm, GoLand, PhpStorm, Rider, CLion, RustRover, and RubyMine; DataGrip is not yet supported. 

Usage is detected within the IDE itself, so if you use AI features via an external tool or terminal, those won’t be reflected yet.

How your IDE expertise is determined

The model is intentionally simple for now. It is designed to represent your practical use of JetBrains tools, not to rank developers or certify skill levels. Our goal was to provide a solid starting point, but we know there’s more to capture about how developers work with their IDEs.

Statements map to different levels of experience and are generated based on how you interact with your IDE – from writing and editing code using basic features to working with debugging tools, version control, and AI-assisted workflows. For more information, see our documentation.

What’s coming next

We’re already working on the next version, planned for later this year. We’ll focus on improving how IDE usage, including AI feature usage, is represented, expanding support to DataGrip, and making the overall experience feel more integrated.

FAQ

Which JetBrains IDEs are supported?

IntelliJ IDEA, PyCharm, WebStorm, GoLand, PhpStorm, Rider, CLion, RustRover, and RubyMine. Support for DataGrip is coming soon.

Why isn’t DataGrip supported yet?

DataGrip is designed for working with databases and includes workflows that differ from our other IDEs. We plan to support it soon.

Can I connect multiple IDEs?

Yes, if you use multiple supported JetBrains IDEs, you can connect each of them. You’ll get a badge for all connected IDEs.

Note: If you use multiple JetBrains accounts across different IDE instances but link them all to the same LinkedIn profile, IDE usage statements from each account will be displayed on that LinkedIn profile.

Do I need to keep the plugin installed after connecting? 

You can share your IDE usage statement once and then remove the plugin, but note that it must remain installed if you want to track your ongoing progress and have any changes reflected on LinkedIn.

Is this feature free?

Yes, it’s available to all JetBrains IDE users at no cost.

Is this a certification?

Connected apps reflect real IDE usage and are designed to showcase applied experience, not to act as a formal certification or skill ranking. Certifications, degrees, and licenses remain important markers of professional achievement. Connected apps on LinkedIn add a different kind of signal: partner-validated tool usage that reflects practical work and can update over time.

What data is shared with LinkedIn and JetBrains?

Only the information required to represent your connected account and IDE usage statement. 

Will this help me get hired?

Having connected apps on your LinkedIn profile is extra proof of your practical experience with leading tools. While connected apps make your expertise visible, they are just one part of your profile. Think of it as a way to let your tooling speak for itself.

Give it a try and let us know what you think in the comments below. We’re continuing to develop this integration, and your feedback will help shape what comes next.

The world of software development keeps moving at full speed, and this month’s selection helps you keep up without drowning in tabs. Inside, you’ll find hand-picked articles, podcasts, videos, and thought-provoking reads covering Java, Kotlin, AI, and the technologies shaping the next generation of development.

Grab a coffee, pick a topic that catches your eye, and get ready to discover what’s new in the world of software development.

Let’s go!

Java News

The latest from the Java world is here. Let’s see what’s new, what’s changing, and what’s next: 

• Java News Roundup 1, 2, 3, 4 
• JEP targeted to JDK 27: 532: Primitive Types in Patterns, instanceof, and switch (5th Preview)
• JEP targeted to JDK 27: 533: Structured Concurrency (7th Preview)
• JEP 533 Tightens Exception Handling in Java’s Structured Concurrency for JDK 27
• Quality Outreach Heads-up – JDK 27: Removal of Deprecated Java Launcher Options
• Java 26: Better Language, Better APIs, Better Runtime
• Quality Outreach Heads-Up – JDK 27: Numeric Fields in JSON Thread Dumps
• Skills, Java 17, and Theme Accents With Codename One

Java Tutorials and Tips

From quick tips to deep dives, here are some Java tutorials worth adding to your reading list:

• Genie Tarpit
• The JDK Client Desktop: 2026 and Still Swinging
• Java is Not the Dark Side: Why Learning Java Is Easier Than You Think
• Comparing Top Gen AI Frameworks for Java in 2026
• Foojay Podcast #95: Is Your Java App Actually Secure, Or Does It Just Look That Way?
• Native Interoperability With JDK 25 and the FFM API
• Episode 59 “Java Is Memory Efficient” [AtA]
• The Legendary Marit van Dijk
• “Fat-Free” Lambdas in Java

Kotlin Corner

From ecosystem updates to productivity-boosting tricks, here’s what’s happening in the world of Kotlin:

• KotlinConf’26 Keynote Highlights 
• Koog 1.0 Is Out! 
• Official Kotlin Support for Visual Studio 
• The Road to Name-Based Destructuring 

AI 

Here’s what caught our eye in the world of AI this month:

• Compressed Cognition: The Cost of Faster Coding
• The Next Generation of AI Products
• Teaching an AI Agent to Debug Flaky Tests
• Agentic AI Workflows for OpenJDK Development
• Why Enterprise Java Teams Need Quality Gates Even More in the Age of AI
• Using AI to Write Better Code More Slowly

Languages, Frameworks, Libraries, and Technologies

The tech world is bigger than just Java and Kotlin. Explore the latest updates and happenings across technologies: 

• This Week in Spring 1, 2, 3, 4
• How a Group of Developers Took Back Control from Enterprise Java | Spring: The Documentary
• Micronaut Framework 5.0.0 Released!
• Kubernetes Made Easy. Deploy. Monitor. Debug. All From IntelliJ IDEA
• Three Pillars of Platform Engineering: A Virtuous Cycle
• The Code Was Always the Door
• When Should You Use a Cache With MongoDB?
• Building an AI-Powered Operations Assistant With Spring AI and MongoDB Atlas – Part 1: RAG Foundation
• Five (and a Half) Cool Things You Can Do With Quarkus
• A Bootiful Podcast: The Legendary Adib Saikali
• Benchmarking AI Agents on Kubernetes
• Product Thinking for Cloud Native Engineers
• A Bootiful Podcast: Hadi Hariri, JetBrains Legend
• A Bootiful Podcast: Microsoft’s Martijn Verburg

Conferences and Events

Mark your calendar: 

• JPrime – Sofia, Bulgaria, June 3–4
• JSpring – Utrecht, Netherlands, June 4
• JSail Unconference – Hemelum, Netherlands, June 8–12
• DevBcn – Barcelona, Spain, June 16–17
• Devoxx Poland – Kraków, Poland, June 17–19
• Voxxed Days Luxembourg – Mondorf-les-Bains, Luxembourg, June 18–19

Culture and Community

Code is only part of the story. Explore the ideas, conversations, and people shaping the developer community:

• The AI Joy Gap: Why Some Developers Thrive While Others Struggle
• Leadership in AI-Assisted Engineering
• AI Native Engineering

And Finally…

Check out the latest blog posts from IntelliJ IDEA: 

• Improving Accessibility in JetBrains IDEs: What’s New and What’s Next in 2026
• Hibernate 7.4 New Features
• Teaching an AI Agent to Debug Flaky Tests

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

The latest update brings the following improvements:

• In tmux, the terminal cursor is no longer rendered above the current line. [IJPL-102697]
• The Markdown preview now correctly displays images when referencing files outside the project directory. [IJPL-171896]
• Custom colors are rendered correctly in various UI components in the Database tool window. [DBE-25711]
• Launching WSL via wsl.exe -d <distribution> no longer causes shell integration and process detection issues. [IJPL-236576]

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!

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.

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

Happy developing!

The article will focus on the following features:

• Limits and Fetch Joins: How Hibernate 7.4 improves working with paginated queries that include fetched associations.
• History and Audit Tables: How the new capabilities support querying entity state across time and working with historical data.

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

Limits and Fetch Joins

One common requirement in data-driven applications is loading a page of parent entities along with an associated child entity collection. For example, suppose an application has an Order entity with a Set<OrderItem> collection, and we want to load the first few orders together with their order items.

List<Order> orders = session
        .createSelectionQuery(
            "select o from Order o join fetch o.items order by o.id",
            Order.class
        )
        .setMaxResults(10)
        .getResultList();

In Hibernate versions before 7.4, applying a limit to a query that used a collection fetch join could not be safely pushed down to the database. Because each Order may have multiple OrderItem rows, limiting the SQL result directly could cut off part of an order’s item collection. To avoid returning incomplete collections, Hibernate loaded all matching rows from the database and applied pagination in memory at the application layer.

That behavior was correct, but it could be expensive. A query intended to load only 10 orders might still read many more rows if the table contained a large number of orders and order items.

Before Hibernate 7.4, the generated SQL would look like the following:

select
    o1_0.id, i1_0.order_id, i1_0.id, i1_0.product_code,
    i1_0.quantity, o1_0.order_number, o1_0.status
from
    orders o1_0
        join
    order_items i1_0
    on o1_0.id=i1_0.order_id

As you can see, the limit(pagination) is not applied at the SQL query level. So, it will load all the orders and their associated order_items, which could be a very expensive operation and may result in OutOfMemoryException.

You can see a WARNING logged by Hibernate as follows:

[WARN] HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory

One option to prevent Hibernate performing pagination in memory is by setting the following property:

hibernate.query.fail_on_pagination_over_collection_fetch=true

By configuring this property, Hibernate throws an exception instead of performing pagination in memory.

Hibernate 7.4 fixes this problem by using nested queries. Instead of applying the limit directly to the joined result set, Hibernate first determines the limited set of parent entity identifiers and then fetches the associated collection for only those parent rows. 

This allows pagination to happen in the database while still returning complete items collections for each selected Order.

With Hibernate 7.4, the SQL will be generated as follows:

select
        o1_0.id, i1_0.order_id, i1_0.id, i1_0.product_code,
        i1_0.quantity, o1_0.order_number,o1_0.status 
    from
        (select
            o1_0.id, o1_0.order_number, o1_0.status 
        from
            orders o1_0 
        where
            exists(select
                1 from order_items i1_0 
            where
                o1_0.id=i1_0.order_id) 
        offset
            ? rows 
        fetch
            first ? rows only) o1_0(id, order_number, status) 
    join
        order_items i1_0 
            on o1_0.id=i1_0.order_id

This improvement makes fetch joins more practical for paginated screens, such as an order listing page that displays each order with its line items, without forcing the application to load the full result set first.

History and Audit Tables

Hibernate 7.4 adds built-in support for temporal history tables and audit tables. Both features help track changes to entity data, but they serve slightly different use cases: history tables let us query the state of an entity at a point in time, while audit tables record the sequence of changes that happened to an entity.

Consider the following Product entity:

@Entity
@Table(name = "products")
class Product {
    //fields id, code, name, price
}

History Tables

To enable temporal history for Product, annotate the entity with @Temporal and optionally specify the history table name using @Temporal.HistoryTable.

@Entity
@Table(name = "products")
@Temporal
@Temporal.HistoryTable(name="products_history")
class Product {
    //fields id, code, name, price
}

With this mapping, Hibernate stores previous versions of product rows in the products_history table. The table includes the entity columns plus two temporal columns: effective, which marks when a version became active, and superseded, which marks when that version was replaced.

products_history table:

We can get the Product entity data at a given point of time as follows:

Instant someTime = ...
try (var session = sessionFactory.withOptions().asOf(someTime).open()) {
    var product = session.find(Product.class, productId);
    
}

This makes temporal queries feel like normal entity lookups while Hibernate resolves the correct historical row behind the scenes.

Hibernate offers several different strategies(NATIVE, SINGLE_TABLE, HISTORY_TABLE) for mapping temporal entities. For more info check out the Temporal data section.

Audit Tables

Previously, Hibernate-based applications typically used the separate Hibernate Envers library for auditing entity changes. Hibernate 7.4 brings audit table support into Hibernate ORM itself, so applications can use auditing features natively without adding Envers for this use case.

Audit support is enabled by adding @Audited and can be mapped to a custom table using @Audited.Table.

@Entity
@Table(name = "products")
@Audited
@Audited.Table(name="products_aud_log")
class Product {
    //fields id, code, name, price
}

When auditing is enabled, Hibernate writes one row per change into the audit table. Unlike the history table, the audit table focuses on recording what operation happened and when.

The rev values are the timestamps at which the change happened. The revtype values are represented using ModificationType enum as follows:

public enum ModificationType {
    /**
    * Creation, encoded as 0
    */
    ADD,
    /**
    * Modification, encoded as 1
    */
    MOD,
    /**
    * Deletion, encoded as 2
    */
    DEL
}

For more info check out the Audit logs section.

Summary

Most of the applications use pagination to show a list of resources, and we used to write custom logic to load paginated data along with the associated child collection. Now this is being handled at the framework level itself. Also, we used to rely on external libraries like Envers to implement auditing, which is now provided by Hibernate itself.

Hibernate 7.4 brings practical improvements that address real problems in JPA/ Hibernate-based applications. Whether we are optimizing pagination query behavior or tracking historical data, Hibernate 7.4 reduces the amount of custom infrastructure needed and provides better support out of the box without requiring additional libraries.

Go ahead and explore these new features using this GitHub repository.

In this post, we’d like to share the general direction we’re taking for this release cycle.

Most importantly, we are working to maintain the balance between AI-assisted coding and classic development workflows (where manual coding is still the main activity).

For AI users, we are introducing the skill repository for your agents right in the IDE and actively working to improve next edit suggestions, add AI-powered full method generation, and expose more IDE knowledge via MCP.

With full method generation, when you call a method that doesn’t exist yet, the IDE’s AI will give you the option to generate both the signature stub and the full implementation body, using the same Tab-to-accept flow you are already familiar with.

MCP will make more debugging capabilities visible to agents. This will allow agents to set breakpoints, including newly introduced logpoints.

Now that agents have moved into the CLI, we are working to ensure that IntelliJ IDEA’s built-in terminal offers ideal support for them. It will support drag-and-drop file paths and image pasting when you’re talking to a CLI coding agent, plus the project’s JDK is available without manual PATH setup.

For those who prefer classic development workflows, we’re bringing revamped dependency completion to build scripts. In the dependency section, the IDE will provide completion only where relevant – artifact coordinates, scopes, and relevant version – based on the local cache and server-side knowledge.

You’ll also be able to run Flyway and Liquibase migrations from the same context menu and data source view you use for everything else, with dedicated run configurations for each tool. This keeps migrations in the same workflow – whether you’re spinning up a new module or fixing a broken state on staging.

But no matter your preferred way of coding (even if you combine methods), you are still in control of what ships, so understanding, reviewing, and debugging the code is just as important as ever.

We’re continually improving Spring Debugger to provide even more runtime information. The editor will show security indicators next to your endpoints and tell you which roles unlock them, so you can see at a glance whether a controller method is protected and how.

We’re also working to bring a new Hibernate Debugger that shows the SQL or HQL that Hibernate is about to issue, lets you jump from a query straight to the line of Kotlin or Java code that triggered it, and allows you to run the query in the application’s own configuration. If you’ve ever asked, “Where is that query coming from?”, this feature is for you.

Logpoints are the “println debugger” you’ve always wished you had. Investigating a bug used to mean sprinkling System.out.println calls and rebuilding. In 2026.2, AI can place logpoints with the expressions you actually care about during a debugging session – no suspending, no recompile, and no leftover prints to clean up.

A cornerstone of IntelliJ IDEA is that we stay on the cutting edge in supporting underlying tech. Early support for Java 27, Kotlin 2.4.x updates, and Gradle 10 is coming.

Following the Kotlin and JPA improvements in 2026.1, in this release cycle, we’re continuing to sharpen Kotlin in Spring projects: clearer Kotlin-aware diagnostics, smoother data class interop, and fewer surprises when migrating an existing Java/Spring codebase to Kotlin.

And it should go without saying that we’re always working to boost product performance and overall quality, fix freezes and bugs, and reduce resource consumption.

Not every EAP build will have a dedicated blog post, but once the features we’re working on land in public builds, we’ll cover them in dedicated posts. Stay tuned!

Share your feedback

Take part in the Early Access Program by trying out the EAP builds and sharing your feedback with us. You can get in touch with us on X, Bluesky, or LinkedIn, or leave a comment below. If you come across a bug or something that doesn’t work as expected, please report it via our issue tracker.

Happy developing!

You can use the audio player below to listen to this blog post.

Better compatibility with assistive technologies

One of the key areas we’ve been working on is improving how JetBrains IDEs interact with OS-level accessibility tools.

Improved Magnifier support on Windows

Screen magnifiers are among the most commonly used assistive technologies in JetBrains IDEs. Until recently, the built-in Windows Magnifier didn’t reliably follow the text cursor in the editor, making navigation and editing more difficult for low-vision users. We’ve implemented support for cursor tracking so Magnifier follows text as you type, just as it does in other applications.

This builds on earlier work on macOS, where we addressed text cursor tracking with macOS Zoom. Now, the same support is being extended to Windows.

Orca and GNOME Magnifier support on Linux

With version 2026.2, coming this summer, JetBrains IDEs will allow you to use the Orca screen reader and GNOME Magnifier in supported Linux environments. 

This is an active area of work, with multiple related tasks already underway. Accessibility shouldn’t depend on your operating system, and we’re continuing to improve support across platforms.

More predictable keyboard navigation

We’ve also been making it easier to move through the IDE without relying on a mouse.

Main menu access with Alt on Windows

In native Windows applications, pressing Alt moves the focus to the main menu, allowing you to navigate it with the keyboard. This behavior was previously missing from JetBrains IDEs, and screen readers, such as NVDA, would sometimes announce the system menu instead.

Now, the main menu behaves in a way that feels familiar and predictable for keyboard-only and screen-reader users, and the bright focus indicator helps low-vision users identify the selected item.  

Navigating between major parts of the IDE

Another focus area is the experience of moving between different parts of the IDE interface, such as toolbars, panels, and the editor. We’re working on a more structured model for navigating through the big component groups:

• Tab and Shift+Tab move the focus within the current area.
• A dedicated shortcut lets you jump between larger sections of the IDE.

This reduces the effort required to reach essential controls and makes the overall layout easier to navigate. For the current iteration, we made it possible to bring the main toolbar and status bar into focus, and we fixed the Project and Git toolbar widgets, which were not selectable by screen readers, even though other elements already were. 

As the next step, we’ll polish specific controls and include tool window bars on both sides of the IDE frame in the navigation flow.

Exploring richer non-visual feedback with audio cues

Accessibility is not only about reaching controls, but also about understanding what’s happening while you work. We’re exploring ways to provide richer audio feedback in the IDE. Two directions we’re currently investigating:

• Contextual signals when the caret lands on lines with errors, warnings, breakpoints, or version control changes. We want the IDE to provide immediate, non-visual feedback in context.
• More general audio notifications for IDE actions and state changes.

The goal is to reduce the need to rely on visual indicators or switch contexts just to understand what changed. Instead, we want the IDE to provide that information more directly.

Accessibility as an ongoing effort

We’re improving accessibility in JetBrains IDEs across multiple areas at once, including by providing compatibility with assistive technologies like screen readers and magnifiers, as well as by offering more consistent keyboard navigation and clearer feedback for events that are otherwise mostly visual.

These improvements build on earlier updates, such as support for VoiceOver and NVDA, a high-contrast UI theme, and color schemes for red-green vision deficiency. There’s still more to do, and we’ll continue working in this direction.

We’d love to hear from you

We’re eager to hear from developers who rely on accessibility features, as well as from anyone interested in improving the experience of using them.

If you have ideas or feedback about accessibility in JetBrains IDEs, you can reach us directly at accessibility@jetbrains.com. You can also report issues through YouTrack or the support request form.

If you’d like to stay informed about accessibility improvements, you can subscribe to updates here.

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

Here are the most notable updates included in this version:

• Projects can now be opened correctly via .ipr files generated by the Gradle idea task. [IJPL-242321]

• The indentation for Java ternary expressions with chained method calls has been fixed. [IDEA-387867] 

• Pressing the Alt+Enter key combination on Windows no longer opens the context menu unexpectedly. [IJPL-47743] 

• Live templates with groovyScript now work as expected again. [IJPL-241581] 

• Dragging and dropping selected code with the mouse onto its original position no longer causes the code to disappear. [IJPL-235895] 

• It is once again possible to open a diff in an external tool by double-clicking a file in the Commit tool window. [IJPL-241256] 

• The MCP Server no longer reports illegal character errors for projects with spaces in their paths [IJPL-241803] 

• Workspaces once again function as expected. [IDEA-388445] 

• Several IDE freezes have been resolved. [IJPL-235455] [IJPL-224542] [IJPL-203153]

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

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

Happy developing!

• Searches for declared Spring beans are no longer triggered during typing or completion, ensuring code completion works smoothly in Spring-based projects. [IDEA-378966]

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.

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!

This month, Emily Bache joins us to share some sharp finds about AI agents and test-driven development. Java stays busy with fresh updates and practical tips, and Kotlin keeps pushing forward right next to it. The AI section is, as usual, packed with things worth your attention.

You’ll also find upcoming events to plan for and a few ideas to challenge your thinking.

Featured Content 

Emily Bache

Emily Bache is an independent consultant, YouTuber, author, and Technical Coach, with over 25 years of experience working with Java and other programming languages and tools. She works with developers, training and coaching effective agile practices like refactoring and test-driven development. Emily has written two books about software development and contributed to several others. Emily founded the Samman Technical Coaching Society in order to promote technical excellence and support coaches everywhere.

It’s my pleasure to bring to your attention some interesting content that appeared in April. The huge change that is sweeping through our industry right now is the adoption of AI coding agents, which many people are using instead of hand-coding changes to software. One of the most important new skills to master is designing a “harness” for your AI tool, and this month Birgitta Böckeler has published the best reference I’ve seen so far about what that is and a mental model for how to think about it. Chris Parsons has also published an extensive guide titled How I use AI to Code, which is a really great resource for experienced developers looking to create their own harness and mentor others to do the same.

Perhaps as a contrast, I’d also like to highlight Michael Taggart’s introspective experience report on his use of AI. He wrestles with his conscience over using these tools at all. An interesting metaphor for AI-assisted coding came up in an article by Drew Breunig – we run the risk of building a Winchester Mystery House. After you read that, listen to Kevlin Henney’s talk Being the Human in the Loop, where he takes a look at the engineering skills we still need – ones that could perhaps prevent the kind of thing Drew writes about from happening. 

I have a particular interest in test-driven development, which, as a technical coach, is a big part of what I teach to others. I wrote an initial assessment of what TDD looks like these days, based on interviews with several practitioners I trust who are all using agentic AI. For those of you who’d like to see me in action writing code,  I have a demo of a narrow integration test for an outbound port in a hexagonal architecture, in Kotlin.

Java News

Catch what shipped and track what’s next:

• Java News Roundup 1, 2, 3, 4
• Newsletter: Java 26 Is Now Available | JDK 27 Heads-Ups
• Quality Outreach Heads-up – JDK 27: Obsolete Translation Resources Removed
• Update Your JDK, Read More Code, and Talk to Your Users: Interviews From VoxxedDays Amsterdam (#93)

Java Tutorials and Tips

Steal these tricks:

• Analysing Crashed JVMs – Inside Java Newscast #109
• Oracle’s Java Verified Portfolio and JavaFX: What It Actually Means
• 10 Things I Hate About Java by Adele Carpenter
• Is AI Ruining Java Open Source? – Andres Almiray | The Marco Show
• Java 26: Updates You Must Know
• Java and Gen AI: JVM Agents With Embabel by Rod Johnson (Spring Creator)
• A Bootiful Podcast: Java Developer Advocate Ana-Maria Mihalceanu
• Does Java Really Use Too Much Memory? Let’s Look at the Facts (JEPs)
• Thread-Safe Native Memory in Java: VarHandle Access Modes Explained
• Episode 54 “How JDK 26 Improves G1’s Throughput” [AtA]
• You Must Avoid Final Field Mutation – Inside Java Newscast #110
• How the JVM Optimizes Generic Code
• The Curious Case of Enum and Map Serialization
• Avoiding Final Field Mutation

Kotlin Corner

• Kotlin kontra Java – Part 1 – Ecosystem
• Kotlin Professional Certificate by JetBrains – Now on LinkedIn Learning
• Introducing Koog Integration for Spring AI: Smarter Orchestration for Your Agents
• Reliable AI Agents Using Domain Modeling With Koog in Java

AI 

Cut the hype, test the tools, and boost your flow: 

• How We Built a Java AI Agent by Connecting the Dots the Ecosystem Already Had
• Stateful Continuation for AI Agents: Why Transport Layers Now Matter
• A Bootiful Podcast: Mark Kropf on AI Orchestration
• Embabel Tools & MCP Servers: Supercharge Your Java AI Agents
• Adversarial AI: Understanding the Threats to Modern AI Systems
• Why Java Developers Over-Trust AI Dependency Suggestions
• A GitHub Agentic Workflow 
• ACP Java SDK: Building IDE Agents in Java 
• Spring AI Agentic Patterns (Part 7): Session API – Event-Sourced Short-Term Memory with Context Compaction
• Beyond RAG: Architecting Context-Aware AI Systems With Spring Boot 
• Spring AI Agentic Patterns (Part 6): AutoMemoryTools – Persistent Agent Memory Across Sessions 
• 5 Best Practices for Working with AI Agents, Subagents, Skills, and MCP 
• Deepfakes, Disinformation, and AI Content Are Taking Over the Internet
• MCP in the Java World: Bringing Architectural Strategy to LLM Integrations

Languages, Frameworks, Libraries, and Technologies

Explore new tools and technologies, and revisit the old ones:

• This Week in Spring 1, 2, 3, 4
• Article: Beyond RAG: Architecting Context-Aware AI Systems With Spring Boot
• Six and a Half Ridiculous Things to Do With Quarkus
• The Spring Team on Spring Framework 7 and Spring Boot 4
• A Bootiful Podcast: The Legendary Craig Walls
• Enabling Reflection-Free Jackson Serializers by Default 
• Understanding Performance 
• A Bootiful Podcast: A Bootiful Podcast: Dr. Venkat Subramaniam and James Ward on Intelligent Kotlin and So Much More
• The Road to Docker Official Images for Java: The Azul Zulu Story
• Spring Debugger New Power: Where Should I Click to Demystify Spring Boot Magic?

Conferences and Events

Join the crowd online or offline:

• JAX – Mainz, Germany or Online, May 4–8
• Devoxx UK – London, United Kingdom, May 6–7; JetBrains will have a booth at the event. Also, come and listen to our JetBrains speakers: Marit van Dijk, Cheuk Ting Ho, and Simon Vergauwen. The Spring documentary will premiere there, followed by a panel with Josh Long, Steve Poole, and Marit van Dijk.

• GeeCon – Kraków, Poland, May 14–15; Marit van Dijk is speaking and moderating a panel on Java to discuss what excites each of them most about Java in 2026. 
• JAlba – Edinburgh, Scotland, May 14–16
• JNation Conference – Coimbra, Portugal, May 26–27; Anton Arhipov and Marit van Dijk from JetBrains are the speakers. 
• JCON Slovenia – Portorož, Slovenia, May 27–29

Culture and Community

Where do you stand on these topics?

• Panel: Building a Culture That Works
• How to Do What You Love and Make Good Money 
• Do Things That Don’t Scale 
• Encoding Team Standards 
• Beyond the Hype: Is AI Taking the Fun out of Software Development? 

And Finally…

One last thing before you close the article. Don’t skip it!

• Using Spring Data JPA With Kotlin
• Using Spring Data JDBC With Kotlin
• Speeding up Interactive Rebase in JetBrains IDEs
• From Java to Wayland: A Pixel’s Journey

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

If you aren’t yet familiar with them, the idea is simple: Instead of prompting instructions for a specific task each time, you define them once and reuse them later. A Skill is an AI equivalent of a knowledge base article: a plain text document that lives in a discoverable location and describes steps, a set of conventions, or domain-specific knowledge.

Most Skills you see in the wild are for simple things like enforcing code style or commit message conventions. But they can be much more powerful than that. In this article, we’ll combine AI Skills, good old developer tools, and a bit of creative thinking to address a notoriously challenging task: making AI deterministically find the root cause of flaky tests.

The problem

Quoting the TeamCity CI/CD guide:

Flaky tests are defined as tests that return both passes and failures despite no changes to the code or the test itself.

Flakiness undermines the whole point of tests: When a test fails, you can’t tell whether something is actually broken. You can’t fully rely on the test results, and at the same time, you can’t ignore them. This wastes both human and infrastructure resources.

And as if the underlying bugs weren’t difficult enough on their own, flaky tests often have this property of failing once in several thousand runs, making them extremely hard to reproduce and debug.

Example project

For the example project, let’s take the webshop demo from this article: Your Programs Are Not Single-Threaded. It is a Spring Boot project, in which one of the services has a TOCTOU (time-of-check to time-of-use) problem: It checks a condition and then acts on it, but another thread can change the state in between. In this particular case, it may sometimes cause duplicate invoice numbers and also makes the corresponding test flaky.

Here’s the problematic test:

@SpringBootTest
class InvoiceServiceTest {

    @Autowired
    private OrderService orderService;

    @Test
    void firstTwoOrdersGetInvoiceNumbersOneAndTwo() {
        CompletableFuture<Invoice> alice = CompletableFuture.supplyAsync(
                () -> orderService.checkout("Alice", BigDecimal.TEN));
        CompletableFuture<Invoice> bob = CompletableFuture.supplyAsync(
                () -> orderService.checkout("Bob", BigDecimal.TEN));

        String num1 = alice.join().getInvoiceNumber();
        String num2 = bob.join().getInvoiceNumber();

        assertEquals(Set.of("INV-00001", "INV-00002"), Set.of(num1, num2));
    }
}

The test creates two orders concurrently and checks that the resulting invoices get numbers INV-00001 and INV-00002. Because of a bug in InvoiceService, it can either pass or fail randomly.

If we knew nothing about the underlying bug, and only had the test, is there a tool that could help us find the root cause? Or can we make one ourselves? Furthermore, could we delegate both building and using the tool to AI?

The intuition

Let’s come up with some intuition for this class of problem.

To produce two kinds of results, the execution must follow different code paths. The difference might be minimal, possibly just one extra method call or one if branch taken instead of another. But it has to be there; otherwise, the result would be consistent. So, if we could record the code path for a passing run and a failing run and then compare them, the diff should at least point us in the right direction. And ideally, by following the call tree, we could find the place where execution splits. This line must be exactly where the flakiness originates.

Does this reasoning make sense? Let’s put it to the test.

Build the tools

What tool can we use for recording code paths? While not designed specifically for tracing, a test coverage tool can give us the information we’re after.

There are a couple of Java coverage tools to choose from, such as JaCoCo and IntelliJ IDEA’s coverage tool. We’ll go with IntelliJ IDEA’s, because it includes a hit counting feature that is very useful. We may need this extra granularity because the flakiness might stem not only from what is executed, but also how many times.

Run coverage from the command line

IntelliJ IDEA’s coverage tool has a familiar UI, but we need a way to launch it programmatically. Fortunately, coverage can also be collected from the command line by attaching the coverage agent to the JVM via Maven Surefire:

mvn surefire:test \
  -Dtest=com.example.webshop.service.InvoiceServiceTest \
  "-DargLine=-Didea.coverage.calculate.hits=true \
    -javaagent:\$AGENT_JAR=\$IC_FILE,true,false,false,true,com.example.webshop.*"

The -Didea.coverage.calculate.hits=true flag tells the agent to record invocation counts per line rather than just a boolean hit/not-hit mask. After the test finishes, the results are written to a binary .ic file.

So far so good, but we need the report in a human (and AI)-readable format.

Add text output

Luckily, the IntelliJ coverage agent is open-source. Let’s clone the project and ask AI to add a text reporter that converts binary reports to plain text.

The agent creates a new class called TextCoverageStatistics. After we build the project and run the reporter against our .ic file, we get something like this:

=== Coverage Summary ===

  Instructions: 236/618  38,2%
  Branches    : 0/20   0,0%
  Lines       : 56/150  37,3%
  ...

=== Per-Class Coverage ===

Class                                                           Lines    Line%  Methods    Meth%
--------------------------------------------------------------------------------------------
...
com.example.webshop.service.InvoiceNumberGenerator              4/4    100,0%    2/2    100,0%
com.example.webshop.service.InvoiceService                     10/10   100,0%    3/3    100,0%
com.example.webshop.service.OrderService                        6/6    100,0%    2/2    100,0%
...

The first part of the report gives a high-level overview: How many lines, branches, and methods were covered across the entire project. Below that, there’s a per-class breakdown showing the same metrics for each class individually.

Then it is followed by per-line hit counts for each class:

--- com.example.webshop.service.InvoiceService ---
  Line       Hits  Branch
  19            2
  20            1
  22            2
  23            2
  24            2
  ...

For every line that the coverage agent instrumented, we see how many times it was executed and whether any branches were taken. The actual report is longer, but you get the idea. Now we have a text representation of which lines were executed, and exactly how many times.

This is the raw material we need for the diff. So far, so good!

Diff the reports

Supposedly, the obtained reports contain the necessary information, and a very determined developer could peruse them and find the bug. But we’re not here for mundane tasks like that, right?

Let’s upgrade the tool so that it gets multiple report variations and presents the diff. The most controllable way would be to do one “brick” at a time, but I think we’re safe to delegate the entire thing to AI here, including the automation:

The resulting script runs the test in a loop until both of the following happen:

• We get at least one passing and one failing run.
• The specified number of runs have passed.

Both conditions are important because test failures can be very rare, and the specified number of runs might not be enough. At the same time, there can be finer grained variations within pass and fail runs, so we might want to catch those too.

After the reports are collected, the script summarizes the lines that have variations between the runs. Here’s what it looks like:

Collected 20 runs: 12 pass, 8 fail

Lines that vary across runs:

  Invoice:29                           Hits(1,2)
  Invoice:31                           Hits(1,2)
  Invoice:32                           Hits(1,2)
  InvoiceNumberGenerator:15            Hits(1,2)
  InvoiceService:19                    Hits(1,2)  Branch(1/2)
  InvoiceService:20                    Hits(1,2)
  InvoiceService:22                    Hits(1,2)
  InvoiceService:24                    Hits(1,2)

All variations have the same pattern: the difference is not which lines were executed, but how many times. As we expected, the hit counting feature of IntelliJ IDEA’s coverage agent proved useful!

The varying lines point at a lazy initialization block in InvoiceService and its downstream effects in InvoiceNumberGenerator and Invoice. The variation in hit counts means that the initialization sometimes runs more than once, which shouldn’t happen. That’s exactly where the flakiness comes from.

If you missed the article that describes the problem, here’s why double initialization causes this bug. The createGenerator() method queries the database for the last used invoice number and creates a counter starting from that value. When two threads both enter the if (generator == null) block before either finishes, each reads the same number from the database and creates its own generator starting from the same value. The result is duplicate invoice numbers.

The coverage diff has pointed us at the very same TOCTOU race discussed in more detail in the previous article. But, what is novel in our current approach is that it doesn’t solely rely on human expertise and is easily accessible for AI.

Turning it into a Skill

Now, I’d say that AI-assisted modifications to open-source tools that help you solve the task at hand, all within minutes, are amazing on their own. But let’s keep our eyes on the bigger picture.

Here’s what we’ve done so far: We started with an intuition: Flaky tests take different code paths, and coverage analysis can reveal where they diverge. Then we turned that intuition into a concrete, repeatable procedure. Does this warrant a knowledge base article, or an AI Agent Skill, perhaps? Yes!

In the same agent session, let’s ask the agent to:

1. Make sure all the scripts are self-contained and runnable.
2. Document the entire procedure in a SKILL.md file, step by step, so that another agent can follow it without any prior context.

The agent packages everything and writes a guide that describes when to apply the Skill, what tools are needed, and what steps to follow.

Testing the Skill

To verify that the Skill actually works, let’s start a fresh agent session. No warm-up, no hints. Instead, let’s deliberately phrase it in a very general way, something like “find and fix the cause of flakiness in InvoiceServiceTest“.

The agent matches the Skill description from SKILL.md with the problem description, discovers the instructions, and executes them: It runs the coverage script, reads the diff, and identifies the race condition. Instead of guesswork, it follows the established steps and arrives at the same conclusion every time. That’s about as deterministic as generative AI can get!

Summary

The changes that we’ve made to the coverage agent are already published with the new version 1.0.774. And the Skill is available here.

In this article, we started with an intuition about flaky tests, built custom tooling around an open-source coverage agent, used it to find a race condition, and packaged the entire procedure into a reusable AI Skill. You can use this Skill for finding flaky tests in your own projects, but I hope this post conveys the bigger idea.

AI Skills allow you to teach agents to solve virtually anything, as long as you can stack text interfaces together. Many hard programming problems can be broken down into simpler ones and solved using familiar tools. And with AI orchestrating all this, we can even make the process enjoyable. As was the case long before AI, curiosity is the only real prerequisite.

Have you been inspired to solve a tough problem in your own work? Would you like to share the Skills you wrote or find most useful? Let us know in the comments!

Happy debugging!

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

Here are the most notable updates included in this version:

• It’s once again possible to set up a WSL Python SDK. [IJPL-240728]
• Emmet in remote development now works as expected. [IJPL-168255] 
• Gradle sync no longer fails due to a class cast error involving InternalIdeaModule and org.gradle.tooling.model.ProjectModel. [IDEA-386409]
• The IDE now correctly connects to the WildFly admin process after server startup, restoring deployment and the Open browser after launch option. [IDEA-387483] 
• The IDE no longer fails to locate the WSL 2 JDK. [IJPL-222935] 
• Double-clicking an Ant target in the Ant tool window now runs the target and shows the build output in the Messages tool window. [IDEA-387507] 
• Search for context actions and code completion in large Spring projects are now more responsive and faster. [IDEA-378966]  
• The IDE now correctly supports creating a run configuration for a local WebLogic server. [IDEA-387617]
• The Find and Replace action now works as expected when pressing Enter. [IJPL-240373]

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

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

Happy developing!