• Standard library: Support for coroutine stack trace recovery, new functions for checking equality and uniqueness of collection elements, and new overloads for kotlin.test assertion functions.
• Kotlin/Native: New Swift export features, improved incremental compilation, and automatically generated Package.swift files for SwiftPM dependencies.
• Kotlin/Wasm: Changes to top-level require() calls in @JsFun declarations, improved companion object initialization order, and support for Wasmtime in the Kotlin Gradle plugin.
• Kotlin/JS: A new DSL for browser testing, support for exporting suspend lambdas as async functions, and improved exportability of data classes.
• Gradle: Support for Gradle 9.7.0 and improved reporting in the Problems API.
• Build tools API: Support for new targets: Kotlin/JS, Kotlin/Wasm, and Kotlin metadata.
• Kotlin compiler: The `kotlinr` runner command and a separate native image.

For the complete list of changes, see What’s new in Kotlin 2.4.20 or the release notes on GitHub.

How to install Kotlin 2.4.20

The latest version of Kotlin is included in the latest versions of IntelliJ IDEA and Android Studio.

To update to the new Kotlin version, make sure your IDE is updated to the latest version and change the Kotlin version to 2.4.20 in your build scripts.

If you need the command-line compiler, download it from the GitHub release page.

If you run into any problems:

• Find help on Slack (get an invite).
• Report issues to our issue tracker, YouTrack.

Special thanks to our EAP Champions

• Zac Sweers
• Alexander Nozik
• Benoit Lubek
• Yang
• Rick Clephas
• Johannes Svensson
• Łukasz Wasylkowski
• Sterling Albury
• David Lopez
• Florian Schreiber
• Sechaba Mofokeng
• Bernd Prünster
• Anderson Lameck
• Dayan Ruben
• Josh Stagg
• Yuri Geronimus
• Sergey Chernov
• Ivan Canet
• Olaf Gottschalk
• Mohamed Rejeb

Further reading

• What’s new in Kotlin 2.4.20 documentation
• Kotlin 2.4 compatibility guide
• Kotlin EAP Champions

Read on for the details, and check the release notes for the full list of changes and bug fixes.

Additionally, klibs.io now uses the Kotlin Toolchain in production. A real backend and not a sample, it’s built on JDK 21, Spring Boot 4 (with Spring AI), PostgreSQL, and OpenSearch. We’ve converted nine convention plugins to Kotlin Toolchain templates, and two Gradle plugins with no built-in equivalent: Jib and Git Properties, which we’ve implemented as local Kotlin Toolchain plugins. Check out the sources yourself.

To get support for Kotlin Toolchain’s latest features, use IntelliJ IDEA 2026.2.1 (or newer). Make sure the latest version of the Kotlin Toolchain plugin is installed. 

Try the Kotlin Toolchain

Kotlin Multiplatform libraries publication

Library publishing arrived in preview in 0.11, but only for JVM libraries. Starting with 0.12, multiplatform libraries work too, with exactly the same configuration:

product:
  type: lib
  platforms: [jvm, android, iosArm64, iosSimulatorArm64, wasmJs]

settings:
  publishing:
    enabled: true
    group: org.example
    version: 1.0.0

The Kotlin Toolchain publishes everything your users need to depend on your library from any of its targets: the common API, one artifact per platform, the sources, and the module publication metadata that lets build tools pick the right pieces automatically.

Cinterop bindings are supported as well. They are published both commonized and per platform, so your users get the same C API you compiled against without setting up interop themselves. The result is consumable from Gradle projects like any other multiplatform library.

For more details, see the documentation.

Note: Resources of Compose Multiplatform libraries are not part of the publication yet. Follow KTC-5698 for progress.

Better compliance with Maven Central quotas

Because of the new quotas on Maven Central publications that Sonatype will soon enforce, we made a few notable changes to reduce the number of files published by default:

• Checksums of signature files (.asc.sha1) are not necessary and are no longer published.
• Only the .md5 and .sha1 checksums are published by default now. If you need to continue publishing the .sha256 and .sha512 checksums, use settings.publishing.checksums: [md5, sha1, sha256, sha512].

Wasm application support

wasm-js/app modules can now be built into a ready-to-use web application.

Among the supported features are:

• Running Wasm apps with the kotlin run command.
• Customizing index.html and other resources. 
• Fetching transitive npm dependencies from Kotlin Multiplatform libraries.

More information on working with Wasm web applications is available in the documentation.

Terminal UI improvements

We are actively working to make the output of the kotlin command less verbose and more user-friendly. 

Diagnostics

For example, here are some of the recent diagnostics improvements:

Tests in the status widget

Running tests are now visible in the status widget under the respective tasks and their suites. There are also short test execution statistics visible during the run.

There are more things to iron out, but we’ll get there.

IDE improvements

Compose preview support

Android modules and kmp/lib modules that have Android as one of their targets now support the Compose preview feature, powered by the androidx.compose.ui.tooling.preview.Preview annotation and the Android plugin.

Better support for Compose resources

The IDE now correctly recognizes Compose resources, updates Res classes on the fly, provides navigation, completion, and refactorings that update both XMLs and your code.

Android tooling improvements

Adding to the Compose preview support mentioned above, we have also brought support for more of the Android features you are accustomed to, such as:

• Android Lint 
• Live Edit
• Layout Inspector
• Resources (R class) navigation and completion

iOS improvements

Starting with IntelliJ IDEA 2026.2.1, the experience of working with iOS applications should be closer to what you’re used to in Gradle projects.

The run configuration now lets you pick a device, configure Xcode options, and choose a debug/release configuration mode.

We’ve also fixed a few issues with Kotlin/Swift interoperability, which should be more stable now.

Inlay hints with coordinates of catalog dependencies

Catalog dependencies in module files and templates now have an inlay hint next to them displaying coordinates that each entry points to.

Better Compose Hot Reload support

We now properly support Compose Hot Reload from the command line using the kotlin run --compose-hot-reload-mode command.

General improvements

• The very first reload is now much faster and the build should consume fewer resources.
• The Restart the application action from the DevTools menu is now supported.

Compose Hot Reload MCP

We now support an MCP server for agents to interact with applications running with Compose Hot Reload.

To get started, add the following snippet in your mcp.json:

{
    "mcpServers": {
        "Compose Hot Reload": {
            "command": "./kotlin",
            "args": [
                "compose-hot-reload-mcp-server"
            ]
        }
    }
}

With this, agents can interact with, reload, restart, and view window snapshots, and dump the tree of composables. Read more about these capabilities here.

Other improvements

New recommended local dependency format using the // prefix

Previously, the only way to define local module dependencies was to use relative paths starting with the . (dot) symbol. This approach had several problems. For example, moving a module from one directory level to another required changing all the dependency paths, such as from../../foo to ../foo. And having a multitude of ../ in deeply nested directory structures generally made paths hard to read.

The new recommended way to define local module dependencies is to use project-root-relative paths starting with the // prefix. You might be familiar with this syntax from tools like Bazel. The // prefix represents the project root directory and can be used not only in the dependencies block but in any place that expects a path as well, for example, apply.

The old relative-paths approach still works for now.

This is a step toward allowing multiple modules with the same directory name.

Raised minimum JDK and Kotlin versions

Until now, the minimum JDK version supported by the Kotlin Toolchain was not clearly documented anywhere, and the build would just fail in different places if you used a JDK that was too old. There is now a clear diagnostic and a clear minimum: only JDK 17 and higher are supported to compile your code. You can still use settings.jvm.release to set a lower target if your code should be runnable on lower JREs. 

The minimum Kotlin compiler version was raised from 2.1.10 to 2.2.20. This allows simplifying our code, and is in line with the new security support policy for the Kotlin standard library. 

Updated default versions

We’ve also updated some of the default versions for built-in toolchains and frameworks:

• Kotlin 2.4.10
• JDK 25
• JUnit Platform 6.1.3
• KSP 2.3.11
• Ktor 3.5.2
• Spring Boot 4.1.0
• DataFrame 1.0.0-rc01
• Kotlinx.rpc 0.10.3

Try Kotlin Toolchain 0.12.0

To get started with the Kotlin Toolchain, check out our Getting started guide. Take a look at some examples, follow the tutorial, or read the comprehensive user guide, depending on your learning style.

Try the Kotlin Toolchain

To update an existing project, use the kotlin update command.

Share your feedback

The Kotlin Toolchain is still in Alpha and under active development. You can provide feedback about your experience by joining the discussion in the #kotlin-toolchain Slack channel (get invite: https://kotl.in/slack) or by sharing your suggestions and ideas in a YouTrack issue. Your input and use cases help shape the future of the Kotlin Toolchain!

Here are the highlights of this release:

• MCP server for AI agents in Compose Hot Reload
• Automatic font fallback for web
• v2 version of the window and dialog API for desktop

For a complete overview of the changes, check out What’s new in Compose Multiplatform 1.12.0 or the release notes on GitHub.

Get Started with Compose Multiplatform

MCP server for AI agents in Compose Hot Reload

Compose Hot Reload now ships with an experimental Model Context Protocol (MCP) server that connects AI coding agents to your running application.

Using the MCP server, an agent can trigger reloads, take screenshots, inspect the semantic tree, simulate clicks and text input, and read application logs. In practice, this means the agent can verify the results of its own edits. It can confirm that the reload succeeded, inspect the rendered UI, catch a runtime exception, and iterate – all without you describing what’s on screen.

For the full list of available tools and instructions on connecting your agent, see the Compose Hot Reload documentation.

Try Compose Hot Reload

Automatic font fallback for web

Compose Multiplatform for web now handles characters that your application’s fonts don’t cover. When it encounters an unresolved character during rendering, it downloads the matching Noto font subset on demand and recomposes the affected text. As a result, Japanese, Arabic, Devanagari, and emoji render correctly without you having to bundle fonts for them.

Window and dialog API v2

This release introduces an experimental v2 of the API for WindowState and DialogState in the androidx.compose.ui.window.v2 package. It gives you finer control over how windows and dialogs are positioned and sized. You can:

• Select the screen a window appears on.
• Provide custom positioning and sizing logic, including logic based on the content’s intrinsic size.
• Set minimum and maximum window sizes.
• Position dialogs relative to their parent window.

The enhanced API also makes the asynchronous nature of window state changes explicit: It distinguishes the state you request from the state the window currently has.

For example, to center a window and give it a fixed size, use WindowPositionProvider and WindowSizeProvider:

val windowState = rememberWindowState(
    initialBoundsProvider = WindowBoundsProvider(
        positionProvider = WindowPositionProvider.CenteredOnScreen,
        sizeProvider = WindowSizeProvider.Fixed(DpSize(400.dp, 200.dp))
    )
)

With the API v2, you can also use WindowSizeProvider.Unconstrained to size the window to its content initially, while still letting that content expand with fillMaxSize() when the user enlarges the window:

WindowBoundsProvider(
    positionProvider = WindowPositionProvider.CenteredOnScreen,
    sizeProvider = WindowSizeProvider.Unconstrained
)

See the Window and dialog API v2 documentation for the full details.

Update your dependencies, try out the new APIs, and let us know what you think about Compose Multiplatform 1.12.0.

For everything that didn’t make it into this post, check out the full release notes or What’s new.

Sergey Chernov

Sergey Chernov is a Lead Software Engineer at Salmon, specializing in functional Kotlin and type-safe system design. At Salmon, a technology-driven financial company building banking and lending products in Southeast Asia, Sergey works on authentication and verification systems: the platform layer responsible for keeping user access secure, reliable, and consistent across products. He has 10+ years of experience designing and building scalable backend systems.

Here’s a function that signs a document:

fun signDocument(
    documentId: UUID,
    code: String,
): Unit

In Kotlin, Unit means the function completes without returning a meaningful value – roughly equivalent to void in Java.

Got it? Now, tell me what could go wrong. You can’t. 

Yet, the code might be invalid. The signing window might have closed. The database might be down. The document might already be signed, or expired, or the request might have arrived out of order from a buggy client. 

Every one of those is a real outcome this function must reckon with. Not one is visible in the line above.

To discover possible failures and how to handle them, you could open the implementation. Then, the service it calls. Then, the exception handlers, the route mapping, the tests, the OpenAPI spec, and the client code that consumes it. 

You could read everything except the one thing that should have told you in the first place: the signature.

At Salmon, I work on authentication and verification. A mishandled failure is rarely cosmetic and the difference between two error cases can be the difference between letting the right person through and the wrong one. I’ve spent a fair bit of time on this question: how do you make a function’s expected failures part of what it tells you, instead of something you have to go digging for? 

This article is my answer. It uses Kotlin, but the concept carries to any language with sealed types.

Have no fear of “functional error handling”

“Functional error handling”. That phrase scares people off. They expect monads, category theory, and a lecture. This isn’t the case. The goal is plain: the function signature should be enough to know how to call it and how to handle every expected outcome. Nothing hidden in the body. 

If a failure is part of the business logic, it belongs in the function signature, the API contract, and the client’s handling code, not buried in the implementation.

Salmon’s engineering culture runs on a few commitments: real ownership from day one, high standards held in the open, and a refusal to ship things that don’t actually work. A function that hides its failures is at odds with all three. 

So, in the case of the example above, the signature I actually want should look like this:

fun signDocument(
    documentId: UUID,
    code: String,
): Either<DocumentSignError, Unit>

We now have the inputs on the left of the function and the expected failure type and the success type on the right. 

Now, before we get to what Either is, we need to agree on what belongs inside DocumentSignError in the first place, because that’s where a lot of the value of this system comes from.

Three kinds of failure, but only one belongs in the signature

Not every bad thing that happens is the same kind of bad thing. I split failures into three groups, and each group gets handled differently.

01 · API CLIENT ERRORS

The caller used the API wrong: this means a malformed JSON, a missing header, an unsupported operation, a request that arrived out of sequence, access that isn’t allowed. 

A healthy client should almost never see these, and there is no designed screen for them, because a working app doesn’t produce them. Thus, you can collapse the whole category into coarse HTTP responses: a 400, a 403, a 404. You do not enumerate them one by one in your domain model.

02 · UNEXPECTED EXCEPTIONS

The database is unavailable. A dependency timed out. The network dropped. A null slipped through and you have a NullPointerException, or an invariant broke and you’re in an illegal state. These are not business outcomes. 

Nobody designs a user flow for “Postgres fell over.” You do not model these as domain errors. Instead, they become operational signals: a 500 to the client, a full stack trace in the logs, a spike in your error-rate metric, a page to whoever is on call.

03 · DOMAIN ERRORS

Here, the client behaved correctly, yet the operation still can’t succeed. 

The signing code was wrong. The window has closed. The document was already signed. Approval is missing. The policy rejected it. These are the failures a real user hits while doing everything right, and your designers have a specific screen for each one. 

This is the category that has to be visible. If a healthy client needs to handle two outcomes differently, those two outcomes have to be distinguishable in the type. This is the group that belongs in the contract.

I often see people mistakenly dragging the second group into the other two. For instance, people add DatabaseUnavailable to their error union as if it were a business failure. It isn’t. Let it throw, let the global handler catch it, and keep your domain model honest. 

HTTP 400 is not a domain concept. “Signing window closed” is.

In any case, if you recognize and split these three categories correctly, most of the design work is already done. The rest is choosing a mechanism that keeps the second group visible.

Why exceptions and their relatives keep losing

The default in most Java and Kotlin codebases is to validate, then throw:

fun signDocument(documentId: UUID, code: String) {
    if (signingWindowClosed(documentId)) throw SigningWindowClosedException()
    if (!codeMatches(documentId, code)) throw SignatureRejectedException()
    if (alreadySigned(documentId)) throw AlreadySignedException()
    // ... sign it
}

The signature says “returns nothing, succeeds.” But the implementation tells a different story, and the compiler will not make the caller listen to it. If someone adds a fourth exception next quarter, every call site still compiles, and every call site silently fails to handle the new case. You find out in production, and that’s not great.

Java tried to fix this with checked exceptions, and the instinct was right: force the caller to handle declared failures or pass them on. But it didn’t scale. And the Stream API doesn’t compose with checked exceptions at all, so you end up doing sneaky throws and wrapping everything back into runtime exceptions.

As it turns out, the better tool is already in the language itself. A sealed interface tells the compiler the complete set of subtypes, this means that when you handle these errors (using Kotlin’s when expression), the compiler can safely verify you haven’t missed a single case:

sealed interface DocumentSignError {
    data object SignatureRejected   : DocumentSignError
    data object SigningWindowClosed : DocumentSignError
    data object AlreadySigned       : DocumentSignError
}

Now the caller handles every case, and the compiler enforces it:

when (error) {
    SignatureRejected   -> showSignatureRejected()
    SigningWindowClosed -> showSigningWindowClosed()
    AlreadySigned       -> showAlreadySigned()
}

Add a fourth failure to the sealed interface and this when stops compiling until you handle it. And this is the whole game: the compiler now knows what can fail, and it won’t let you forget.

You just reinvented Either

Once you have a sealed error type, you need a way to say “this function returns either that error or a success.” You can build a wrapper by hand, and people do, for each result type, over and over. That gets verbose fast.

What you’re reaching for is a generic version of the same shape: a value that is one thing or the other, never both. Left for the failure, right for the success. That is Either, and you don’t need a library to understand it. It’s a sealed type with two cases and a handful of helper methods (map, flatMap, fold, getOrElse). If you’ve used Optional in Java or nullable types in Kotlin, you already know how it feels to work with. An Optional is roughly an Either whose left side carries no information, just Unit.

The payoff is that the failure set moves into the public type:

fun signDocument(
    documentId: UUID,
    code: String,
): Either<DocumentSignError, Unit>

Failures are no longer hidden in the function body; they are part of what the function tells you upfront.

Two unions people get wrong

Unfortunately, two anti-patterns show up constantly once teams adopt this, and both undo most of the benefit.

fun signDocument(documentId: UUID, code: String): 
Either<Throwable, Unit>

While this looks typed, the type says only “something can fail.” It does not say which expected failures the caller must handle, because Throwable is open, so a when over it always needs an else. You’re back to not knowing. 

This is essentially the same as throwing an error, and it’s why Kotlin’s own Result<T> type didn’t work out and isn’t recommended for domain modeling. If the left side is open, you’ve gained nothing.

The second is one broad union shared across a whole class, in the name of not repeating yourself:

sealed interface DocumentError {
    data object SignatureRejected   : DocumentError
    data object SigningWindowClosed : DocumentError
    data object AlreadySigned       : DocumentError
    data object TemplateNotFound    : DocumentError
    data object ExportFailed        : DocumentError
}
 
fun signDocument(...)     : Either<DocumentError, Unit>
fun prepareSigning(...)   : Either<DocumentError, SigningSession>
fun exportDocument(...)   : Either<DocumentError, ExportFile>

The compiler is happy, but now every method appears to return every error. signDocument can never produce TemplateNotFound, yet every caller has to account for it anyway. You get exhaustive handling full of impossible branches, which is just catch-all programming wearing a type.

The fix is to define one narrow union per public method:

sealed interface DocumentSignError { /* the three real failures */ }
sealed interface PrepareSigningError { /* its own set */ }
sealed interface ExportError { /* its own set */ }

Then each when handles only what its method can actually return. No else or impossible cases:

when (error) {
    SignatureRejected   -> showSignatureRejected()
    SigningWindowClosed -> showSigningWindowClosed()
    AlreadySigned       -> showAlreadySigned()
}

A little more typing up front, but worth it every single time you read one of these signatures later.

Composition, without drowning in the plumbing

Real flows chain steps, and each step can fail. Done naively with flatMap, the lambdas nest deeper with every step and the code gets ugly. 

You have a few ways out. Plain Kotlin handles it with early return:

val document = findDocument(documentId)
    .getOrElse { return it.left() }

Flat, typed, and the pattern itself needs no library: if you hand-roll Either, you write these helpers yourself. The syntax above happens to use Arrow’s getOrElse and left, but nothing here depends on the abstraction being fancy. 

If you want it cleaner, Arrow also gives you an either { } block where bind() unwraps a right value and short-circuits on the first left:

either {
    val document = findDocument(documentId).bind()
    validateStatus(document).bind()
    val signature = validateSignature(document, code).bind()
    markSigned(document, signature).bind()
}

This is the same idea Scala has had in the language for years with for-comprehensions. Use Arrow if the ergonomics help your team; it also brings useful types like non-empty lists. (But the contract idea does not depend on Arrow, and I’d rather you adopt the discipline than the dependency.)

The contract should survive the whole trip

A typed failure is only useful if it stays typed across the stack. Here’s the rule I hold to: services and repositories return domain errors, and you map to HTTP at exactly one place, the route boundary.

service.signDocument(request)
    .mapLeft { error -> error.toHttpResponse() }

Expected domain failures become an Either.Left. API-client misuse collapses to a coarse 4xx. Unexpected infrastructure failures and bugs stay as exceptions and become a 500. The controller is the only layer that knows about HTTP, and the layers beneath it speak in business outcomes.

There’s also a bonus most teams don’t realize here: If you publish your API client alongside the service, publish the error types with it. If you do this, the client handles failures with the same sealed union the server produces, and the two stay consistent for free.

How does this impact code review, and AI-generated code?

The day-to-day return on all of this shows up in review. When failures live in the signature, a reviewer can start from the contract instead of doing implementation archaeology. Did the error union change? Is this API-client misuse dressed up as a domain error? Does the new failure map to HTTP? You can answer those by reading the interface, before you ever open the body.

At Salmon and elsewhere, this agility matters more now that a large share of code is drafted by agents. 

When a model writes the implementation, an explicit contract is the cheapest way to check whether it did the right thing: you read the types, not the 200 lines underneath. You can put the rule in an agent instructions file, “return a typed error union, don’t throw for expected failures,” and the model will mostly follow it. But the way you verify is by reading the contract, not by trusting the prose. 

In fact, on our team at Salmon this is less a personal preference than a shared default: the contract is the unit of review, and a generated implementation doesn’t lower that bar. Deciding which failures an operation can actually produce is a judgment call, and the signature is where that judgment gets written down so the next person, or the next agent, has to respect it. Essentially, the signature is where ownership lives.

The honest tradeoff

This costs you something. More types, more mapping code, more verbose signatures. I won’t pretend otherwise. 

But the complexity was already there. The signing window could always close. The code could always be wrong. All this approach does is take that complexity out of the implementation, where it was hiding, and put it in the type, where it’s named, tested, and visible.

You are simply moving the work to where the compiler can help. It surfaces risk to the next caller instead of hiding it, makes clear what the code really does and stops broken paths from compiling. Making failures part of the signature is how those values show up at the smallest scale: one function telling the truth about what it can do. It is also how we work in practice at Salmon: we share these typed contracts across services and their clients, and in review we read the contract before the implementation.

A signature that returns Unit and throws in secret is lying to you about what it does. Make your signatures tell the truth!

Discover more than 4,200+ KMP projects

klibs.io combines information from GitHub and Maven Central, bringing the details needed to evaluate a project into a single catalog. When source metadata is incomplete, klibs.io uses LLMs to refine descriptions and tags, improving search and discoverability.

Discovery now goes well beyond a basic keyword search. Use multiple search terms, filter by supported platforms and targets – including Android, iOS, JVM, JavaScript, and Wasm – and browse curated categories such as Compose UI, local storage, networking, or dependency injection. Results can be sorted by relevance, GitHub stars, or dependent count.

Project pages make comparison easier by bringing together descriptions, tags, README content, supported platforms, package versions, dependent counts, license information, and project activity. 

This gives you a clearer view of whether a library fits your project before you add the dependency.

Bring klibs.io into your AI workflow

Library decisions often happen while you are already coding. The new AI integrations allow coding agents to pull structured, up-to-date data from klibs.io rather than relying solely on training data or a general web search.

Connect through the klibs.io MCP server

The klibs.io MCP server lets agents search Kotlin Multiplatform projects by platform and target and retrieve the latest published package versions directly from the klibs.io index.

Give agents reusable KMP library expertise

The Kotlin Multiplatform Libraries expert skill provides task-specific instructions for discovering and comparing libraries, recommending options for a use case, verifying platform support, and finding up-to-date dependency coordinates and stable versions. We measured agent output with and without klibs.io connected – the evaluation results are published in the klibs.io repository.

Keep project guidance close to the code

The AI integration guide includes setup instructions and a recommended AGENTS.md snippet. Adding guidance to a project helps AI tools consistently use verified information from the KMP library.

Help shape what comes next

klibs.io is an open-source project, and feedback from library users and authors helps the catalog keep improving. Here are a few ways to take part:

•  Try it out: Search for a library, explore a category, and see how the filters work for your target platforms.

•  Improve project information: Project owners can use the Suggest an edit option on project pages to propose better descriptions and tags through GitHub.

•  Report issues or contribute: Report bugs, missing libraries, or incorrect metadata in the GitHub issue tracker, or contribute directly to the open-source project.

•  Join the discussion: Share feedback in the #klibs-io channel on Kotlin Slack.

Whether you browse the catalog directly or integrate it with your AI tools, klibs.io now makes it easier to discover, compare, and use Kotlin Multiplatform libraries with up-to-date information.

The vision is simple: give backend developers a way to build server-rendered UI as type-safe, reusable Compose components (real Kotlin, with autocomplete, refactoring, and compiler checks) instead of string-based templates. No separate templating language, no separate UI codebase to maintain alongside the backend. This blog serves to explore some ideas how to achieve this vision and represents an exploration instead of an official commitment.

Every major JS framework now has an SSR story: React has Next, Vue has Nuxt, Svelte has SvelteKit. And it’s not only the JS ecosystem. C#, Rust and even functional languages like Elixir have innovative solutions to build fullstack apps without relying on templating engines. Instead, they bundle state and rendering into reusable components, directly in code, the same way Compose already does everywhere else.

Right now the JVM doesn’t have a horse in this race. There’s no shortage of SSR libraries on the JVM. But most of them need some sort of templating language and have nothing close enough to a component for a JS dev to recognize as such.

But there is already a framework that is battle-tested and capable of filling this gap for the JVM, it just never really targeted the server. Compose Multiplatform allows us to write business logic and User Interfaces once and share it between platforms: Android, iOS, Desktop, and the web. It just needs to make the jump to the server next.

Compose Multiplatform already targets the web, but not the way you’d want for this: it renders directly into a canvas, which shares UI code between mobile platforms and the browser at the cost of SEO, loading times, and accessibility.

A way to render HTML with Compose already exists, and it’s older than Compose for Web: Compose HTML, which uses the Compose runtime to build SPAs in Kotlin and compile it to JS using the Kotlin/JS compiler. Add a JVM target and it could do SSR too. The rendering happens directly in Kotlin: real components, real types, no templating language.

JVM devs stuck with Thymeleaf/JSP, or reaching for a separate JS framework just to build fullstack applications, wouldn’t have to leave the platform: type-safe, reusable Compose components replace what the templating language used to handle. Kotlin’s Java interoperability means it would slot into large legacy Java applications too.

Take something as basic as a reusable card component. In Thymeleaf, that’s a fragment defined in its own file, called by name, with parameters passed as untyped strings:

<!-- fragments/card.html -->
<div th:fragment="card(title, count)" class="card">
	<h3 th:text="${title}">Title</h3>
	<span th:text="${count}">0</span>
</div>
<!-- usage -->
<div th:replace="~{fragments/card :: card(title='Cart', count=${cartCount})}"></div>
<div th:replace="~{fragments/card :: card(title='Wishlist', count=${wishlistCount})}"></div>

Rename count to itemCount and every call site keeps compiling until it breaks at runtime. The compiler has no idea card or its parameters even exist.

The same component in Compose is a typed function:

@Composable
fun Card(title: String, count: Int) {
	Div({ classes("card") }) {
		H3 { Text(title) }
		Span { Text(count.toString()) }
	}
}
// usage
Card(title = "Cart", count = cartCount)
Card(title = "Wishlist", count = wishlistCount)

Rename count here and every call site either updates with the IDE or fails to compile. Pass a String where an Int is expected, and it’s a compiler error, not a runtime surprise.

Today Compose HTML only has a JS target, so it can only be used from the browser; there’s no way of doing SSR yet. That doesn’t mean the Kotlin web-dev ecosystem is standing still, though.

There is Kobweb, a batteries-included framework built on top of Compose HTML. It doesn’t offer SSR but supports static site export/prerendering to help with SEO. There is also Kilua, which doesn’t build on top of Compose HTML but on top of the Compose Runtime directly to do SSR and CSR, leveraging JS or Wasm, and offers integrations for Ktor, Spring Boot, and others. And there is Summon, with SSR and hydration support.

There’s already a small but active community leveraging Compose to build for the web. Adding SSR capabilities to Compose HTML would give Kobweb, Kilua, and Summon a shared foundation instead of three separate approaches, and give frameworks like Spring Boot and Ktor a good reason to integrate with it on the server.

This space isn’t totally unexplored, but everything from this point onward is pure exploration.

What Compose HTML on the server could look like

The first step would be to add a JVM target to Compose HTML, which is a bit easier said than done. There would need to be renderToString and renderToBytes functions that run a composition once on the JVM and serialize the resulting tree into a string.

fun renderToString(content: @Composable DOMScope<DomElement>.() -> Unit): String

val html: String = renderToString {
    Div({ classes("card") }) {
        Text("Hello")
        Span({ classes("title") }) {
            Text("World")
        }
    }
}
// html == """<div class="card">Hello<span class="title">World</span></div>"""

It composes once, lets the initial composition settle, walks the resulting tree, and serializes it straight to an HTML string: no browser, no DOM.

There are some limitations to this. There would probably be only a single render pass, meaning no recomposition on state change or any effects, in essence very similar to SSR in JS. Event listeners should be accepted but will be inert; there’s no point in binding to browser events on the server.

This would probably already be enough to build basic, entirely server-rendered pages using Compose. Here’s a full todo app on Spring Boot:

@Controller
class TodoController(private val todoService: TodoService) {

    @GetMapping("/todos")
    @ResponseBody
    fun todoView(): String = renderToString {
        TodoView(todoService)
    }

    @PostMapping("/todos")
    fun addTodo(createTodoDto: CreateTodoDto): String {
        todoService.addTodo(createTodoDto.title)
        return "redirect:/todos"
    }

    @PostMapping("/complete/{id}")
    fun completeTodo(@PathVariable id: Long): String {
        todoService.completeTodo(id)
        return "redirect:/todos"
    }
}

data class CreateTodoDto(val title: String)

@Composable
fun TodoView(todoService: TodoService) {
    AddTodo()
    TodoList(todoService)
}

@Composable
fun AddTodo() {
    Form(
        attrs = {
            action("/todos")
            method(FormMethod.Post)
        }
    ) {
        TextInput(
            attrs = {
                placeholder("Add todo")
                name(CreateTodoDto::title.name)
            }
        )
        Button(
            attrs = {
                type(ButtonType.Submit)
            }
        ) {
            Text("Add")
        }
    }
}

@Composable
fun TodoList(todoService: TodoService) {
    val todos by produceState(initialValue = emptyList<Todo>(), todoService) {
        value = todoService.getTodos()
    }
    Ul {
        todos.forEach { todo ->
            Li {
                Form(
                    attrs = {
                        action("/complete/${todo.id}")
                        method(FormMethod.Post)
                    }
                ) {
                    Text(todo.title)
                    Button(
                        attrs = {
                            type(ButtonType.Submit)
                        }
                    ) {
                        Text("Complete")
                    }
                }
            }
        }
    }
}

Every interaction here is a real HTTP form submission and full-page redirect: no client JS at all, same as classic Thymeleaf-style SSR, just written entirely in Compose.

At that point, frameworks like Spring and Ktor could start experimenting with integrations and identifying missing integration points. This would also be the first sensible point at which new libraries (e.g. components) could be created.

Going entirely off the rails into pure speculation, this is what such an integration could look like for Spring:

@ComposePage("/todos")
@Composable
fun TodosPage(todoService: TodoService) {
    AddTodo()
    TodoList(todoService)
}

@ComposeAction("/todos", method = PostMapping::class)
fun addTodo(
    @RequestBody createTodoDto: CreateTodoDto,
    todoService: TodoService
) {
    todoService.addTodo(createTodoDto.title)
}

The idea: a hypothetical Spring integration could turn a @Composable function directly into a routed page, no manual renderToString call, no controller boilerplate, no wrapping HTML shell. Spring would own request mapping and dependency injection exactly like it does today; Compose HTML would just be the render target instead of a View/template.

Or for Ktor:

routing {
    composable("/todos") {
        TodoView(todoService)
    }

    post("/todos") {
        val params = call.receiveParameters()
        todoService.addTodo(params["title"]!!)
        call.respondRedirect("/todos")
    }
}

composable(path) { } would be a thin wrapper Ktor could add: call renderToString internally and respond with the HTML content type, so a route body becomes a @Composable lambda instead of a string template or manual call.respondText.

Worth repeating: these are illustrative sketches, not planned APIs, not a roadmap.

Hydration and state sync are the natural next question, not an answer: how would a composable that already rendered on the server pick up interactivity in the browser, and would client and server ever need to agree on state? Answering that would also open the door to sharing UI code between client and server, the same component compiled once for the browser and once for the server, and enable interactive fullstack web apps built entirely in Kotlin.

Let’s be clear about scope: the goal is not to expand Compose HTML into a fully-fledged, batteries-included framework. Rather, the vision is similar to React’s: stay small and let frameworks build the integration points on top, just applied to a multiplatform library instead of a single-platform one. Framework integrations and ecosystem libraries live outside the core. That’s a real contrast to the rest of Compose Multiplatform, which ships official libraries for Material3 components, state management, and many other things. Compose HTML will need to rely on the Kotlin community and ecosystem to figure out what integration points are actually needed and how its future will look, instead of dictating a direction from the inside.

We are already talking to framework maintainers from Kobweb, Kilua, and Summon to gather their perspective, as well as the Spring team, which has expressed interest in experimenting once a JVM target is added to Compose HTML.

If you want to talk shop, argue with any of this, or just see where it goes, join the Kotlinlang Slack (get your invite here: https://kotl.in/slack) and the #compose-ssr channel.

Every other ecosystem already took its shot at the server. Kotlin’s turn is overdue.

The history of programming is, in part, a history of escape

Ada Lovelace wrote for a machine that did not yet exist in working form. A century later, programmers were wrestling with machines that had switches, punched cards, and raw numeric instructions. Then came assembly, and with it the first great bargain of software: give up a little closeness to the machine, and gain a little room for the human mind. But history does not stand still. With new languages and shifts in context, aspects of existing languages began to get in the way.

One language moved to such a high level of abstraction that its efficiency in the physical reality of the machine stopped holding up. Meanwhile, the fast-growing Internet of Things meant that programs now had to run on a coffee machine in a sense that was no longer metaphorical. In some places, development speed was missing. In others, safety was.

We escaped from assembly into C, from C into managed runtimes, from ceremonial enterprise Java into Kotlin, from dynamic-language freedom into TypeScript, from unsafe systems code into Rust, and from heavy frameworks into smaller cloud-native tools. At first glance, all migration channels seem clear. But how does this map onto reality?
Quite a lot of material, in one way or another, measures how the popularity of programming languages changes over time. Yet it seems that no one has really looked at the broader picture of how programmers themselves move between languages – not from the point of view of global trends in software development, but from the point of view of an individual path.

For us at JetBrains, it is very important to get closer to understanding what is happening from the programmer’s perspective, rather than from that of a programming historian or a career adviser. This is the perspective that matters most to us. In this spirit, we designed our State of Developer Ecosystem surveys with the goal of illuminating what the path of a real programmer looks like. Here’s what we found in 2025.
First, we should acknowledge that the path between languages can look like almost anything. Yes, the most common routes are between the leading languages: from Python to Java and back, with Java to Kotlin in third place by absolute numbers. But people migrate in every possible direction.

But we’ve gotten ahead of ourselves. Let’s take things one step at a time.

What we did before and what we achieved in 2025

Since the beginning of the Development Ecosystem survey, we have used the question “Do you plan to adopt or migrate to other languages in the next 12 months? If so, which ones?” We quickly found, however, that it is not a good predictor for future language migration. It’s one thing to plan to try Rust or switch from Java to Kotlin, but even for very common moves, the number of developers who actually make the switch is much lower than the number of those who have plans. Just because we have issues supporting our old Java 8 codebase, for example, doesn’t mean we’ll actually leave it.
So last year, we added a new set of questions regarding respondents’ previous experience with programming languages. We decided to assess actual migration over the past year using the question “What were your primary programming languages 12 months ago?” and some other related ones. This report addresses these questions, as well as the programming language landscape as a whole, based on the 8,837 responses we collected.
For reference, the following terms refer to the answers of the corresponding questions:
Used language – “Which programming languages have you used in the last 12 months?”
Primary language – “What are your primary programming languages? (Up to 3)”
Main language – “What is your main programming language?”

This сhart is based on the responses to the question “Which programming languages have you used in the last 12 months?” The increase in Java and Kotlin shares is most likely the result of a shift in the sample, rather than a real trend. The main fast risers are TypeScript and Rust, as we described in our 2024 Developer Ecosystem infographic. We also predicted some growth for Python, Go, and Lua, but only Go showed actual growth.

JetBrains Language Promise Index

The Language Promise Index tracks the migration prospects of languages in arbitrary units, based on the data we had on the stability of positive or negative migration dynamics and the number of people wishing to learn the language. Lua was previously one of the top languages in this category, but its growth has apparently reached a certain ceiling, and it is no longer among the leaders.

TypeScript, Rust, Python, and Go all still have large growth potential. We expect that a lot of people would change their main language from JavaScript to TypeScript while still using JS as their secondary language. 

As you can see, despite being the most popular language in terms of overall usage, JavaScript is the main language for only 6% of software developers, while Java is still much more popular as a main language. 

Unfortunately, we don’t have enough answers for most programming languages, so the next tables include only the most popular ones.

Surprisingly, C shows the lowest retention. About half of those who said that C was their main language last year have now switched to something else. This is a bit strange. Initially, we assumed that this flow probably consisted of students who had adopted C through their education and then switched to another language. However, the experience level has only a small effect. Half of those who dropped C chose “I wanted to learn a new language” as the reason for their change, which has a higher share than among switchers from other languages, who mostly chose “A project I am working on requires the usage of a new language.”
However, we didn’t have such questions for last year and do not see so much churn for C based on a comparison of shares with previous-year data (2.1% this year as a main language vs 2.0% in last year). But this churn rate may be a good predictor of future changes.

Why developers leave – and where they go

First of all, we should say that we don’t have data about everyone who churned – people who retired or switched to another career path don’t typically answer our developer surveys. Nevertheless, we do have enough information to draw some conclusions about why people decide to switch from one language to another.

Note: The sample is extremely small (less than 100) for C, Kotlin, and PHP.,
Some findings from this data:
1. Project requirements are the most common reasons for switching languages.
2. As we mentioned before, for C, “I wanted to learn a new language” and “More modern language features” are very popular reasons for switching, which probably point to widespread dissatisfaction and the language’s aging.
3. For JavaScript, the reason people leave is often “Better job market opportunities”.
4. Performance and scalability limitations are often a reason to switch from PHP.
5. “Other” reasons accounted for 18% of Kotlin churners. According to their answers, they are switching companies and switching between hobby and professional use.

The following tables, where both rows and columns list the same programming languages, require some additional explanation. Each one depicts the shift in respondents’ main languages. In the first, the columns are divided by last year’s responses for a given language, and the rows show the languages that respondents have moved to. Conversely, the second tracks where new language users are coming from, with the columns divided by respondents’ current main languages and the rows showing their previous answers. Each column totals 100%, because it tracks the same population over the course of a year. 

The tables show transitions from seeing one language as your “main” language to seeing another language that way. This does not mean that people stopped programming in the “abandoned” language altogether. It simply means that it stopped being their primary language.

This table shows where people go based on their previous language. Python is the main switch destination for all languages except C (whose users preferred to move to Java and C++) and TypeScript (where the top target destinations were Java, JavaScript, and C#).

Why developers adopt – and where they come from

Let’s look at the inverted perspective, based on the language to which people migrated.

Some findings from this data:

1. Surprisingly, JavaScript is both the main language people leave for better job market opportunities and the one people move to for the same reason. But these flows are not the same: one of the main sources for JavaScript growth is HTML/CSS. So, the pattern looks a bit like a conveyor belt: HTML to JavaScript to TypeScript. 
2. Project requirements are very common reasons for switching to C# and C++, suggesting many developers switch to these languages simply because they have to. 
3. People don’t go to Kotlin because they have to, but because it offers a better development experience and more modern language features.
4. Performance and scalability are the main attractions of Go, whereas ecosystem and library support are stronger attractions for Python.

At first glance, the following table may look the same as the main-language churn table above. But it is actually completely different, with a different meaning.

Here, the language that respondents see as their main language at the time of answering is taken as 100%. Accordingly, the diagonal shows what we called the continuity rate: the share of people who use this language as their main language now and also used it as their main language a year ago. Imagine that we have 150 respondents. Of them, 100 said they use a certain language as their main language this year, while 125 said they used it as their main language last year. 75 people used this language as their main language both a year ago and at the time of the survey.

In this case, the retention rate would be 75%, while the continuity rate would be 60%. It is important to note that everyone else is not necessarily a “newcomer” to the language. They may well have used this language before, just not as their main one.

In terms of growth sources, Python is the main source for C, C#, C++, Go, Java, and JavaScript, which is not surprising, because it is one of the most popular languages.

For Kotlin, the main growth source is Java, while for PHP and TypeScript, it is JavaScript.

For Python itself, the main growth source is Java. 

Conclusion

By looking at actual moves instead of plans, we shift from intention to action – not what developers say, but what they do. The ecosystem data stops being a snapshot and starts to look like a map of flows.

Project requirements still do most of the pushing. Necessity, not choice, drives many switches, but not all. Some languages win on specific jobs, others on performance or ecosystem. And many developers move in chains: from HTML/CSS to JavaScript, and then further along – a conveyor belt of skills, where each step opens the next.

Churn tells a clearer story. C leaks talent faster than expected, even if its headline numbers look stable. Java remains a hub, but its outflow goes mostly to Python and TypeScript, not Kotlin. Python acts as a catch-all destination. TypeScript and Rust still look like the forward edge.

Kotlin, our own language, plays a different game – and plays it well. Developers come not because they have to, but because they want to, drawn by cleaner syntax, fewer rough edges, and a development experience that simply feels better. It wins on pull, not push. Yet the inflow from Java is weaker than expected, and some developers even switch back.

The picture that emerges is a simple one of push, pull, and drift. With the new data, we see not just which languages grow or shrink, but how it happens – which languages move with the current, and which have to work against it.

Let’s see what DevEco’26 will reveal.

Here’s what stood out to me most over the past month:

Kodee-approved spotlight

Kotlin turned 15: Leave a birthday wish

This one is close to my heart – Kotlin recently turned 15! To mark the milestone, we’re inviting the whole community to celebrate. You can create a birthday postcard, upload a photo to party with me, and share a wish or a prediction for Kotlin’s next chapter. Now is the perfect moment to look back at how far we’ve come – and to look ahead together.

Join the celebration

Ship Kotlin Everywhere Award at RevenueCat Shipaton 2026

Already know Kotlin? RevenueCat Shipaton 2026 is the perfect opportunity to turn your Kotlin skills into a new app. From August 1 to September 30, build and ship for Android, iOS, desktop, or web and compete for the Ship Kotlin Everywhere Award. Use the KMP starter guide to get your project up and running. To earn bonus points, you can help others by sharing your development journey. Shipping is impressive, but helping someone else is even better.

Learn more and register

The Kotlin Benchmark for AI coding agents

Kotlin now has its very own public benchmark for AI coding agents. It ranks agents on 105 real engineering tasks drawn from open-source Kotlin repositories, so you can compare them by resolution rate, token cost, and latency – and dig into the methodology behind the numbers. As AI becomes a bigger part of coding in Kotlin, I love that we finally have an open, Kotlin-specific way to measure what actually works.

Explore the benchmark

Kotlin 2.4.10 and Kotlin 2.4.20-Beta2

July brought the Kotlin 2.4.10 bug fix release, alongside Kotlin Kotlin 2.4.20-Beta2 with coroutine stack trace recovery, faster klib compilation, expanded Swift export, and an experimental compiler native image. Try the Beta version and share your feedback while the release is still taking shape.

See the Kotlin 2.4.10 changelog

Kotlin comes to BlueJ

Kotlin support is now available in BlueJ 6.0 thanks to a collaboration between JetBrains and the BlueJ team at King’s College London. Students can create, edit, compile, and run Kotlin code, inspect class diagrams, and interact with objects through BlueJ’s familiar workflow. For educators, a new onboarding guide and ready-to-use materials make it easier to include Kotlin’s concise syntax and null safety in introductory object-oriented programming courses.

Read the post

A conversation with the Golden Kodee winners

The first Golden Kodee Community Awards recognized Matheus Leandro Ferreira, Jaewoong Eum, Nicole Terc, Eeva-Jonna Panula, and Yinlong Liu for their contributions to education, online presence, creativity, positive societal impact, and in-person community building. Read their interviews and watch the video to discover practical advice on learning in public, starting small, and helping the community grow.

Meet the Golden Kodee winners

Showcase your JetBrains IDE experience on LinkedIn

The free LinkedIn Connected Apps plugin lets you connect a supported JetBrains IDE to your LinkedIn profile. Once connected, a profile statement highlights how you use your IDE in practice, based on usage data that stays on your machine. As your development habits evolve, the statement updates automatically to reflect your experience. It is designed to showcase practical tool usage – not to rank developers or replace formal certification.

Connect your IDE to LinkedIn

How I came to life

I didn’t always look like this! My journey began with a simple robot-inspired concept. Then, with the help of research, creativity, and community feedback, I evolved into the Kodee you know and love today. Check out my origin story (including how I got my name!).

Discover the story behind Kodee

KMP library spotlight: Ktor, Koin, and Kermit

Finding the right KMP library shouldn’t slow down your project. klibs.io brings together more than 4,100 Kotlin Multiplatform libraries, with filters for developers and AI integrations that give coding agents access to accurate, up-to-date library data. This month, we’re spotlighting Ktor, Koin, and Kermit – a practical trio for networking, dependency injection, and logging.

Find your next KMP library

X rebuilds its Android app in 100% Kotlin

Built from scratch, X’s Android app is now written entirely in Kotlin. X Chat also uses Kotlin Multiplatform across Android, iOS, and web for end-to-end encryption, storage, sync, and business logic. It’s exciting to see Kotlin and Kotlin Multiplatform used at this scale.

Check out the rebuilt app

Where you can learn more

• Learn how to use Navigation 3 in Compose Multiplatform.
• Move a KMP project from CocoaPods to SwiftPM dependencies with help from Junie.
• Connect your AI coding agent to klibs.io for up-to-date KMP library data.
• Use Kotlin AI skills for common migration tasks.
• KotlinLLM is Going Open Source.
• Learn how to secure APIs built with Kotlin and Spring Boot using OAuth2 and JWT.
• Build a task manager app with Kotlin, Spring Boot, and Claude Agent.
• Explore Backend Development with Kotlin – presentation slides and a runnable demo project.
• Listen to Sébastien Deleuze and Josh Long talk Kotlin for backend on A Bootiful Podcast.

YouTube highlights

• Sony’s KMP Journey: Scaling BLE & Hardware with Kotlin Multiplatform | Sergio Carrilho.
• What’s New in Compose Multiplatform | Sebastian Aigner and Márton Braun.
• Run, Kotlin, Run! | Marc Reichelt.
• A First Look at the Kotlin Ecosystem Plugin for Declarative Gradle | Marcin Mycek.
• Building Enterprise Ready AI With Koog | Vadim Briliantov.
• Real-World Data Science With Kotlin Notebook | Adele Carpenter.
• Evolving Kotlin Language Defaults | Michail Zarečenskij.
• Context Parameters and API Design | Alejandro Serrano Mena.
• Concurrency Patterns for Modern High-Performance Kotlin Servers | Bowen Feng.
• Deconstructing OkHttp | Jesse Wilson.

If you know Kotlin, that idea is closer to the App Store than you think.

Join the Shipaton

The Ship Kotlin Everywhere Award

JetBrains is a Gold Sponsor of Shipaton this year, with our own category. The idea is simple: reuse the Kotlin you already know to build one brand-new app and bring it to multiple platforms, including Android, iOS, desktop, and web, with Kotlin Multiplatform and Compose Multiplatform.

You don’t need to hit all four platforms. Judges reward effective cross-platform development, not platform count alone.

What you can win

The award has a $30,000 prize pool split among three winners: $15,000, $10,000, and $5,000. The first-place app also receives Shipaton’s first-place category winner package: a feature on a Times Square billboard, an invitation to RevenueCat’s App Growth Annual conference in New York City on October 21, a custom Shippy trophy, and a media spotlight.

One more thing: you submit once and compete everywhere. Your Kotlin Multiplatform app also stays in the running for the $100,000 Grand Prize and more than 20 other categories, from #BuildInPublic to the Best Game Award, with over $1,000,000 worth of prizes in total.

Don’t just take our word for it. Here’s Chris Krueger, whose app Momental took first place in our KMP category at Shipaton 2025:

“Building Momental with Kotlin Multiplatform was very enjoyable. Sharing one codebase for Android and iOS gave me so much more time to focus on user feedback and actually improving the app. I was amazed how quickly I could build a beautiful, complex UI — even features like a full music player with soundscapes worked smoothly across platforms.

If you’re hesitating, just enter the challenge. It forces you to grow, explore new parts of KMP, and ship faster than you expect. You’ll reach way more users than you think possible.”

What you get as a participant

• IntelliJ IDEA Ultimate, free for 3 months for the first 1,000 builders
• Access to Junie, our AI coding agent, for 2 months for 200 builders ready to build in public
• A Starter Guide, an AI Guide, weekly livestreams, and JetBrains advocates answering questions in Discord

Ready to ship?

Everything you need is on the award page: rules, the starter kit, offers, and the timeline.

Join the Ship Kotlin Everywhere Award

Happy shipping!

Qodana 2026.2 makes it easier for development teams to act on code quality, security, and compliance findings throughout the development workflow. This release introduces clearer code coverage insights for pull requests, highlights uncovered new lines directly in the IDE, and automatically detects coverage reports in common project locations – reducing the configuration required to get started.

The release also expands Qodana’s security offering with new inspections, support for custom security rules, post-quantum cryptography inspections, and publicly available SAST benchmarks through SABER. Laravel inspections are now enabled by default, while new License Audit quality gates help teams prevent newly introduced dependencies with prohibited or unknown licences from progressing through the pipeline. Let’s get into the details.

Try Qodana

Better Code Coverage UX

Code Coverage for incremental analysis in the IDE

Starting with Qodana 2026.2, pull request analyses can show which changed or added lines are covered by tests and which are not, alongside the total coverage for newly added code, known as fresh coverage.

After the analysis, developers can open the report in the IDE and browse the files changed in the pull request. They can see which files lack coverage through statistics in the tool window, while new lines are highlighted in the IDE to reveal coverage gaps. Developers can use this information to write targeted tests for functionality that lacks coverage, improving the reliability of their software.

Out-of-the-box code coverage reporting

Showing code coverage results in Qodana now requires fewer configuration steps. You no longer need to copy all reports to the .qodana/code-coverage directory, which lets you simplify your build configuration.

Qodana 2026.2 automatically detects coverage reports in the project:

• Qodana for JVM and Qodana for Android: default paths for Jacoco and Kover plugins are supported for both Maven and Gradle
• Qodana for JS: default location coverage/lcov.info is supported, as well as some common community locations like reports or test-coverage directories
• Qodana for PHP: clover.xml and coverage.xml files are supported in common in community locations, such as the project root, build/logs, reports and coverage
• Qodana for Python:  coverage.xml file is supported in common locations like project root, coverage-reports or reports
• Qodana for Go: coverage.out or cover.out files in root directory and other common directories like  coverage, reports are supported
• Qodana for .NET: coverage.cobertura and coverage.info files in project root or other common directories like  coverage or TestResults are supported
  

To generate code coverage reports, set up one of the supported tools, and see your statistics in any run. To disable this behaviour, either selectively copy your reports to the .qodana/code-coverage directory, or specify your custom location using a new codeCoverageLocations parameter in your qodana.yaml file. See the documentation for an example of how to specify a custom directory. To disable coverage reporting, disable the corresponding inspection in your configuration.

View Documentation

New security inspections

Broader SAST and multi-file taint analysis

Qodana 2026.2 expands the security analysis available in the Qodana for .NET linter, helping teams detect a broader range of vulnerabilities in C#, JavaScript, and TypeScript code. The new inspections are enabled by default in the recommended profile and appear as standard Qodana findings within existing IDE, CI/CD, and reporting workflows.

The expanded inspection set combines two forms of analysis. Pattern-matching rules identify insecure coding practices within individual code locations, while taint analysis tracks untrusted data as it moves through an application, including across multiple files. This enables Qodana to detect vulnerabilities such as SQL injection, command injection, cross-site scripting (XSS), and path traversal.

Teams can also extend this coverage with their own security rules. Qodana for .NET now supports custom and third-party rules written in the OpenGrep format. Place these rules in the .qodana/opengrep directory at the project root, and Qodana will make them available as Qodana inspections.

The predefined rules are publicly available in the opengrep-sast-rules repository. Behind the scenes, pattern matching uses an open-source JetBrains fork of OpenGrep, while data-flow tracking is handled by Qodana’s own taint analysis engine. This gives teams access to the OpenGrep rule format and ecosystem while retaining Qodana’s multi-file analysis and developer workflows. Support will be extended to additional Qodana linters and languages (Kotlin/Java) in future releases.

The following example shows how Qodana detects a classic SQL injection vulnerability in the WebGoat.NET project. The taint trace follows untrusted input from Request[“productNumber”] to its use in an SQL query located in another file.

The taint trace begins with the untrusted user input in the Request[“productNumber”]

SABER – Static Analysis Benchmark Evaluation Runner

To make the performance of these inspections easier to evaluate, we have introduced SABER, the Static Analysis Benchmark Evaluation Runner. SABER runs Qodana against publicly available security benchmarks and compares its findings with known expected results.

Transparent SAST benchmarking with SABER

The current benchmark suite includes:

• CodeQL benchmarks for C# and JavaScript, built from CodeQL .expected files
• WebGoat.NET, using publicly available ground-truth data from Sonar
• The Qodana post-quantum cryptography demonstration project

The benchmark configurations, individual runs, and aggregated results are publicly available on the SABER TeamCity instance.

Guest access is enabled, allowing anyone to inspect the results and follow how Qodana’s SAST capabilities develop over time. It is available via this link. Guest access is enabled, so anyone can open it using the ‘Log in as guest’ option. We have a strong commitment to demonstrating SAST-related capabilities and continually improving them using industry-standard benchmarks. For example, this is the aggregated report for the currently available benchmarks:

Projects ‘CodeQL C#’ and ‘CodeQL JS’  use the jetbrains-qodana/codeql-benchmark project that is built from the CodeQL ‘.expected’ files. Project WebGoat.NET is a well-known vulnerable C# project (our fork is here: jetbrains-qodana/WebGoat.NET) and uses the publicly available ground-truth.json as the expected results. The PQC demo project is a test project that demonstrates the capability to identify post-quantum cryptography issues in your code.

Post-Quantum Cryptography (PQC) inspections

If you have heard about quantum computation, you might know that it will, in the future, easily break many widely used public-key cryptographic algorithms (such as RSA and ECC). Even though quantum computation is not yet widely spread, you should be ready now because of the Harvest Now, Decrypt Later approach, in which future attackers might already harvest and store your encrypted data to decrypt it later.

Qodana for JVM now includes inspections that help developers identify affected code and guide them toward post-quantum cryptographic alternatives, reducing future security risk and supporting a gradual, manageable migration, helping organizations prepare for quantum-era security risks.

Our PQC inspections are implemented in accordance with NIST recommendations and are grouped into several priority levels (called PqcMinLevel1, PqcMinLevel2, and so on to PqcMinLevel5). To enable these inspections, activate one of the corresponding groups that represent NIST-based post-quantum readiness levels:

• Level 1 – Flag pre-quantum and legacy cryptographic algorithms. This uncovers the most critical vulnerabilities.
• Level 2 – Flag baseline post-quantum algorithms.
• Level 3 – Flag standard-strength post-quantum algorithms.
• Level 4 – Flag high-strength post-quantum algorithms.
• Level 5 – Flag all algorithms except those providing maximum security.

Every level includes all previous levels, so level 5 includes inspections from levels 1-4 as well.

We also prepared a demo project (PQC demo) that showcases PQC’s current capabilities. These inspections are backed by OpenGrep and taint analysis (described in the previous section), which also support excellent pattern matching and multifile taint analysis for Java and Kotlin, as shown in the example below.

A non-compliant crypto protocol is found in a string constant

Laravel checks enabled by default

Qodana for PHP now includes Laravel code inspections. This reduces the number of false positives in PHP code, and analyses code for Laravel-specific code problems, such as directly assigning values to guarded attributes.

Quality gates on License Audit

Qodana 2026.2 adds support for license audit quality gates, with two new options:                                                                                                                                                                              

• failOnProhibited — fails the run if any dependency uses a license prohibited by your configured license rules.                                                                                            
• failOnUnknown — fails the run if any dependency has a license that couldn’t be detected or categorized.

For example, in qodana.yaml, the failureConditions section may now contain a dependencyLicenses block:

failureConditions:                                                                                                                                                                                                                     
  dependencyLicenses:                                                                                                                                                                                                                  
    failOnProhibited: true
    failOnUnknown: true

Qodana evaluates the quality gate against the collected dependency licenses directly, independently of whether License Audit problems are present as inspection results. Only the CheckDependencyLicenses inspection needs to be enabled.

License audit quality gates also work for incremental analysis, and only fail on new violations.

What to do next:

If you’re already using the latest release, you’re ready to start using the improvements in Qodana 2026.2 right away. If not, update to 2026.2.

For setup details and feature-specific guidance, head over to the documentation. If you’d like to see what Qodana can do in your own environment, try it on your project and explore the latest updates on the Qodana blog.

Request a demo if you’d like to learn more from our sales team or want 20% off when switching to Qodana from a comparable, commercial solution.

Request Qodana Demo

Mdu Sibisi

Mdu Sibisi is an Oracle-certified software developer and blogger with over ten years of experience working primarily with object-oriented languages. He has been writing about technology for more than eight years, focusing on making complex topics easier to understand. Mdu is passionate about accessible developer education, clean code, and creating content that helps developers learn and grow.

Website | Twitter

Repository with the companion code for the tutorial

Go to GitHub

APIs are frequent targets for bad actors since they expose data and functionality. Securing them while maintaining usability is often one of the most challenging and time-consuming parts of API development. OAuth 2.0 and JSON Web Tokens (JWT) help make these processes more manageable and reliable. They allow developers to represent and verify identity and manage access by safely transmitting claims and enabling delegated authorization.

This article discusses these technologies and the most efficient ways you can use them to secure your Spring Boot-built APIs and backends. If you’re interested in a coroutine‑driven solution, a companion tutorial using Ktor is also planned and will be published soon.

OAuth2 and JWT Primer

OAuth2 and JWT(s) aren’t competing technologies. They’re complementary pieces of the puzzle, with one handling the delegation of authorization and the other serving as the compact, verifiable token format that carries secure information.

Authentication vs. Authorization

Authentication verifies identity (who you are), usually through credentials like passwords, tokens, or certificates. JWTs can carry identity information and act like a form of ID once issued. Roles and other claims within a JWT are then used for authorization.

Authorization helps control what a user has access to (what they can do). This includes the scopes or resources that they can “touch” and how those permissions are managed. In a system that uses OAuth2 and JWT, the access badge is bundled into your ID card. OAuth2 oversees and manages this process.

The Role of OAuth2

OAuth2 is a framework for delegated access. Instead of sharing passwords directly, users grant applications a token that represents their permissions. This means that your backend (acting as a Resource Server) doesn’t have to issue tokens. Instead, it trusts and validates the ones coming from the Authorization Server within OAuth2’s framework. This decoupling of duties allows you to simplify your APIs while reducing security risks and ensuring all tokens follow a clear, consistent, centralized policy.

You don’t have to worry about implementing user logins or browser redirects within your API. As far as validation and authorization are concerned, your backend or API’s job is to receive the Bearer Token, authenticate the signature, check expiration, and enforce scopes/roles.

Your API just checks badges; it’s not responsible for printing them. So how do JWTs fit into the equation?

What Is a JWT?

A JWT is a small, web-friendly piece of text (string) that securely transports information between systems. Their compactness makes them easy to pass around in HTTP headers or URLs. Each token uses Base64URL encoding, making them safe to include in query strings or headers.

JWTs are signed (and sometimes encrypted), so that recipients can verify that they weren’t tampered with. They’re also self-contained, carrying details like user ID, roles, or permissions. These elements (especially self-containment and signing) allow for stateless authentication without Session Storage. This means that you don’t need a database or cache to track active sessions. It also encourages fewer lookups and less infrastructure complexity, which reduces your system’s overhead.

JWTs have a very simple, standardized structure made up of three parts, separated by dots:

• The Header contains metadata about the token, such as the type (JWT) and the signing algorithm (HS256, RS256).
• The Payload features the claims, which are statements about the user or system (like user ID, roles, or token expiry).
• The Signature is a cryptographic signature created using the header, payload, and a secret or private key. This ensures the token has not been tampered with.
  

The basic structure of a JWT looks like this:

xxxxx.yyyyy.zzzzz

A real-world Base64URL-encoded token typically resembles the following:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

When OAuth2 meets JWT

There are four key roles in OAuth2’s implementation:

• Resource Owner: The entity (usually the user) granting access to the protected resources.
• Client: The application requesting access to the resource on behalf of the resource owner.
• Authorization Server: The server that authenticates the resource owner and issues access tokens to the client.
• Resource Server: The server hosting the protected resources, which accepts and validates tokens.
  

The Resource Owner grants permission (e.g., you click “Allow” when an app requests access), the Client then requests authorization from the Authorization Server, which issues an access token (JWT) if the Resource Owner approves. The Client uses this access token to access data from the Resource Server.

How to Implement OAuth2 and JWT

Imagine you’re building a simple document management system with a Kotlin and Spring-based backend that exposes a REST API. This implementation lets clients upload documents, list them, view specific ones, etc. Some potential endpoints the API can expose include:

• GET /documents: Lists all documents.
• GET /documents/{id}: View a specific document.
• POST /documents: Upload a new document.
  

You want to restrict access so that only authenticated users can view or upload documents, but you don’t want to manage passwords in your backend. You also don’t have to maintain sessions or deal with login forms.

Prerequisites

If you want to follow along, you’ll need:

• IntelliJ IDEA
• JDK 17+
• Google Cloud Console
• A basic understanding of Kotlin, Spring Boot, and Spring Security
  

All the code used in this tutorial is available on GitHub repository.

Initial Application Setup

To start, run IntelliJ IDEA and create a new project (File > New > Project):

Select Spring Boot under the Generators section on the left panel. Give your project a name (like doc-manager), select Kotlin as the Language, Gradle – Kotlin as the Type, 17 as the Java version, Jar as the packaging, and Properties as the configuration. Leave all other properties in their default state and then click Next.

On the next screen, select dependencies for your project. Make sure you’re using the latest stable version of Spring Boot (4.0.3 at the time of writing) and then use the search bar to find and add the following dependencies:

• Spring Security
• OAuth2 Authorization Server
• OAuth2 Resource Server
• Spring Web
  

Once that’s done, click Create.

After your project’s done importing and loading, expand your project, scroll down, and find the application.properties file under the resources folder (src > main > resources). Add the following lines to it:

spring.application.name=doc-manager-kotlin-demo

spring.security.oauth2.resourceserver.jwt.public-key-location=classpath:public.pem

In most cases, you’d specify an Authorization Server (issuer-uri) here. But to keep things simple, you won’t be using a real Authorization Server for this part of the implementation (this will come in later). So you need to supply your application with a public key to verify signed tokens. You can generate your own publickey.pem using OpenSSL or use the ones provided in this project’s resources folder. Make sure to save and store the private.pem. You’ll need it for JWT generation. 

Configure Your Resource Server

Create a resource controller for your endpoint:

// Insert Your Package Name Here + .controller

import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController

@RestController
@RequestMapping("/api")
class ResourceController {
    @GetMapping("/fetchDocuments")
    fun fetchDocumentsEndpoint(): String {
        return "Here are your documents"
    }
}

For now, the ResourceController class contains only one endpoint.

Next, create a security configuration for your Resource Server:

// Insert Your Package Name Here + .config

import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.springframework.http.HttpMethod
import org.springframework.security.config.annotation.web.builders.HttpSecurity
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity
import org.springframework.security.config.http.SessionCreationPolicy
import org.springframework.security.web.SecurityFilterChain

@Configuration
@EnableWebSecurity
class OAuth2ResourceServerSecurityConfiguration {

    @Bean
    @Throws(Exception::class)
    fun securityFilterChain(http: HttpSecurity): SecurityFilterChain =
        http
            .httpBasic { it.disable() }
            .formLogin { it.disable() } 	// Disables Spring's default form-based login
            .csrf { it.disable() } 		    
            .authorizeHttpRequests {
                it.requestMatchers(HttpMethod.GET, "/api/fetchDocuments").hasAuthority("SCOPE_read:documents") // Verifies that client has read access  
                it.anyRequest().authenticated()			   	
            }
            .oauth2ResourceServer {  // Enables JWT‑based authentication for an OAuth2 Resource Server.
                it.jwt { }
            }
            .sessionManagement { it.sessionCreationPolicy(SessionCreationPolicy.STATELESS) }
            .build()
}

If you’ve worked with Spring Security in Java before, you’ll likely notice how clean the Kotlin DSL looks in comparison. References to OAuth2LoginConfigurer, wrapping lambdas in Customizer, or even annotations like @Throws(Exception::class) aren’t strictly necessary (unless you’re working with a mix of Java and Kotlin). Kotlin’s DSL trims that away and lets you express the rules directly.

Now, generate the JWT using the private key (found in the private.pem). Make sure to encode it using the RS256 and that the claims are set and formatted correctly:

Run your Spring Boot application and then initiate an authenticated request to the /fetchDocuments API endpoint with your generated JWT as the bearer token:

GET http://localhost:8080/api/fetchDocuments
Bearer Token <JWT>

If it works as it should, you should see “Here are your documents” as a response. This implementation enables you to simulate a client sending a request with a Bearer token (JWT). Upon receiving the token, your Resource Server (backend) checks the expiry date and signature using the details in your application’s properties file. It also looks for the read:documents scope before granting access to the fetchDocument endpoint.

Handling Advanced Patterns and Validations

In a document management API (and most complex systems), simple scope checks aren’t enough. They can grant coarse permissions, but they often fail to capture the nuance of real-world access control. To address this, the system must separate token validation (ensuring the JWT is authentic) from business authorization (deciding what actions a user can perform).

Scopes alone can’t enforce ownership or hierarchical rules, and they don’t capture organizational roles. That’s why you need a combination of scope and role-based access, where administrators can access all features, while lower-level users are granted only a few. By layering roles, scopes, and resource checks, the API achieves fine-grained, context-aware authorization that balances security with usability.

Hardcoding security decisions in such systems should be avoided at all costs. Practices like embedding role checks or scope logic directly into controller methods may seem convenient at first, but it introduces significant risks as your system grows. A developer might forget to update one of these hardcoded checks when business requirements change, leaving certain endpoints exposed or inconsistent. Hardcoding also undermines separations of concerns. Security decisions should be modeled in a dedicated layer, not mixed into business logic.

Using Custom Claim Extraction and Spring Security’s PreAuthorize

Like most token formats, JWTs can carry custom claims in their payloads. A JWT with custom claims for roles and permissions would look something like this:  

{
  "iss": "https://myapp.com/auth",
  "sub": "mdu",
  "iat": 1773754406,
  "exp": 1773840838,
  "scope": "read:documents",
  "roles": ["admin", "editor"],
  "permissions": ["documents:read:all", "documents:write:own"]
}

Spring handles authority mapping for scopes out of the box and provides a hasRole function. However, roles aren’t automatically extracted from JWTs because there is no universal standard for how identity providers represent them. Scopes are standardized in OAuth2 and OpenID Connect, so Spring can safely map them into authorities. Roles often appear under custom claims and require a custom converter to translate them into Spring’s expected format before they can be used effectively.

Let’s say you want to authenticate and authorize based on roles and scope. Navigate to your security config and add the following function:

@Bean
fun jwtAuthenticationConverter(): JwtAuthenticationConverter {
    val converter = JwtAuthenticationConverter()
    converter.setJwtGrantedAuthoritiesConverter { jwt ->
        val authorities = mutableListOf<GrantedAuthority>()

        // Map scopes
        val scopes = (jwt.claims["scope"] as? String)?.split(" ") ?: emptyList()
        authorities.addAll(scopes.map { SimpleGrantedAuthority("SCOPE_$it") })

        // Map roles
        val roles = jwt.claims["roles"] as? Collection<*> ?: emptyList<Any>()
        authorities.addAll(roles.map { SimpleGrantedAuthority("ROLE_$it") })

        // Map permissions
        val permissions = jwt.claims["permissions"] as? Collection<*> ?: emptyList<Any>()
        authorities.addAll(permissions.map { SimpleGrantedAuthority(it.toString()) })

        authorities
    }
    return converter
}

This changes the behaviour of the JwtAuthenticationConverter so that it no longer relies solely on Spring Security’s default scope mapping. Instead, it explicitly maps both scopes and roles from the JWT into Spring authorities. If you mapped only roles, then Spring Security would ignore the scope claim entirely.

Kotlin ensures the safe extraction of custom claims thanks to its null-safety. For instance, take a look at the scope mapping section of the code. The safe call operator (?.) ensures that if jwt.claims["scope"] is null, the chain stops gracefully instead of throwing a NullPointerException. The safe cast operator (as? String) attempts to convert the value returned from the jwt.claims["scope"] operation into a String from an Any? (could be anything or null). If the safe cast operator fails, it returns null instead of throwing a ClassCastException. This allows for type-safe conversions that won’t interrupt or break your code. The Elvis operator (?:) provides a fallback value when the left-hand side is null. So if the role is missing for whatever reason, the function returns an empty list as a default value.

The tricky part is adding validations for all these claims. If you were checking these claims individually, you could use the hasRole function for roles, and hasAuthority for scopes and permissions. One way to chain these validations together would be to use the access function. Here, you’ll use [Spring’s Method Security](Spring @EnableMethodSecurity Annotation | Baeldung) (@PreAuthorize) because it offers a more fine-grained and cleaner approach.

Return to your Security Config file and place the @EnableMethodSecurity(prePostEnabled = true) above the class definition:

...
import org.springframework.security.config.annotation.method.configuration.EnableMethodSecurity

@Configuration
@EnableWebSecurity
@EnableMethodSecurity(prePostEnabled = true)
class OAuth2ResourceServerSecurityConfiguration {
    class SecurityConfig(
... 

You can keep your security filter chain as is for now. Navigate to your resource controller, and add the @PreAuthorize annotation to it:

...
@GetMapping("/fetchDocuments")
@PreAuthorize("hasRole('admin') and hasAuthority('documents:read:all')")
fun fetchDocumentsEndpoint(): String {
    return "Here are your documents"
}
...

This ensures that only admins with read-all permissions can access the fetchDocuments endpoint. You can create more endpoints, like getDocument and deleteDocument to test the combination of your roles and permissions. The @PreAuthorize annotation helps you avoid embedding role checks or scope logic directly inside controller methods (for example, writing if (user.hasRole("admin")) { ... } in the body of a controller). Alternatively, you can perform your role checks in your filter chain and your scope and permission checks on the method level.

Strengthening Token Trust: Issuer and Audience Enforcement

Under most normal circumstances, you’d supply Spring Security with an issuer URI in your application properties file. Then Spring would do the work of finding the Provider Configuration or Authorization Server Metadata and using them to decode your JWT. But as you learned here, these can be bypassed when you’re using custom-generated keys.

Regardless of whether you’ve configured an issuer URI or not, it’s important to explicitly verify the issuer (iss) in your code to ensure that every incoming token actually claims the same issuer and prevent token replay across apps. This adds defense in depth and makes your security posture clear in code. Likewise, audience (aud) ensures that the token is meant for your API, not for some other application. When both the issuer and the audience are checked, it prevents tokens from other apps or environments from being accepted by your API.

To validate these claims, you’ll need to create a custom JwtDecoder. But, because Spring doesn’t have a dedicated OAuth2TokenValidator for its audience, you’ll need to create one. Re-open your Security Configuration file and add the following class (nested):

class AudienceValidator(private val audience: String) : OAuth2TokenValidator<Jwt> {
    override fun validate(token: Jwt): OAuth2TokenValidatorResult =
        if (token.audience.contains(audience)) {
            OAuth2TokenValidatorResult.success()
        } else {
            OAuth2TokenValidatorResult.failure(OAuth2Error("invalid_token", "The required audience is missing", null))
        }
}

Then, add the following method:

@Bean
fun jwtDecoder(): JwtDecoder {
        val issuer = "https://myapp.com/auth"           // Replace with your own official issuer URI
        val audience = "http://localhost:8080/api/"

        val decoder = JwtDecoders.fromIssuerLocation<NimbusJwtDecoder>(issuer)

        // Add audience validation
        val audienceValidator = AudienceValidator(audience)
        val issuerValidator = JwtValidators.createDefaultWithIssuer(issuer)

        val validator = DelegatingOAuth2TokenValidator(listOf(issuerValidator, audienceValidator))
        (decoder as NimbusJwtDecoder).setJwtValidator(validator)

        return decoder
}

This function builds a custom JwtDecoder that enforces stricter validation on incoming JWTs. It starts by creating a decoder from the configured issuer, then defines two validators: one to ensure the token’s aud claim matches the expected audience, and another to ensure the iss claim matches the trusted issuer. These validators are combined into a DelegatingOAuth2TokenValidator and applied to the decoder, so that only tokens issued by the correct identity provider and intended for your application are accepted.

Add the validation to your security filter chain:

@Bean
@Throws(Exception::class)
fun securityFilterChain(http: HttpSecurity): SecurityFilterChain =
    http
        .httpBasic { it.disable() }
        .formLogin { it.disable() }
        .csrf { it.disable() }
        .authorizeHttpRequests {
            it.requestMatchers("/api/fetchDocuments").hasAuthority("SCOPE_read:documents")

            it.anyRequest().authenticated()
        }
        .oauth2ResourceServer {
            it.jwt { jwt -> 
                jwt.jwtAuthenticationConverter(jwtAuthenticationConverter())
                jwt.decoder(jwtDecoder())         // Add custom JwtDecoder                                                              
            }
        }          
        .sessionManagement { it.sessionCreationPolicy(SessionCreationPolicy.STATELESS) }
        .build()

This allows the strict enforcement of the rules by the backend, never leaving it up to frontend logic to authorize or validate sensitive information.

Repository with the companion code for the tutorial

Go to GitHub

What’s Next?

Strong security requires fine-grained control and layered safeguards beyond basic authentication. Use short-lived tokens with clear refresh and revocation strategies to limit exposure and prevent compromised tokens from persisting. Avoid using JWTs for session storage, as this leads to token bloat, complicates revocation, and increases the risk of exposing sensitive data. Instead, keep JWTs focused on authentication and authorization claims, and enforce validation of issuer, audience, signature, and expiry to ensure tokens are trustworthy and intended for your application.

Ultimately, securing Spring Boot APIs with OAuth2 and JWT depends on careful design, explicit configuration, and a clear understanding of how tokens, scopes, and identities are validated and enforced. Kotlin complements this by promoting null safety, immutability, and concise configuration, helping reduce misconfigurations and overlooked edge cases.

KotlinLLM is now public. It’s a research prototype for delegating runtime logic to an LLM from Kotlin code. Instead of calling an LLM on every request or running a separate agent, you can write an explicit Kotlin call. Its body is generated Kotlin source code, and that code is updated as your application hits new runtime scenarios.

👉 Check it out 

👉 KotlinConf 2026 talk

What is KotlinLLM?

KotlinLLM is an IntelliJ IDEA plugin for Kotlin/JVM projects. It adds a language feature we call Smart macros. A Smart macro is a regular Kotlin function call whose body is generated Kotlin code. The public API has the following two Smart macros:

• asLlm<F, T>(from, hint) converts an input of type F into a typed value T (data class, enum, list, or primitive). Use it to parse unstructured or semi-structured data into typed Kotlin values at runtime.
• mockLlm<T>() generates a stateful implementation of an interface T. Its behavior depends on which methods are called on it, so it works as a test double that you don’t have to write by hand.

// One level of abstraction higher: describe intent, let KotlinLLM fill in the logic.
val issuesApiUrl: String = asLlm(repoInput, hint = "GitHub API URL: get all issues, including closed")
val issues: List<Issue> = asLlm(response, hint = "Return all beginner-friendly issues for this repository")

The behavior comes from actual runtime usage rather than being fully specified before the program runs. The call site stays compact and explicit: a clear, keyword-like API over generated code.

The problem it solves

In software engineering, LLMs are used during development, for code completion, code generation, and program comprehension. Using an LLM at the runtime of a compiled application is less common, and the existing options have clear trade-offs:

• Direct runtime delegation (calling the model on every invocation) is slow, non-deterministic, and costly. It also makes the application depend on an LLM service at runtime.
• External agent workflows keep the generated logic outside the codebase, where it’s harder to review, test, and ship.
• Most prior work (e.g. byLLM, nightjar, Healer) targets interpreted languages like Python, not a compiled, statically typed language like Kotlin.

KotlinLLM is built around three properties:

• Explicit – the call site shows that a feature is LLM-backed, so it’s visible in code review.
• Persistent – generated behavior is saved as an ordinary Kotlin source, not kept only in the runtime session. It can be committed, reviewed, tested, and distributed like any other code.
• Portable – once generated, the code runs as plain Kotlin without the plugin. For scenarios that are already covered, there’s no further LLM call, so no added latency or cost, and the result is reproducible.

Does it actually work?

We tested the approach on two Kotlin/JVM projects:

• An adapted Spring Petclinic Kotlin – 18 asLlm call sites, 24/24 application scenarios completed after Smart macro evolution, with a 100% hot-reload success rate and compilation/redefinition adding ~1% of total runtime overhead.
• A synthetic “GitHub Beginner Issue Radar” – parsing real GitHub issue data across 20 repositories (30k+ issues), reaching ~0.89 recall on ground-truth beginner labels.

These results show that persistent runtime evolution for compiled Kotlin is feasible. The evaluation also documents the current limits.

We’re making it public 

KotlinLLM is open source under the Apache License 2.0. The repository contains:

• The IntelliJ plugin prototype and the stable Smart macro API.
• Runnable example projects (GitHub Issue Radar, an adapted Petclinic), including committed generated sources, so you can inspect what the LLM produced and run it as ordinary Kotlin.
• The KotlinConf2026 talk recording and the theoretical write-up with the full design rationale and evaluation.

Try it and tell us what you think 

KotlinLLM is a research prototype, so feedback is useful at this stage. A few ways to help:

• Start and explore the repo
• Try it on your own Kotlin/JVM project. Add the KotlinLLM.kt API file, launch with the Run with KotlinLLM executor, and let the Smart macros evolve. Setup steps are in the README. 
• Open issues for anything you run into: rough edges, unexpected LLM behavior, missing cases, or behavior you’d expect to be different.
• Send PRs with use cases. Real scenarios where asLlm/mockLlm work well – or break – are the most useful. New examples, target types, and agent tools are all welcome.

If you find a place where runtime logic delegation fits your code, open an issue. If you build something with it, send a PR.