Kotlin 2.5 previews companion blocks that compile to JVM statics

Serguey Asael Shinder01 October 2026, 07:072 min read

JetBrains has described a new experimental feature arriving in Kotlin 2.5.0: companion blocks and companion extensions. Both target members that belong to a class rather than to its instances, such as constants, utilities and factory methods, which Kotlin has so far expressed through companion objects.

A companion block looks almost the same as a companion object in source, but the compilation is different. On the JVM, its members are compiled as static members, closer to how other platforms treat type-level functions. A companion extension goes further: it declares a new type-level member on a class or interface the developer does not control, whether it comes from Kotlin or from Java and whether or not it has a companion object. The post's example adds a factory, companion fun Vector.unit(angle: Double), which is then called as Vector.unit(...).

The static compilation has a consequence for Kotlin Multiplatform: an expected companion-block member can now be actualised by a Java class that contains static members.

Both features are behind compiler flags. -Xcompanion-blocks enables blocks; -Xcompanion-blocks-and-extensions enables both. Using extensions makes the compiler emit pre-release binaries, so libraries that use them may not be consumed as dependencies until the feature becomes stable. Exposing companion blocks has no such restriction, although consumers still need the blocks flag. The design is described in a KEEP proposal.

JetBrains says there is no need to migrate. Companion objects remain fully supported and are still the only option when a companion must implement an interface, because they compile to a full class. Moving to a block is usually a matter of removing the object keyword, but dependent code must be recompiled and other ecosystem tools may not support blocks yet.

Why it matters

Static compilation removes the extra object that every companion has carried on the JVM and makes Java interop more natural. The pre-release binary rule means library authors should wait before using extensions in public APIs.