此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 Spring Boot 3.4.3! |
Kotlin 支持
Spring Boot 通过利用其他 Spring 项目(如 Spring Framework、Spring Data 和 Reactor)中的支持来提供 Kotlin 支持。 有关更多信息,请参阅 Spring Framework Kotlin 支持文档。
开始使用 Spring Boot 和 Kotlin 的最简单方法是遵循此综合教程。
您可以使用 start.spring.io 创建新的 Kotlin 项目。
请随时加入 Kotlin Slack 的 #spring 频道,或使用spring
和kotlin
标签(如果您需要支持)。
要求
Spring Boot 至少需要 Kotlin 1.7.x,并通过依赖项管理管理合适的 Kotlin 版本。
要使用 Kotlin,org.jetbrains.kotlin:kotlin-stdlib
和org.jetbrains.kotlin:kotlin-reflect
必须存在于 Classpath 中。
这kotlin-stdlib
变种kotlin-stdlib-jdk7
和kotlin-stdlib-jdk8
也可以使用。
由于 Kotlin 类默认是 final,因此您可能希望配置 kotlin-spring 插件,以便自动打开 Spring 注释的类,以便可以代理它们。
在 Kotlin 中序列化/反序列化 JSON 数据需要 Jackson 的 Kotlin 模块。 在 Classpath 上找到它时,它会自动注册。 如果存在 Jackson 和 Kotlin,但不存在 Jackson Kotlin 模块,则会记录一条警告消息。
如果在 start.spring.io 上引导 Kotlin 项目,则默认提供这些依赖项和插件。 |
Null 安全
Kotlin 的主要功能之一是 null 安全。
它涉及null
值,而不是将问题推迟到运行时并遇到NullPointerException
.
这有助于消除常见的错误来源,而无需支付包装器的成本,例如Optional
.
Kotlin 还允许使用具有可为 null 值的函数结构,如本 Kotlin 中的 null 安全性综合指南中所述。
尽管 Java 不允许在其类型系统中表达 null 安全性,但 Spring Framework、Spring Data 和 Reactor 现在通过工具友好的注释提供其 API 的 null 安全性。 默认情况下,Kotlin 中使用的 Java API 中的类型被识别为放宽了 null 检查的平台类型。Kotlin 对 JSR 305 注释的支持与可为 null 性注释相结合,为 Kotlin 中的相关 Spring API 提供了空安全性。
JSR 305 检查可以通过添加-Xjsr305
compiler 标志替换为以下选项:-Xjsr305={strict|warn|ignore}
.
默认行为与-Xjsr305=warn
.
这strict
value 需要在从 Spring API 推断的 Kotlin 类型中考虑 null-safety ,但应该知道 Spring API 可空性声明甚至在次要版本之间也可能演变,并且将来可能会添加更多检查)。
Kotlin API
runApplication 应用程序
Spring Boot 提供了一种惯用的方式来运行应用程序runApplication<MyApplication>(*args)
如以下示例所示:
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
@SpringBootApplication
class MyApplication
fun main(args: Array<String>) {
runApplication<MyApplication>(*args)
}
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)
}
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.
Dependency Management
In order to avoid mixing different versions of Kotlin dependencies on the classpath, Spring Boot imports the Kotlin BOM.
With Maven, the Kotlin version can be customized by setting 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.
Spring Boot also manages the version of Coroutines dependencies by importing the Kotlin Coroutines BOM.
The version can be customized by setting the kotlin-coroutines.version
property.
org.jetbrains.kotlinx:kotlinx-coroutines-reactor
dependency is provided by default if one bootstraps a Kotlin project with at least one reactive dependency on start.spring.io.
@ConfigurationProperties
@ConfigurationProperties
when used in combination with constructor binding supports data classes with immutable val
properties as shown in the following example:
@ConfigurationProperties("example.kotlin")
data class KotlinExampleProperties(
val name: String,
val description: String,
val myService: MyService) {
data class MyService(
val apiToken: String,
val uri: URI
)
}
Due to the limitations of their interoperability with Java, support for value classes is limited.
In particular, relying upon a value class’s default value will not work with configuration property binding.
In such cases, a data class should be used instead.
To generate your own metadata using the annotation processor, kapt
should be configured with the spring-boot-configuration-processor
dependency.
Note that some features (such as detecting the default value or deprecated items) are not working due to limitations in the model kapt provides.
Testing
While it is possible to use JUnit 4 to test Kotlin code, JUnit 5 is provided by default and 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.
To mock Kotlin classes, MockK is recommended.
If you need the MockK
equivalent of the Mockito specific @MockitoBean
and @MockitoSpyBean
annotations, you can use SpringMockK which provides similar @MockkBean
and @SpykBean
annotations.
Resources
Further Reading
-
-
Kotlin Slack (with a dedicated #spring channel)
-
-
-
-
-
Tutorial: building web applications with Spring Boot and Kotlin
-
-
A Geospatial Messenger with Kotlin, Spring Boot and PostgreSQL
-
-
Examples
-
spring-boot-kotlin-demo: regular Spring Boot + Spring Data JPA project
-
mixit: Spring Boot 2 + WebFlux + Reactive Spring Data MongoDB
-
spring-kotlin-fullstack: WebFlux Kotlin fullstack example with Kotlin2js for frontend instead of JavaScript or TypeScript
-
spring-petclinic-kotlin: Kotlin version of the Spring PetClinic Sample Application
-
spring-kotlin-deepdive: a step by step migration for Boot 1.0 + Java to Boot 2.0 + Kotlin
-
spring-boot-coroutines-demo: Coroutines sample project