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.

🎉 Kotlin turns 15! 🎉

For 15 years, you’ve helped shape Kotlin into the language it is today. Whether you’ve built apps, contributed to the ecosystem, taught others, or simply chosen Kotlin for your next project – thank you for being part of the journey.

Today, we’re celebrating Kotlin and the people who have made its journey possible. Explore special ways to celebrate Kotlin’s 15th birthday.

Leave a birthday wish for Kotlin

Create a digital birthday postcard with a wish or prediction for Kotlin’s next chapter. You can also upload your own photo to personalize the postcard.

Share your postcard with the Kotlin community and add your message to Kotlin’s 15th birthday celebration.

More ways to celebrate

Explore the Kotlin Effect beyond the code:

• Watch familiar Kotlin ideas come to life.
• Battle friction in a browser game.
• Keep learning with free access to select Kotlin courses on Hyperskill until September 9, 2026.

Thank you for being part of Kotlin’s journey

Fifteen years is an incredible milestone – made possible by everyone who has built with Kotlin, contributed to its ecosystem, shared knowledge, and supported one another along the way.

There are still more ideas to explore, more friction to remove, and many more things to build together.

Happy 15th birthday, Kotlin! 💜

Bringing Kodee to life wasn’t just a design challenge; it was a deeply collaborative effort by the Kotlin Marketing team, together with the Design and Strategic Research teams at JetBrains. The project’s goal was to create a mascot that truly resonated with the developer community. To do that, Strategic Research team leaned into a structured approach: gathering feedback through surveys, analyzing user sentiment, and facilitating a focus group to uncover the values and traits developers wanted to see. 

What follows is a behind-the-scenes look at how thoughtful research and creative iteration turned a simple idea into a beloved mascot.

First iteration of the Kotlin mascot

The mascot project was initiated and driven by the Kotlin Marketing team. The first design concept was the result of a thoughtful and detailed creative process in which Kotlin designers explored everything from the character’s shape and traits to its personality. The initial idea was to introduce a robot companion that subtly echoed the Kotlin logo – one that was helpful and approachable by nature, with a screen for a face. A reliable sidekick, always ready to lend a hand!

Preliminary sketches of the Kotlin mascot

Following its release, the character received mostly positive feedback. However, a few social media channels and online forums made it clear that the character hadn’t quite clicked with some members of the Kotlin community. This is where the Kotlin Marketing and Strategic Research teams partnered to validate the direction, and the researchers launched a mixed-method project to better understand community sentiment and shape the next iteration. Here, user feedback was indispensable. We started by scouring the internet to get a general idea of how the community felt about the mascot. This allowed us to make a few initial adjustments. At the same time, we realized we needed to dig deeper, so we moved on to the survey phase.

Survey feedback gathering

The Strategic Research team organized a feedback round to learn more about developers’ feelings about the character. We wanted to understand not just what people liked or disliked about the mascot, but also the reasons behind their sentiments. And the clock was ticking. With barely more than six months remaining before KotlinConf 2023, starting everything over from scratch (naming, production, etc.) wasn’t an option. Moreover, a lot of Kotlin users had already been vocal about liking the first variant, and it didn’t seem fair to totally replace a mascot that had already won the hearts of so many in the community.

We kicked things off with a survey. As researchers, we’re used to getting responses that only express broader emotions (“It’s bad”, “I don’t like it”, etc.), so this time we designed the questions to help guide responses toward more specific insights. The survey included a mix of:

• Projective questions like “What specific mascots of other brands do you consider ‘good’ or ‘bad’?” 
• Associative questions like “What comes to mind when you see this character?”
• Direct prompts like “What specifically don’t you like about this mascot, beyond just ‘I don’t like it’ or ‘It’s just bad’?” 

Feedback round 1: Results

We went into this knowing that opinions would differ. After all, you can’t please everyone. But our goal was merely to find overarching patterns in the feedback – and in this regard, we succeeded.

The most frequent concerns participants expressed were that the character:

• Didn’t feel charming or cute (which is typically expected from a mascot). 
• Came across as too plastic and robotic. 
• Lacked expression and personality. 
• Had some visual quirks that bothered people (for example, the proportions, the oversized eyes, a missing mouth, and the color palette).

Second iteration of the Kotlin mascot

Next, we asked the design team to create three quick concept drafts – no deep detailing, just enough to capture the overall impression while reflecting the feedback we’d gathered. 

Each of the three sketches went in a different direction. One leaned into a more human-like but still robotic style; another took a more animal-like approach; and the third refined the original concept, adjusting its features based on the feedback we’d received. 

The three mascot variants

Each draft gave us a fresh angle to consider, helping us explore what felt most relatable and visually appealing to the community.

After their changes, three things were clear: 

• The proportions felt more natural.
• The character’s personality had begun to shine through. It was no longer just a silent silhouette.
• Its emotions had become more expressive.

The designers also made sure the color palette would work well with a wide range of different backgrounds, making the mascot more versatile. The Kotlin team intended to use the character in a wide variety of ways, so it had to fit naturally into any digital and real-life context and had to align with the general Kotlin brand design guidelines.

Focus group feedback

We planned to present the drafts during a guided focus group session, which would give participants the chance to share deeper feedback and help us choose the most promising direction to take things in. The idea for this focus group came from one of the researchers’ backgrounds in urban anthropology and spatial development. A widely adopted approach in this field is participatory design, in which users of a space share their perspectives on how public areas should be shaped and experienced.

To keep the process productive, we carefully applied the principles of cognitive interviewing to uncover the implicit expectations and mental images of the participants. Some participants actually requested a preview of the drafts in advance, but we had to decline, so as to ensure we were getting a totally “fresh” reaction from every single session participant.

We kicked the session off by dividing everyone into smaller groups to ensure every voice could be heard. The first task was to define the core values, keywords, and associations the Kotlin mascot should reflect. What key traits did the participants identify? They said it should be friendly and supportive, a little mischievous, and clearly tech-savvy. Participants also emphasized that the character should feel helpful and be something they’d be proud to show off. 

To guide the evaluation process, we set up a Miro board where participants could assess each mascot variant against the criteria they had established earlier in the session. The board was structured to reflect the key traits – like friendliness, tech-savviness, and a touch of playfulness – and allowed each group to visually map how well each character draft aligned with those values.

This setup worked out as we expected: it made it easy to compare impressions across groups, highlight areas of consensus, and spot where a particular variant might fall short. Moreover, we visualized and mapped all the individual “mental images” of the character and managed to get all the participants to agree on those “personality traits”. This helped us gather structured, actionable feedback about the mascot’s appearance for the design team in a collaborative and engaging way. 

Miro board where participants evaluated mascot variants according to criteria they developed

In the end, the refined version of the original character came out on top. By modifying its features based on community feedback – adding warmth, personality, and visual balance – we managed to strike the right chord with participants. The design stayed true to the initial concept while evolving into a more relatable mascot.

And the winner is…

Kodee toy specifications

After that, designers spent some time refining the final version and aligning it with the feedback from the session. It took a few rounds to make sure everything was just right – from visual details to brand alignment. Once the design felt solid, Kotlin Marketing led the stakeholder approval process, aligning teams around the refined direction before moving into production.

Eventually, the mascot was officially approved and ready to meet the world. And then came the final piece of the puzzle: the mascot’s name. 

Naming the Kotlin community’s mascot

Naming the mascot turned out to be one of the most creative and surprisingly tricky parts of the process. We were looking for a name that felt tech-savvy and in line with Kotlin’s spirit, while also carrying a sense of warmth and approachability. Striking that balance wasn’t easy.

To generate new ideas, the mascot working group split back up into teams so that each team could have a brainstorming session and work on the problem from their own angle. The Strategic Research team even used ChatGPT (a fairly novel strategy in early 2023!) to refine the list of options and bring it more in line with the focus group feedback we’d collected. Meanwhile, the Kotlin Marketing team also consulted the Twitter community (now X), and the response was incredible: we received hundreds of thoughtful, fun, and clever suggestions. 

After much deliberation, the Kotlin team narrowed it down to a short list of appealing options. To avoid copyright clashes or intercultural confusion, we invited JetBrains Localization team and Copyeditor team to check how each option might be received among people from various cultural and linguistic backgrounds. After this analysis, we landed on three finalists: Kodee, Milo, and Lilo. Picking one was no small feat. Milo was nice, but had no obvious relation to Kotlin. One key reason it edged out Lilo was flexibility. In many languages, “Lilo” would call to mind a shade of purple or violet. But since the mascot’s look was bound to evolve over time, we thought it was best not to use a name that was tied to a physical trait. Ultimately, the Kotlin team landed on Kodee, a playful nod to coding that felt right at home in the Kotlin ecosystem. 

And just like that, Kodee was born – ready to meet the world, be animated in presentations, and featured on pins.

Multiple versions of Kodee

The response to the new version of Kodee was overwhelmingly positive. Developers loved the refreshed design and personality, and it quickly became a recognizable part of the Kotlin identity. 

Today, Kodee takes many forms, from expressive emojis and animated stickers to physical merchandise like plush toys. It’s not just a mascot anymore – it’s a friendly face that brings the Kotlin community together across platforms and events.

Different versions of Kodee, including plush, Lego, and life-sized forms

Recently, Kodee has started resonating beyond the developer community. Earlier this year, the character was presented at Pictoplasma in Berlin, one of the world’s leading conferences dedicated to character design, storytelling, and contemporary visual culture. Introducing Kodee to an audience of designers, illustrators, and character creators demonstrated that the mascot can connect with people not only as a product symbol, but also as an independent character with its own identity and story. For us, this was an exciting milestone in Kodee’s evolution and a reminder that well-crafted characters can build bridges between different creative communities.

Kodee’s story at Pictoplasma in Berlin, plush Kodee shown on the screen

Conclusion

Kodee’s journey from concept to community icon reflects a cross-functional effort by the Kotlin Marketing team in close collaboration with Design, Strategic Research, many other JetBrains teams, and the Kotlin community. What began as a simple idea for adding warmth and personality to the programming language evolved into a vibrant character shaped by feedback, creativity, and shared values. 

The greatest recognition for our mascot project came from the Kotlin community itself: Kodee was wholeheartedly adopted, creatively reinterpreted, and enthusiastically reproduced in countless ways, from digital artwork to handmade clay figures. It really became a character that Kotlin developers are proud to show off – one of the essential requirements for the mascot, as described by our focus group participants.

With its expressive design, tech-savvy charm, and playful spirit, Kodee now stands out as more than just a mascot: it’s a symbol of Kotlin’s inclusive and developer-friendly culture, ready to grow alongside the community it represents.

Kodee and its leading researcher, Olga Vorobeva

Many thanks to all teams involved:

Researchers: 
Leading researcher – Olga Vorobeva
Naming – Yanina Ledovaya, Sofia Kulikova
Focus group designers and facilitators – Olga Vorobeva, Yanina Ledovaya, Raisa Kanischeva, Evgenia Igolnikova, Sofia Kulikova

Designers:
Main designer / Kodee’s “mother” – Tina Prokhorova
Positions and situations of the characters – Arina Kovrizhkina
Preliminary 3D version and animation – Kirill Malich
Final 3D version – Alexey Salmin
Final animation – Alena Sulza, Anastasia Ibragimova

Kotlin team representatives:
VP of Product – Egor Tolstoy
Kotlin Marketing Team Lead – Ekaterina Volodko 
PMM – Maria Krishtal
PMM – Ksenia Shneyveys
And other Kotlin team members who were always eager to help, brainstorm, and give feedback.

We’re taking the first step in addressing that gap by releasing the Kotlin Benchmark, JetBrains’ official benchmark for evaluating AI coding agents on Kotlin software engineering tasks. Our goal is to give developers a credible, public way to assess how different agents perform on Kotlin and compare agent setups using tasks that are closer to day-to-day dev work.

Alongside the benchmark release, we’re publishing the benchmark assets on GitHub and launching the official leaderboard to track the evaluation results.

Explore the benchmark on GitHub

See the first results on the leaderboard

How the Kotlin Benchmark works

The first public iteration of the Kotlin Benchmark is based on the SWE-bench methodology and focuses on repository-level Kotlin software engineering tasks.

Kotlin already has strong model-focused evaluation assets, including Kotlin_HumanEval and Kotlin_QA, which help measure a model’s understanding of the language’s syntax and core concepts. The Kotlin Benchmark looks at a different layer: how well an AI coding agent can complete validated software engineering tasks in existing Kotlin projects.

The dataset features 105 engineering tasks sourced from active open-source repositories. Each task requires the AI agent to interpret a real issue description, navigate the project’s context, and generate a functional patch. Solutions are strictly verified in containerized environments, and a task is only marked as resolved when the generated solution passes the required test verification.

You can read more about our environment setup and data collection on the Methodology page.

First results

The first evaluations show that leading coding agents can complete a large share of the current Kotlin Benchmark tasks. These results reflect the first public iteration of the benchmark and do not yet include the most recent model releases. We are already working on the second iteration and will update the leaderboard as newer evaluations are added.

In this run, the top result came from Claude Code with Opus 4.7 xhigh, which resolved 90 of 105 tasks, an 85.71% resolution rate. JetBrains Junie with Opus 4.7 max (81.9%) and Codex with GPT 5.5 xhigh (81.9%) followed closely.

The full leaderboard is available on kotlinlang.org/benchmark, where you can compare agents and configurations in detail.

For teams evaluating coding agents, the benchmark provides a shared frame of reference for comparing setups on Kotlin tasks instead of relying only on vendor claims. The scores are intended as a signal, not a guarantee for every codebase. Real-world results depend on your architecture, internal APIs, coding standards, tooling, and validation process.

What’s next

We value an open approach, which is why we built this benchmark on the open-source Multi-SWE-bench infrastructure and made all datasets and test harnesses publicly available.

We treat benchmarks as a continuous quality measurement pipeline. Moving forward, we plan to expand the framework in these areas:

• Broader Kotlin ecosystem coverage: We want the task mix to better reflect how Kotlin is used in practice, including areas such as Android and Kotlin Multiplatform, and cover a wider range of task difficulty levels.
• More evaluation metrics: Passing tests is a useful correctness signal, but it is only one part of agent evaluation. Future iterations will look at cost, performance, maintainability, and code quality.
• More agents and model setups: We plan to evaluate more commercial agents, agent-model configurations, and open-weight models, so teams can compare a wider range of setups.

The benchmark is open, so you can inspect the tasks, compare results, and tell us which Kotlin scenarios we should cover next.

From creating educational content and building engaging online communities to organizing events, fostering connections, and driving positive societal impact, the Golden Kodee Awards shine a spotlight on the many ways people contribute to Kotlin. Open to active members of the Kotlin community who have made notable contributions over the past two years, the awards honor those who share knowledge, mentor others, and inspire developers around the world.

Getting to know the Golden Kodee winners

This year’s winners represent the diversity and strength of the Kotlin community: Matheus Leandro Ferreira (Education), Jaewoong Eum (Online Presence), Nicole Terc (Creativity), Eeva-Jonna Panula (Positive Societal Impact), and Yinlong Liu (In-Person Presence).

In the days following KotlinConf, we caught up with each of the winners to learn more about their projects and initiatives.

Which of your projects do you think stood out the most in helping you win a Golden Kodee?

Matheus Leandro Ferreira: Since my category is focused on education, I believe my experience teaching at the university and working with Kotlin over the years may have been an important factor. I’ve been teaching programming and mobile development with Kotlin for quite a long time, while also creating educational content for the developer community outside the classroom.

Jaewoong Eum: I’ve contributed to the open-source community for over nine years, so I believe most of my open-source projects have helped me win this award, such as Balloon, landscapist, and compose-stability-analyzer. But also, I’ve written lots of technical content on my personal blog, newsletters, and recently, I’ve published several books, so all these activities and projects helped me to win this award.

Nicole Terc: Composable Sheep talks.

Eeva-Jonna Panula: I think there might not have been one project that stood out the most; it was probably the whole body of work I’ve done in content creation on accessibility, disability, and inclusion.

Yinlong Liu

As one of the earliest developers to adopt KMP in China, I established a KMP WeChat community to connect developers, and I have been glad to see an increasing number of companies successfully adopt KMP.

What did winning a Golden Kodee feel like?

Matheus: It meant a lot to me. In many ways, it felt like a validation of my long journey in education. I’ve been working professionally in technology for more than 20 years and teaching for 13 years. It’s honestly very difficult to describe what I felt when I won. It was incredibly gratifying. Without a doubt, it was the biggest award of my career.

Jaewoong: I’m truly honored to have received the Golden Kodee Award. I’ve received so much appreciation and encouragement from the community about this win, and it has motivated me. I felt so many positive vibes from everyone throughout the experience. To be honest, even though I’ve been consistently contributing to the community over the years, I don’t often get an opportunity to directly hear words of appreciation from people. But through this award, I was able to feel that gratitude in a very real way, and it genuinely made my heart beat faster. It reminded me again why I love being part of this community and why I want to keep contributing.

Nicole: It was really surprising at first, then I felt really humbled and seen. We don’t get enough awards in the community, so having all the hard work recognized was a welcome change. 

Eeva-Jonna: Awesome. The reason I do what I do is that I enjoy it and want to share knowledge and help developers create more inclusive apps. In a sense, it’s a niche topic that doesn’t get much attention compared to many other topics, so being recognized with a Golden Kodee truly meant a lot.​

Yinlong: It feels truly joyful, honorable, and exciting. Having been a practitioner and advocate of KMP for about six years, I have integrated Kotlin and KMP into my work, life, and even my faith. I have grown my own influence through KMP. I also have a special connection to the color purple: it is not only the theme color of Kotlin but also the color of my favorite NBA team, the LA Lakers.

Jaewoong Eum

I’ve received so much appreciation and encouragement from the community about this win, and it has motivated me.

Can you take us back to the beginning: How did you first discover Kotlin? What initially attracted you to it, and what made you stick with it?

Matheus: I started using Kotlin practically from the moment it was introduced for mobile development. At that time, all of my company’s applications were built with Java. Gradually, we migrated all of them to Kotlin, without exception. I also updated the curriculum at the university where I teach, replacing the applications and teaching materials that were previously developed in Java with Kotlin. The language brings a huge range of opportunities. It’s less verbose, constantly evolving, and keeps up with the trends of the professional market. These days, using Kotlin is essential.

Jaewoong: The positive cycle of community keeps going around. Back in 2018, I first discovered Kotlin when well-known people in the open-source community began sharing their experiences using it for Android development. I heard great feedback about its impact on developer productivity, which led me to try it for the first time. At the time, I started using Kotlin because of its Java interoperability and various convenient features. But the more I used it, the more I began to see its true value. Today, Kotlin is undoubtedly my top-choice programming language.

Nicole: My story is similar to many: I was a Java Android developer and adopted it when it got announced as an official Android language. We had an early adopter on our team at the time, so the transition was not hard at all. I stuck with it because of all the goodies it brought into Android: less verbosity, null safety, no use of semicolons, coroutines, etc.

Eeva-Jonna: I was a web developer at a company that didn’t have much web development work in Finland at the time. I was also an accessibility specialist who had just conducted accessibility testing on our Android app, realizing that the situation wasn’t optimal. I spoke with the Android developers and realized no one would have time to fix the issues I found, so I decided to do it myself. This was pretty much what got me started with Kotlin – becoming an Android developer. As mentioned, I come from a JavaScript (okay, okay, TypeScript) background. When I started working on the Android app and Kotlin, I had these constant moments where I realized that a language can actually support so many things, instead of forcing you to build the functions from scratch every single time.

Yinlong: We started around 2020 with Kotlin 1.3.72/1.4.0. KMP’s option for shared business logic code is what initially attracted us. We have apps that cover the Android, Windows (Java-based), and iOS platforms, which require high performance and the handling of heavy business logic, all while having a team predominantly made up of Android developers. KMP perfectly matched our requirements for cross-platform technology. As it has become more stable and we’ve gained experience, we have been gradually expanding the scope of our KMP module.

Matheus Leandro Ferreira

The language brings a huge range of opportunities. It’s less verbose, constantly evolving, and keeps up with the trends of the professional market. These days, using Kotlin is essential.

What do you love most about working with Kotlin today?

Eeva-Jonna Panula

Being able to build once and distribute to different platforms is great, but what I especially enjoy is how KMP handles native implementations.

Matheus: My passion has always been backend development, so what I enjoy the most today is the combination of Kotlin with Spring Boot. It’s something truly fantastic. At the university, I teach the “Mobile Programming” course, and over time, I’ve also been enjoying working more and more with mobile frontend development.

Jaewoong: I first started using Kotlin because it was 100% compatible with the JVM ecosystem. Over time, it became my primary programming language. What I love most is that Kotlin has grown far beyond the JVM and Android. Today, it can be used actively across many multiplatform development scenarios, which makes it even more powerful and practical. Another thing I really appreciate about Kotlin is its ecosystem. The Kotlin Foundation is deeply committed to maintaining and growing the Kotlin ecosystem. Through initiatives like the Kotlin Evolution and Enhancement Process, they actively communicate with the community and listen closely to user feedback to improve the language. I think this is one of the biggest differences that sets Kotlin apart from many other language ecosystems. I’m also fascinated by the fact that Kotlin enables more advanced, low-level work through tools like Kotlin compiler plugins and KSP. These open the door for using the language at a much higher level, and they’re a big part of what makes Kotlin so compelling to me.

Nicole: Coroutines. The concurrency handling in Kotlin is pretty good.

Second place is KMP. I really appreciate the potential of porting Android apps to many other platforms.

Eeva-Jonna: From a language perspective, it’s the APIs and the way you can write code intuitively. Extension functions and collection APIs make my life so much easier, and even after years of happily being away from the JS world, I still appreciate these features every day. I also love working with Kotlin Multiplatform. Being able to build once and distribute to different platforms is great, but what I especially enjoy is how KMP handles native implementations. If there’s something I can’t do in Kotlin, I can just drop down to native code to get it done. That flexibility is really powerful.

Yinlong: I love ❤️ Kotlin. I just love everything about it.

What are you currently building or experimenting with in Kotlin?

Matheus: Currently, at the company, I’ve been exploring the backend side a lot with Ktor (and also Spring Boot with Kotlin). I’m building a REST API for our BI platform. The idea is to use Kotlin to improve performance, concurrency with Coroutines, and the overall expressiveness of the code compared to our Java legacy systems. The experience with the clean syntax and null safety in a microservices ecosystem has been fantastic. At the university, I’m focused on Kotlin Multiplatform (KMP). I’ve been experimenting with sharing business logic between Android and iOS in a project with my students. It’s amazing to see how much the technology has matured, allowing us to reuse almost the entire data and architecture layers without losing the native experience of each platform. I’m also keeping a close eye on Compose Multiplatform for UI development.

Jaewoong: I work on a variety of projects with Kotlin, like Compose Stability Analyzer, but the one I’ve been focusing on most recently is Compose HotSwan. HotSwan is a Hot Reload system for real Android devices. When you make changes in the editor, it applies those changes to the currently running app in under a second and immediately shows the result. Some parts are implemented at a lower level, including C++, but most of the system is written in Kotlin across multiple layers, including the Kotlin Compiler Plugin, Gradle plugin, and IntelliJ IDE plugin. Building a Hot Reload system itself requires a very complex workflow, but Kotlin’s broad language and tooling support made the process much more approachable. HotSwan is still in the early stages of adoption, and it is one of the first Hot Reload solutions for Android and Jetpack Compose. Looking ahead, I see it becoming a next-generation mobile client development solution, especially when combined with AI to create a much faster UI development feedback loop.

Nicole: I’m officially working with Kotlin as a professional Android engineer. In my personal time, I’m building a private boardgame-related app and playing with new ideas with my Filament project.

Eeva-Jonna: I’m building an app with Kotlin Multiplatform (currently for Android and iOS). It’s a planner app for women and anyone with cycles, combining cycle tracking, calendars, notes, tasks, and more into one app. Currently, we’re collecting waitlisters and have started testing rounds. I’ve enjoyed building the app with Kotlin Multiplatform. Everything is mostly written in Kotlin, but some things have required a native implementation, which has been easy to implement.

Yinlong: Nothing at the moment.

What advice would you give to developers who want to become more active in the Kotlin community?

Nicole Terc

In my opinion, the point of participating in a community should be to share and grow together, not to be famous.

Matheus: The best advice I could give is: learn in public. You don’t need to be an expert in the ecosystem to contribute. If you spent two hours struggling to configure Coroutines or to get a Kotlin Multiplatform (KMP) project running and finally figured it out, document it. Write a short article on Dev.to, make a LinkedIn post, or create a GitHub repository explaining the solution. What may seem simple to you could be a lifesaver for another developer.

Jaewoong: The community is always open to everyone, but it can take time to truly understand what “community” means. Contributing to a community is not something you do because you expect something in return. It is more about sharing what you have learned, helping others who are facing similar challenges, and slowly becoming part of a positive cycle where everyone learns from each other. My advice is to start small. You don’t need to be a famous speaker or an experienced open-source maintainer from day one. You can write about something you just learned, answer a question, report an issue, improve documentation, or share a small Kotlin example that helped you. Over time, those small contributions build trust, relationships, and confidence. And most importantly, they remind you that the Kotlin community is not just about the language itself, but about the people who keep learning, building, and helping each other grow.

Nicole: Reach out to local meetups. Be proactive with socializing and sharing what you are doing without worrying about the clout. In my opinion, the point of participating in a community should be to share and grow together, not to be famous.

Eeva-Jonna: I would say that the most important thing is to start. Whatever it is you want to do, start doing it. If you want to do public speaking, meetups are usually looking for speakers, and many conferences support first-time speakers. If you want to start creating content, just start. You won’t get it perfect the first time anyway, so better start practicing sooner rather than later. Also, find people who can help you. Reach out to others who are doing what you want to do and ask if they can help. Sometimes the answer might be “no” because, e.g. they don’t have enough time, but many times you get a “yes” and some help. 

Yinlong: My advice is to use Kotlin to implement your ideas and actively communicate and share your findings with others.

Where are you keeping your Golden Kodee?

The stories of this year’s Golden Kodee winners show that there are many ways to make a meaningful impact on the Kotlin community. We hope their journeys and advice have inspired you as much as they have inspired us.

For many students, programming begins in the classroom, where a teacher introduces basic concepts for the first time. Having reached more than 25 million unique learners worldwide, BlueJ is one of the most widely used environments for beginners. Its visual class diagram, object bench, and direct object interaction help students see programs as systems of objects they can create, inspect, and command.

When learning to program, students increasingly need to read, evaluate, debug, and maintain code, including code generated by AI. BlueJ helps beginners build the mental models that let them understand and trust the programs they work with by making program behavior visible and interactive – they can create objects, call methods, and observe how state changes. With Kotlin support, they can do this with less boilerplate and fewer syntactic distractions.

Why Kotlin in BlueJ

Java has played a central role in introductory OOP for many years. It is explicit, structured, and familiar to educators. At the same time, many teachers know the cost of that explicitness: students often need to write quite a lot of boilerplate before they grasp the concept.

Kotlin keeps the object-oriented model visible and surfaces a few important design choices from the beginning:

• Concise syntax reduces the amount of code students need to read and write.
• Null safety makes the possibility of missing values explicit.
• val and var help students distinguish what can change from what cannot.
• JVM interoperability keeps Kotlin close to the Java ecosystem educators already know.

What you can do with Kotlin in BlueJ

This first release focuses on the core classroom workflow. You can create, edit, compile, and run Kotlin files; define classes with properties and methods; and create objects and call their methods through the familiar BlueJ interface, including class diagrams and the object bench. 

Teaching materials

To help educators get started, we’ve prepared an onboarding guide for teaching OOP with Kotlin in BlueJ.

It’s written for teachers who already know how to teach introductory OOP and want to understand how those concepts map to Kotlin. It includes explanations, examples, and projects for classroom use. Each unit comes with example projects and practice materials that can be opened directly in BlueJ.

Thank you to the BlueJ community

Early builds of Kotlin support in BlueJ were shared with educators in the BlueJ community, and their feedback helped shape the release. Teachers tested classroom examples, reported issues, and shared how they think about Kotlin in an objects-first environment. We are especially grateful to everyone who tried the early builds and helped us understand what matters most in real teaching practice.

Try Kotlin in BlueJ

If you teach with BlueJ, we’d love for you to try Kotlin and tell us how it goes.

We are looking forward to your questions and feedback from your own classroom. Write to us at education@kotlinlang.org, and visit the Kotlin for Education page to explore more resources and join the community of Kotlin educators.

Let’s teach Kotlin – good luck, and have fun!