47.1 Requirements

Spring Boot supports Kotlin 1.2.x. To use Kotlin, org.jetbrains.kotlin:kotlin-stdlib and
org.jetbrains.kotlin:kotlin-reflect must be present on the classpath. The
kotlin-stdlib variants kotlin-stdlib-jdk7 and kotlin-stdlib-jdk8 can also be used.

Jackson’s Kotlin module is required
for serializing / deserializing JSON data in Kotlin. It is automatically registered when
found on the classpath. A warning message is logged if Jackson and Kotlin are present but
the Jackson Kotlin module is not.

Tip

These dependencies and plugins are provided by default if one bootstraps a Kotlin
project on start.spring.io.

47.2 Null-safety

One of Kotlin’s key features is null-safety. It
deals with null values at compile time rather than deferring the problem to runtime and
encountering a NullPointerException. This helps to eliminate a common source of bugs
without paying the cost of wrappers like Optional. Kotlin also allows using functional
constructs with nullable values as described in this
comprehensive guide to null-safety in Kotlin.

Although Java does not allow one to express null-safety in its type system, Spring
Framework, Spring Data, and Reactor now provide null-safety of their API via
tooling-friendly annotations. By default, types from Java APIs used in Kotlin are
recognized as
platform types
for which null-checks are relaxed.
Kotlin’s support for JSR 305
annotations combined with nullability annotations provide null-safety for the related
Spring API in Kotlin.

The JSR 305 checks can be configured by adding the -Xjsr305 compiler flag with the
following options: -Xjsr305={strict|warn|ignore}. The default behavior is the same as
-Xjsr305=warn. The strict value is required to have null-safety taken in account in
Kotlin types inferred from Spring API but should be used with the knowledge that Spring
API nullability declaration could evolve even between minor releases and more checks may
be added in the future).

WARN: Generic type arguments, varargs and array elements nullability are not yet
supported. See SPR-15942 for up-to-date
information. Also be aware that Spring Boot’s own API is not yet
annotated.

47.3 Kotlin API

47.3.1 runApplication

Spring Boot provides an idiomatic way to run an application with
runApplication<MyApplication>(*args) as shown in the following example:

This is a drop-in replacement for
SpringApplication.run(MyApplication::class.java, *args). It also allows customization
of the application as shown in the following example:

runApplication<MyApplication>(*args) {
setBannerMode(OFF)
}

47.3.2 Extensions

Kotlin extensions provide the ability
to extend existing classes with additional functionality. The Spring Boot Kotlin API makes
use of these extensions to add new Kotlin specific conveniences to existing APIs.

TestRestTemplate extensions, similar to those provided by Spring Framework for
RestOperations in Spring Framework, are provided. Among other things, the extensions
make it possible to take advantage of Kotlin reified type parameters.

47.4 Dependency management

In order to avoid mixing different version of Kotlin dependencies on the classpath,
dependency management of the following Kotlin dependencies is provided:

kotlin-reflect

kotlin-runtime

kotlin-stdlib

kotlin-stdlib-jdk7

kotlin-stdlib-jdk8

kotlin-stdlib-jre7

kotlin-stdlib-jre8

With Maven, the Kotlin version can be customized via the kotlin.version property and
plugin management is provided for kotlin-maven-plugin. With Gradle, the Spring Boot
plugin automatically aligns the kotlin.version with the version of the Kotlin plugin.

47.5 @ConfigurationProperties

@ConfigurationProperties currently only works with lateinit or nullable var
properties (the former is recommended), since immutable classes initialized by
constructors are not yet supported.

47.6 Testing

While it is possible to use JUnit 4 (the default provided by spring-boot-starter-test)
to test Kotlin code, JUnit 5 is recommended. JUnit 5 enables a test class to be
instantiated once and reused for all of the class’s tests. This makes it possible to use
@BeforeAll and @AfterAll annotations on non-static methods, which is a good fit for
Kotlin.