In this note, we will talk about Kotlin in the context of server-side development (JVM). There will be something similar on Android.

Why is it possible and necessary to stop writing in Java right now and switch to Kotlin?

  1. Co-routines. Asynchronous methods are deservedly popular now. At the same time, the Reactor API leads to absolutely terrible code. Quite illustrative (though old) an article on this topic: (the comments talk about some incompatibilities with Spring, but in practice I haven’t noticed any problems since the beginning of the 22nd year, although the article is 21 years old)
  2. Typed handling of null. There are big problems with this in Java.
  3. Data classes. There seem to be records in Java, but they are still weak. In general, Lombok becomes unnecessary.
  4. Sealed classes. An interesting concept that allows you to type a choice between multiple answer options. Something like Either on steroids.
  5. Typealias. They allow you to type IDs – not just string or int, but OrderID.
  6. Generally compact and readable syntax.
  7. Good acceptance and fast training of Java programmers to Kotlin programmers.
  8. Already developed and stable infrastructure: IDE and specific libraries.
  9. The language is actively developing, but without being too revolutionary.
  10. You do not need to translate the entire project immediately, you can do it in separate classes. There was a study somewhere on the Internet that this does not slow down the speed of the application.
  11. Initially, you can translate 1 in 1, and only then, in separate steps (refactoring), introduce specific features (sealed classes, etc.). Although coroutines are better right away.

Overall, Kotlin looks like the Java we deserve ;).

Of the difficulties, one can distinguish:

  1. The need for libraries to depend not only on a specific version of the JVM, but also on a specific version of Kotlin.
  2. Still, you need to organize a Kotlin adaptation project: tell and show programmers, initial code updates, builds and CICD. The more programmers and code there are, the more difficult it is.
  3. Kotlin can use Java libraries, but information about nullablility is lost and some of the language features are not supported. This is usually not a big deal, but some libraries need to be rewritten (use Kotlin-variants – mockk, log4j-api-kotlin, …). For others, use adapters (jackson-module-kotlin, reactor-kotlin-extensions, kotlin-allopen, springdoc-openapi-kotlin, …).