Ktor 3.4.3

https://github.com/ktorio/ktor/releases/tag/3.4.3

Detekt v2.0.0-alpha.3

https://github.com/detekt/detekt/releases/tag/v2.0.0-alpha.3

Stacks for Kotlin: Design Notes and Local Lifetimes for Kotlin: Design Notes

local parameters let the compiler prove a value won't escape a call. That single primitive unlocks: non-local return without inline, stack-allocated vararg, view types that can't outlive their source, builders that statically prevent receiver leaks.

Then Stacks build on it to make suspend just one of many possible suspension mechanisms. Each coroutine-like API (`Sequence`, Flow, deeply-recursive) gets its own typed continuation instead of fighting over the single global one. @RestrictsSuspension becomes obsolete. KT-3480 fixes itself. DeepRecursiveFunction shrinks 9×.

KEEP: Rich Errors - design details

Amper -> https://kotlin-toolchain.org/

Mellum2

Now open source on Hugging Face, Mellum2 is a 12B-parameter LLM built for:

• Routing and orchestration
• RAG pipelines
• Sub-agents
• Natural language and coding tasks

Powered by a new mixture-of-experts (MoE) architecture and optimized for ultra-low-latency inference.

Kotlin Toolchain 0.11: The Next Step for Amper

Released with a lot of new features and fixes

Kotlin 2.4.20-Beta1

https://github.com/JetBrains/kotlin/releases/tag/v2.4.20-Beta1

Major changes:

1. Context parameters going Stable. Explicit context arguments move to Stable — the headline of the release. KT-86089

2. Companion blocks & extensions. A new language capability landing across the whole toolchain: resolution, reflection (call/callBy), light classes, REPL/scripts, metadata. Enable it with the new (off-by-default) flag -Xcompanion-blocks-and-extensions. KT-84289 KT-85187

3. Native: incremental compilation on by default. K/N builds are finally faster out of the box. KT-86657

4. when via invokedynamic on JVM 21+ by default. More compact bytecode, fewer synthetic classes. KT-78079

5. PowerAssert heading to initial release. Runtime ABI stabilized, runtime dependency added automatically. KT-86170 KT-85250

6. Lombok-style logging on Kotlin classes: @Slf4j, @Log4j2, @JBossLog, @Flogger, @CommonsLog, @XSlf4j, plus @Log and @ToString. KT-81622 KT-85762

7. Collection literals moving forward. Under -Xcollection-literals: type inference in delegate expressions, support in annotations, of operator via companion block. KT-84295

8. Name-based destructuring. Stabilization of the only-syntax variant (targeting 2.5). KT-86201

9. Kotlin/JS catches up. ES2015 syntax in the js() function, KDoc export to .d.ts, @JsExport for annotation classes. KT-21626 KT-56493

10. Stdlib. Common atomic types and a new StackTraceRecoverable interface. KT-62423 KT-86595

Bonus: official deprecation of the K1 compiler has begun (KT-75372), and experimental language version 2.6 was added (KT-85667).

Kotlin 2.4.10-RC

https://github.com/JetBrains/kotlin/releases/tag/v2.4.10-RC

As usual, a bug-fix release – but there's one interesting change I noticed:

Since the Kotlin Toolchain uses kotlin as its command name, the current kotlin command (which is the compiler) is being renamed to kotlinr. 2.4.10 is the first release that ships both: kotlin and kotlinr.
The package itself (e.g. brew install kotlin, sdk install kotlin) will be renamed to kotlinc. So the future end state for the ecosystem:

sdk install kotlin # install kotlin toolchain, command: kotlin
sdk install kotlinc # install kotlin compiler, command: kotlinr

A kotlinc package but a kotlinr executable – confusing, right?

Some updates to new features timelines:

KEEP-0449: Companion extensions and blocks - experimental 2.5.0, stable 2.6.0 (preliminary)
KEEP-0462: Rich Errors, aka Error Union Types - experimental 2.5.0
KEEP-0450: Typed Delegate Access - experimental 2.5.20

Kotlin 2.4.10-RC2

https://github.com/JetBrains/kotlin/releases/tag/v2.4.10-RC2

Kotlin 2.4.10 has been released 🎉️️️️️️

https://github.com/JetBrains/kotlin/releases/tag/v2.4.10

What's new https://telegram.me/TheDailyKotlin/621

KEEP-0466: Expect with fallback

TL;DR
• Expect declarations may define a fallback implementation.
• The fallback implementation implementation is used when there's no corresponding actual declaration in a platform for an expect.
• Fallback implementation must define the declaration completely ("all-or-nothing" rule); leaving some parts unspecified is not allowed.

Kotlin 2.4.20-Beta2

https://github.com/JetBrains/kotlin/releases/tag/v2.4.20-Beta2

Major changes:

1. Swift Export: cross-language inheritance is here. The umbrella ticket for cross-language subtyping is closed: Swift types can subclass Kotlin classes — with supercalls, properties, async members, default interface methods. Sealed classes are supported too. KT-66888 KT-80000

2. Full value classes (KEEP-0453) take shape. Short-form name-based destructuring, abstract value classes, and the old @JvmInline multi-field prototype is removed. Still experimental: builds using them are deliberately poisoned. KT-84904 KT-86018 KT-86849

3. KMP: fragment-aware incremental compilation on JVM. The OSIP-75 push: commonMain will no longer accidentally see jvmMain declarations during IC, removing the need for the non-incremental fallback. Landed behind a feature flag while the rollout continues. KT-87490 KT-86410

4. Wasm on all fronts. Three compilation modes (monolith / multimodule open & closed world), wasmtime as a WASI runtime in Gradle, index range checks on by default, and a prototype of suspend functions on top of the stack-switching proposal. KT-86919 KT-86633 KT-73452 KT-76207

5. Native: release builds with compiler caches. First step towards fast release builds: opt-in caches + module-local optimizations instead of full LTO. KT-80373

6. Browser tests move to Playwright. New JS browser-test DSL: webpack + mocha + playwright, configurable dev-server URL and custom browser executables. KT-86260 KT-87484

7. kotlin-reflect stops slowing you down. typeOf() and friends no longer degrade when kotlin-reflect appears on the classpath — the thing that used to bite Ktor and kotlinx.serialization. KT-73657

8. stdlib & kotlin-test. allDistinct()/allDistinctBy{} (a 2019 request!), JUnit5-style lazy assertion messages, and the new @EqualityBound annotation. KT-30270 KT-31305 KT-86766

9. Xcode 27 support, new floors. Minimum deployment targets bump: iOS 15, macOS 12, watchOS 9 (armv7k is gone), tvOS 15. KT-87187

10. The great cleanup continues. Legacy JS backend sources are deleted, and @K1Deprecation now covers all public declarations of K1 modules. KT-70223 KT-86046

Bonus: the Eager Lambda Analysis language features got postponed (Unit conversions on arbitrary expressions — indefinitely, KT-86877 KT-87439), and OPERATOR_RENAMED_ON_IMPORT was downgraded from error to warning (KT-83880).

KotlinLLM: LLM-generated bodies, committed as Kotlin source

JetBrains Research has open-sourced KotlinLLM under Apache 2.0 — a research prototype for delegating runtime logic to an LLM from Kotlin code, without keeping the model in the request path.

The unit is a Smart macro: an ordinary Kotlin call whose body is generated source code. Two are exposed — asLlm<F, T>(from, hint) turns unstructured input into typed Kotlin values, and mockLlm<T>() builds stateful interface implementations to use as test doubles.

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 argument against the obvious alternative is stated plainly: calling the model on every invocation is slow, non-deterministic and costly, and it makes the application depend on an LLM service at runtime. So KotlinLLM commits to three properties instead. The call site is explicit, so an LLM-backed feature is visible in review. The behaviour is persistent — saved as ordinary Kotlin source under com.jetbrains.kotlinllm.generated, so it can be committed, reviewed, tested and shipped like any other code. And it is portable: once generated, the code runs as plain Kotlin without the plugin, with no extra latency or cost.

The evolution loop is the interesting part. The app runs under JDI with regenerate hooks registered as breakpoints. When the generated logic meets a scenario it cannot handle, it is required to fall through to a hook rather than silently return something wrong. Execution suspends, the plugin captures runtime values and type information from the frame, an LLM agent inspects the code, writes a narrow update into the generated source, compiles it, redefines the class in the running VM, and the original call is retried against the new implementation.

Two evaluations. Spring Petclinic Kotlin, adapted with 18 asLlm call sites: 24/24 application scenarios completed after Smart macro evolution, a 100% hot-reload success rate, and roughly 1% runtime overhead. A GitHub Beginner Issue Radar reached ~0.89 recall on ground-truth beginner labels across 30,000+ issues from 20 repositories.

The constraints are honest. Kotlin/JVM only, because the evolution loop depends on JVM class redefinition through JDI. IntelliJ IDEA 2025.2.x, JDK 21, an OpenAI key in .kotlinllm. Generated updates are deliberately narrow — the agent does not get to rewrite arbitrary project files.

It is a research prototype, not a production tool. But it inverts the usual pattern in a way worth thinking about: the model writes the function once, and the JVM runs it forever.

GitHub · KotlinConf 2026 talk · Recording · Write-up