It’s been around 6 months since we adopted Kotlin for our backend services at the company I currently work at. We’ve been migrating an existing java spring boot service to Kotlin. Our experience with Kotlin has been mostly great. But sometimes it does feel like Spring was retrofitted to support Kotlin.There’s the basic issues like : Spring requires classes with annotations to be open, all classes in Kotlin are closed by default. This can be resolved by adding the plugin to the gradle config. **kotlin-spring** Hibernate entities require a no-arg constructor, Kotlin has provided a compiler plugin to generate an additional zero-argument constructor for classes. **kotlin-jpa** It is important to note that these issues have been identified and the project is generated using have these plugins baked into your configuration. More details on this in the Further Reading section. start.spring.io Spring DTO @NotNull validation Let us take a simple DTO to represent a HTTP request body used to create a person, where we expect and to be . We use annotation to validate the request fields, which we have defined to not be nullable. name age not null _javax_ ’s @NotNull For the below request: {"age": 20,"description": "person with no name"} We expect a validation error on the field, however it passes the validators specified on the DTO. name Why? The validator requires an instance of the object before it can validate it. Since the field is declared as a non-nullable, is providing a default value for the field based on its type. In the case of it sets it to an empty string, or in case of . javax jackson-module-kotlin name(String) 0 age(Int) Possible Workarounds Based on your use case, factor in the possibility of the value being the default value in the validation. (ie) validate against possible defaults. This ensures that the name field has at least one character and fails validation on empty strings. Similarly for age it can be specified to have at least a value of 1. 2. Enabling the for could help by throwing errors while constructing the object during deserialisation. These are different from validation errors and have to handled accordingly. DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES jackson-module-kotlin IMHO the former approach is preferable because apart from the fact it still throws a validation error, it allows you to specify more expressive conditions for validation making it more readable. Spring does not have support for Coroutines Coroutines were made stable in the release of Kotlin version 1.3. However they are still not supported by Spring out of the box. Why? Spring framework’s dispatchers do no support constructs generated by the Kotlin compiler for . Kotlin compiler generates a parameter for functions, for which Spring has no built-in handlers. Coroutines **Continuation** **suspended** Possible solutions Thanks to the efforts of , Coroutines can be used in Spring by using the . The library provides modules to support Coroutines for different applications/domains within Spring. Konrad spring-kotlin-coroutine Or just leverage the that come out of the box with Spring. @Async executors Spring is working on having more native support for Coroutines. Its status is tracked here. https://jira.spring.io/browse/SPR-15413 Further Reading https://github.com/FasterXML/jackson-module-kotlin/issues/130 https://kotlinlang.org/docs/reference/compiler-plugins.html https://www.youtube.com/watch?v=WO6d6nWg6Zk Hope you enjoyed reading this as much as I enjoyed writing it. If you think this will be of help to someone? Do not hesitate to share. If you liked it, tap the clap below so other people will see this here on Medium. Don’t forget to show some love by following the blog!
Share Your Thoughts