What's new in Kotlin 2.2.0

Preview of context parameters

Context parameters allow functions and properties to declare dependencies that are implicitly available in the surrounding context.

With context parameters, you don't need to manually pass around values, such as services or dependencies, that are shared and rarely change across sets of function calls.

Context parameters replace an older experimental feature called context receivers. To migrate from context receivers to context parameters, you can use assisted support in IntelliJ IDEA, as described in the blog post.

The main difference is that context parameters are not introduced as receivers in the body of a function. As a result, you need to use the name of the context parameters to access their members, unlike with context receivers, where the context is implicitly available.

Context parameters in Kotlin represent a significant improvement in managing dependencies through simplified dependency injection, improved DSL design, and scoped operations. For more information, see the feature's KEEP.

Preview of context-sensitive resolution

Kotlin 2.2.0 introduces an implementation of context-sensitive resolution in preview.

Previously, you had to write the full name of enum entries or sealed class members, even when the type could be inferred from the context. For example:

Now, with context-sensitive resolution, you can omit the type name in contexts where the expected type is known:

The compiler uses this contextual type information to resolve the correct member. This information includes, among other things:

• The subject of a when expression

• An explicit return type

• A declared variable type

• Type checks (is) and casts (as)

• The known type of a sealed class hierarchy

• The declared type of a parameter

To try out context-sensitive resolution in your project, use the following compiler option in the command line:

Or add it to the compilerOptions {} block of your Gradle build file:

We plan to stabilize and improve this feature in future Kotlin releases and would appreciate your feedback on our issue tracker YouTrack.

Preview of features for annotation use-site targets

Kotlin 2.2.0 introduces a couple of features that make working with annotation use-site targets more convenient.

Support for nested type aliases

Previously, you could only declare type aliases at the top level of a Kotlin file. This meant that even internal or domain-specific type aliases had to live outside the class where they were used.

Starting from 2.2.0, you can define type aliases inside other declarations, as long as they don't capture type parameters from their outer class:

Nested type aliases have a few additional constraints, like not being able to mention type parameters. Check the documentation for the entire set of rules.

Nested type aliases allow for cleaner, more maintainable code by improving encapsulation, reducing package-level clutter, and simplifying internal implementations.

Stable features: guard conditions, non-local break and continue, and multi-dollar interpolation

In Kotlin 2.1.0, several new language features were introduced in preview. We're happy to announce that the following language features are now Stable in this release:

• Guard conditions in when with a subject

• Non-local break and continue

• Multi-dollar interpolation: improved handling of $ in string literals

See the full list of Kotlin language design features and proposals.

How to apply

The new compiler option has the following syntax:

• error: raises the specified warning to an error.

• warning: emits a warning and is enabled by default.

• disabled: completely suppresses the specified warning module-wide.

Keep in mind that you can only configure the severity level of warnings with the new compiler option.

Use cases

With the new solution, you can better fine-tune warning reporting in your project by combining general rules with specific ones. Choose your use case:

Leave feedback

The new compiler option is still Experimental. Please report any problems to our issue tracker, YouTrack.

Changes to default method generation for interface functions

Starting from Kotlin 2.2.0, functions declared in interfaces are compiled to JVM default methods unless configured otherwise. This change affects how Kotlin's interface functions with implementations are compiled to bytecode.

This behavior is controlled by the new stable compiler option -jvm-default, replacing the deprecated -Xjvm-default option.

You can control the behavior of the -jvm-default option using the following values:

• enable (default): generates default implementations in interfaces and includes bridge functions in subclasses and DefaultImpls classes. Use this mode to maintain binary compatibility with older Kotlin versions.

• no-compatibility: generates only default implementations in interfaces. This mode skips compatibility bridges and DefaultImpls classes, making it suitable for new code.

• disable: disables default implementations in interfaces. Only bridge functions and DefaultImpls classes are generated, matching the behavior before Kotlin 2.2.0.

To configure the -jvm-default compiler option, set the jvmDefault property in your Gradle Kotlin DSL:

Support for reading and writing annotations in Kotlin metadata

Previously, you had to read annotations from compiled JVM class files using reflection or bytecode analysis and manually match them to metadata entries based on signatures. This process was error-prone, especially for overloaded functions.

Now, in Kotlin 2.2.0, the Kotlin Metadata JVM library introduces support for reading annotations stored in Kotlin metadata.

To make annotations available in the metadata for your compiled files, add the following compiler option:

Alternatively, add it to the compilerOptions {} block of your Gradle build file:

With this option enabled, the Kotlin compiler writes annotations into metadata alongside the JVM bytecode, making them accessible to the kotlin-metadata-jvm library.

The library provides the following APIs for accessing annotations:

• KmClass.annotations

• KmFunction.annotations

• KmProperty.annotations

• KmConstructor.annotations

• KmPropertyAccessorAttributes.annotations

• KmValueParameter.annotations

• KmFunction.extensionReceiverAnnotations

• KmProperty.extensionReceiverAnnotations

• KmProperty.backingFieldAnnotations

• KmProperty.delegateFieldAnnotations

• KmEnumEntry.annotations

These APIs are Experimental. To opt in, use the @OptIn(ExperimentalAnnotationsInMetadata::class) annotation.

Here's an example of reading annotations from Kotlin metadata:

Improved Java interop with inline value classes

Kotlin 2.2.0 introduces a new experimental annotation: @JvmExposeBoxed. This annotation makes it easier to consume inline value classes from Java.

By default, Kotlin compiles inline value classes to use unboxed representations, which are more performant but often hard or even impossible to use from Java. For example:

In this case, because the class is unboxed, there is no constructor available for Java to call. There's also no way for Java to trigger the init block to ensure that number is positive.

When you annotate the class with @JvmExposeBoxed, Kotlin generates a public constructor that Java can call directly, ensuring that the init block also runs.

You can apply the @JvmExposeBoxed annotation at the class, constructor, or function level to gain fine-grained control over what's exposed to Java.

For example, in the following code, the extension function .timesTwoBoxed() is not accessible from Java:

To make it possible to create an instance of the MyInt class and call the .timesTwoBoxed() function from Java code, add the @JvmExposeBoxed annotation to both the class and the function:

With these annotations, the Kotlin compiler generates a Java-accessible constructor for the MyInt class. It also generates an overload for the extension function that uses the boxed form of the value class. As a result, the following Java code runs successfully:

If you don't want to annotate every part of the inline value classes that you want to expose, you can effectively apply the annotation to a whole module. To apply this behavior to a module, compile it with the -Xjvm-expose-boxed option. Compiling with this option has the same effect as if every declaration in the module had the @JvmExposeBoxed annotation.

This new annotation does not change how Kotlin compiles or uses value classes internally, and all existing compiled code remains valid. It simply adds new capabilities to improve Java interoperability. The performance of Kotlin code using value classes is not impacted.

The @JvmExposeBoxed annotation is useful for library authors who want to expose boxed variants of member functions and receive boxed return types. It eliminates the need to choose between an inline value class (efficient but Kotlin-only) and a data class (Java-compatible but always boxed).

For a more detailed explanation of how the @JvmExposedBoxed annotation works and the problems it solves, see this KEEP proposal.

Improved support for annotating JVM records

Kotlin has supported JVM records since Kotlin 1.5.0. Now, Kotlin 2.2.0 improves how Kotlin handles annotations on record components, particularly in relation to Java's RECORD_COMPONENT target.

Firstly, if you want to use a RECORD_COMPONENT as an annotation target, you need to manually add annotations for Kotlin (@Target) and Java. This is because Kotlin's @Target annotation doesn't support RECORD_COMPONENT. For example:

Maintaining both lists manually can be error-prone, so Kotlin 2.2.0 introduces a compiler warning if the Kotlin and Java targets don't match. For instance, if you omit ElementType.CLASS in the Java target list, the compiler reports:

Secondly, Kotlin's behavior differs from Java when it comes to propagating annotations in records. In Java, annotations on a record component automatically apply to the backing field, getter, and constructor parameter. Kotlin doesn't do this by default, but you can now replicate the behavior using the @all: use-site target.

For example:

When you use @JvmRecord with @all:, Kotlin now:

• Propagates the annotation to the property, backing field, constructor parameter, and getter.

• Applies the annotation to the record component, as well, if the annotation supports Java's RECORD_COMPONENT.

Per-object memory allocation

Kotlin/Native's memory allocator can now reserve memory on a per-object basis. In some cases, it may help you satisfy strict memory limitations or reduce memory consumption on the application's startup.

The new feature is designed to replace the -Xallocator=std compiler option, which enabled the system memory allocator instead of the default one. Now, you can disable buffering (paging of allocations) without switching memory allocators.

The feature is currently Experimental. To enable it, set the following option in your gradle.properties file:

Please report any problems to our issue tracker, YouTrack.

Support for Latin-1 encoded strings at runtime

Kotlin now supports Latin-1-encoded strings, similarly to the JVM. This should help reduce the application's binary size and adjust memory consumption.

By default, strings in Kotlin are stored using UTF-16 encoding, where each character is represented by two bytes. In some cases, this leads to strings taking up twice as much space in the binary compared to the source code, and reading data from a simple ASCII file can take up twice as much memory as storing the file on disk.

In turn, Latin-1 (ISO 8859-1) encoding represents each of the first 256 Unicode characters with just one byte. With Latin-1 support enabled, strings are stored in Latin-1 encoding as long as all the characters fall within its range. Otherwise, the default UTF-16 encoding is used.

Improved tracking of memory consumption on Apple platforms

Starting with Kotlin 2.2.0, memory allocated by Kotlin code is now tagged. This can help you debug memory issues on Apple platforms.

When inspecting your application's high memory usage, you can now identify how much memory is reserved by Kotlin code. Kotlin's share is tagged with an identifier and can be tracked through tools like VM Tracker in Xcode Instruments.

This feature is enabled by default but is available only in the Kotlin/Native default memory allocator when all the following conditions are met:

• Tagging enabled. The memory should be tagged with a valid identifier. Apple recommends numbers between 240 and 255; the default value is 246.

  If you set up the kotlin.native.binary.mmapTag=0 Gradle property, tagging is disabled.

• Allocation with mmap. The allocator should use the mmap system call to map files into memory.

  If you set up the kotlin.native.binary.disableMmap=true Gradle property, the default allocator uses malloc instead of mmap.

• Paging enabled. Paging of allocations (buffering) should be enabled.

  If you set up the kotlin.native.binary.pagedAllocator=false Gradle property, the memory is reserved on a per-object basis instead.

For more information on memory consumption in Kotlin, see the documentation.

LLVM update from 16 to 19

In Kotlin 2.2.0, we updated LLVM from version 16 to 19. The new version includes performance improvements, bug fixes, and security updates.

This update shouldn't affect your code, but if you encounter any issues, please report them to our issue tracker.

Windows 7 target deprecated

Starting with Kotlin 2.2.0, the minimal supported Windows version has been raised from Windows 7 to Windows 10. Since Microsoft ended support for Windows 7 in January 2025, we also decided to deprecate this legacy target.

For more information, see Kotlin/Native target support.

Build infrastructure for Wasm target separated from JavaScript target

Before, the wasmJs target shared the same infrastructure as the js target. As a result, both targets were hosted in the same directory (build/js) and used the same NPM tasks and configurations.

Now, the wasmJs target has its own infrastructure separate from the js target. This allows Wasm tasks and types to be distinct from JavaScript ones, enabling independent configuration.

Additionally, Wasm-related project files and NPM dependencies are now stored in a separate build/wasm directory.

New NPM-related tasks have been introduced for Wasm, while existing JavaScript tasks are now dedicated only to JavaScript:

Similarly, new Wasm-specific declarations have been added:

You can now work with the Wasm target independently of the JavaScript target, which simplifies the configuration process.

This change is enabled by default and requires no additional setup.

Per-project Binaryen configuration

The Binaryen tool, used in Kotlin/Wasm to optimize production builds, was previously configured once in the root project.

Now, you can configure the Binaryen tool per project or module. This change aligns with Gradle's best practices and ensures better support for features like project isolation, improving build performance and reliability in complex builds.

Additionally, you can now configure different versions of Binaryen for different modules, if needed.

This feature is enabled by default. However, if you have a custom configuration of Binaryen, you now need to apply it per project, rather than only in the root project.

Fix for copy() in @JsPlainObject interfaces

Kotlin/JS has an experimental plugin called js-plain-objects, which introduced a copy() function for interfaces annotated with @JsPlainObject. You can use the copy() function to manipulate objects.

However, the initial implementation of copy() was not compatible with inheritance, and this caused issues when a @JsPlainObject interface extended other interfaces.

To avoid limitations on plain objects, the copy() function has been moved from the object itself to its companion object:

This change resolves conflicts in the inheritance hierarchy and eliminates ambiguity. It is enabled by default starting from Kotlin 2.2.0.

Support for type aliases in files with @JsModule annotation

Previously, files annotated with @JsModule to import declarations from JavaScript modules were restricted to external declarations only. This meant that you couldn't declare a typealias in such files.

Starting with Kotlin 2.2.0, you can declare type aliases inside files marked with @JsModule:

This change reduces an aspect of Kotlin/JS interoperability limitations, and more improvements are planned for future releases.

Support for type aliases in files with @JsModule is enabled by default.

Support for @JsExport in multiplatform expect declarations

When working with the expect/actual mechanism in Kotlin Multiplatform projects, it was not possible to use the @JsExport annotation for expect declarations in common code.

Starting with this release, you can apply @JsExport directly to expect declarations:

You must also annotate with @JsExport the corresponding actual implementation in the JavaScript source set, and it has to use only exportable types.

This fix allows shared code defined in commonMain to be correctly exported to JavaScript. You can now expose your multiplatform code to JavaScript consumers without having to use manual workarounds.

This change is enabled by default.

Ability to use @JsExport with the Promise<Unit> type

Previously, when you tried to export a function returning the Promise<Unit> type with the @JsExport annotation, the Kotlin compiler produced an error.

While return types like Promise<Int> worked correctly, using Promise<Unit> triggered a "non-exportable type" warning, even though it correctly mapped to Promise<void> in TypeScript.

This restriction has been removed. Now, the following code compiles without error:

This change removes an unnecessary restriction in the Kotlin/JS interop model. This fix is enabled by default.

Binary compatibility validation included in Kotlin Gradle plugin

To make it easier to check for binary compatibility between library versions, we're experimenting with moving the functionality of the binary compatibility validator into the Kotlin Gradle plugin (KGP). You can try it out in toy projects, but we don't recommend using it in production yet.

The original binary compatibility validator continues to be maintained during this experimental phase.

Kotlin libraries can use one of two binary formats: JVM class files or klib. Since these formats aren't compatible, the KGP works with each of them separately.

To enable the binary compatibility validation feature set, add the following to the kotlin{} block in your build.gradle.kts file:

If your project has multiple modules where you want to check for binary compatibility, configure the feature in each module separately. Each module can have its own custom configuration.

Once enabled, run the checkLegacyAbi Gradle task to check for binary compatibility issues. You can run the task in IntelliJ IDEA or from the command line in your project directory:

This task generates an application binary interface (ABI) dump from the current code as a UTF-8 text file. The task then compares the new dump with the one from the previous release. If the task finds any differences, it reports them as errors. After reviewing the errors, if you decide the changes are acceptable, you can update the reference ABI dump by running the updateLegacyAbi Gradle task.

Support for rich output in console for Kotlin Gradle plugin

In Kotlin 2.2.0, we support color and other rich output in the console during the Gradle build process, making it easier to read and understand the reported diagnostics.

Rich output is available in supported terminal emulators for Linux and macOS, and we're working on adding support for Windows.

This feature is enabled by default, but if you want to override it, add the following Gradle property to your gradle.properties file:

For more information about this property and its options, see Gradle's documentation on Customizing log format.

Integration of Problems API within KGP diagnostics

Previously, the Kotlin Gradle Plugin (KGP) was only able to report diagnostics such as warnings and errors as plain text output to the console or logs.

Starting with 2.2.0, the KGP introduces an additional reporting mechanism: it now uses Gradle's Problems API, a standardized way to report rich, structured problem information during the build process.

The KGP diagnostics are now easier to read and more consistently displayed across different interfaces, such as the Gradle CLI and IntelliJ IDEA.

This integration is enabled by default, starting with Gradle 8.6 or later. As the API is still evolving, use the most recent Gradle version to benefit from the latest improvements.

KGP compatibility with --warning-mode

The Kotlin Gradle Plugin (KGP) diagnostics reported issues using fixed severity levels, meaning Gradle's --warning-mode command-line option had no effect on how the KGP displayed errors.

Now, the KGP diagnostics are compatible with the --warning-mode option, providing more flexibility. For example, you can convert all warnings into errors or disable warnings entirely.

With this change, the KGP diagnostics adjust the output based on the selected warning mode:

• When you set --warning-mode=fail, diagnostics with Severity.Warning are now elevated to Severity.Error.

• When you set --warning-mode=none, diagnostics with Severity.Warning are not logged.

This behavior is enabled by default starting with 2.2.0.

To ignore the --warning-mode option, set the following Gradle property to your gradle.properties file:

Improved "in process" compiler execution strategy

The KGP supports three Kotlin compiler execution strategies. The "in process" strategy, which runs the compiler inside the Gradle daemon process, previously didn't support incremental compilation.

Now, using the BTA, the "in-process" strategy does support incremental compilation. To use it, add the following property to your gradle.properties file:

Flexibility to configure different compiler versions from Kotlin

Sometimes you might want to use a newer Kotlin compiler version in your code while keeping the KGP on an older one – for example, to try new language features while still working through build script deprecations. Or you might want to update the version of the KGP but keep an older Kotlin compiler version.

The BTA makes this possible. Here's how you can configure it in your build.gradle.kts file:

The BTA supports configuring the KGP and Kotlin compiler versions with the three previous major versions and one subsequent major version. So in KGP 2.2.0, Kotlin compiler versions 2.1.x, 2.0.x, and 1.9.25 are supported. KGP 2.2.0 is also compatible with future Kotlin compiler versions 2.2.x and 2.3.x.

However, keep in mind that using different compiler versions together with compiler plugins may lead to Kotlin compiler exceptions. The Kotlin team plans to address these kinds of problems in future releases.

Try out the BTA with these plugins and send us your feedback in the dedicated YouTrack tickets for the KGP and the Maven plugin.

Stable Base64 encoding and decoding

Kotlin 1.8.20 introduced Experimental support for Base64 encoding and decoding. In Kotlin 2.2.0, the Base64 API is now Stable and includes four encoding schemes, with the new Base64.Pem added in this release:

• Base64.Default uses the standard Base64 encoding scheme.

• Base64.UrlSafe uses the "URL and Filename safe" encoding scheme.

• Base64.Mime uses the MIME encoding scheme, inserting a line separator every 76 characters during encoding and skipping illegal characters during decoding.

• Base64.Pem encodes data like Base64.Mime but limits the line length to 64 characters.

You can use the Base64 API to encode binary data into a Base64 string and decode it back into bytes.

Here's an example:

On the JVM, use the .encodingWith() and .decodingWith() extension functions to encode and decode Base64 with input and output streams:

Stable Hexadecimal parsing and formatting with the HexFormat API

The HexFormat API introduced in Kotlin 1.9.0 is now Stable. You can use it to convert between numerical values and hexadecimal strings.

For example:

For more information, see New HexFormat class to format and parse hexadecimals.

Support for @Composable function references

The Compose compiler supports the declaration and usage of composable function references starting from the Kotlin 2.2.0 release:

Composable function references behave slightly differently from composable lambda objects at runtime. In particular, composable lambdas allow for finer control over skipping by extending the ComposableLambda class. Function references are expected to implement the KCallable interface, so the same optimization cannot be applied to them.

PausableComposition feature flag enabled by default

The PausableComposition feature flag is enabled by default starting from Kotlin 2.2.0. This flag adjusts the Compose compiler output for restartable functions, allowing runtime to force skipping behavior and therefore effectively pause composition by skipping each function. This allows heavy compositions to be split between frames, which will be used by prefetching in a future release.

To disable this feature flag, add the following to your Gradle configuration:

OptimizeNonSkippingGroups feature flag enabled by default

The OptimizeNonSkippingGroups feature flag is enabled by default starting from Kotlin 2.2.0. This optimization improves runtime performance by removing group calls generated for non-skipping composable functions. It should not result in any observable behavior changes at runtime.

If you encounter any issues, you can validate that this change causes the issue by disabling the feature flag. Please report any issues to the Jetpack Compose issue tracker.

To disable the OptimizeNonSkippingGroups flag, add the following to your Gradle configuration:

Deprecated feature flags

The StrongSkipping and IntrinsicRemember feature flags are now deprecated and will be removed in a future release. If you encounter any issues that make you disable these feature flags, please report them to the Jetpack Compose issue tracker.

Kotlin's documentation survey

We're looking for genuine feedback to make the Kotlin documentation better.

The survey takes around 15 minutes to complete, and your input will help shape the future of Kotlin docs.

Take the survey here.

New and revamped tutorials

• Kotlin intermediate tour – Take your understanding of Kotlin to the next level. Learn when to use extension functions, interfaces, classes, and more.

• Build a Kotlin app that uses Spring AI – Learn how to create a Kotlin app that answers questions using OpenAI and a vector database.

• Create a Spring Boot project with Kotlin – Learn how to create a Spring Boot project with Gradle using IntelliJ IDEA's New Project wizard.

• Mapping Kotlin and C tutorial series – Learn how different types and constructs are mapped between Kotlin and C.

• Create an app using C interop and libcurl – Create a simple HTTP client that can run natively using the libcurl C library.

• Create your Kotlin Multiplatform library – Learn how to create and publish a multiplatform library using IntelliJ IDEA.

• Build a full-stack application with Ktor and Kotlin Multiplatform – This tutorial now uses IntelliJ IDEA instead of Fleet, along with Material 3 and the latest versions of Ktor and Kotlin.

• Manage local resource environment in your Compose Multiplatform app – Learn how to manage the application's resource environment, like in-app theme and language.

New and revamped pages

• Kotlin for AI overview – Discover Kotlin's capabilities for building AI-powered applications.

• Dokka migration guide – Learn how to migrate to v2 of the Dokka Gradle plugin.

• Kotlin Metadata JVM library – Explore guidance on reading, modifying, and generating metadata for Kotlin classes compiled for the JVM.

• CocoaPods integration – Learn how to set up the environment, add Pod dependencies, or use a Kotlin project as a CocoaPod dependency through tutorials and sample projects.

• New pages for Compose Multiplatform to support the iOS stable release:

  • Navigation and Deep linking in particular.

  • Implementing layouts in Compose.

  • Localizing strings and other i18n pages like support for RTL languages.

• Compose Hot Reload – Learn how to use Compose Hot Reload with your desktop targets and how to add it to an existing project.

• Exposed migrations – Learn about the tools Exposed provides for managing database schema changes.