Why Backend Javaer Should Try Kotlin
I was a Java Developer mainly focus on backend side before. Spring is my most familiar framework. Since Spring Framework 5 highly supports Kotlin. It’s time to try Spring Framework with Kotlin.
If you google with Why Kotlin, Kotlin Pros. & Cons., Kotlin vs Java, etc. There are many great articles to explain and compare each other. So I’ll not repeat again. But even we know Kotlin has many awesome parts, why many Java developers tend to stay on Java instead of Kotlin?
Umm, It’s a long long story for explaining. But this part is not the main point I want to focus today. But if we consider with business view, stay on Java is a reasonable option. Because even writing Kotlin code is more comfortable than Java. I think the powerful reason is Java already has big ecosystem to support most production cases.
So today I want to show a backend server side scene to explain the title. I will use Coroutine to send or process request concurrently and compare with other code style we used to do.
In frontend side, send request concurrently is a common scene. But in the past, send or process request concurrently in Java backend side is not very popular. I think there are some reasons below.
- Model of Servlet(per request per thread) and blocking request is very easy to learn and use. If your server don’t need to handle huge traffic, vertical expansion is a simple and useful idea.
- Concurrent request style is more complex than sequential blocking request style.
- The ecosystem increase the support recently. For example, Spring 5 deprecate the RestTemplate (Blocking) and suggest we change to WebClient (Non-Blocking)
Talk is cheap. Show me the code.
I design a case for 2–1–2 requests that it’s very common in our real project scene. It means we can send first two requests concurrently. The third request need result of first two requests. Also last two requests need result of third request and we can send it concurrently.
The original blocking request sample is like below block.
As the code you can see if we sequential invoke the requests. It cost 100+200+300+400+500=1500ms. But the 2–1–2 case we explain before means some requests can be send concurrently.
Let’s check the Coroutine version!
We send first two requests concurrently, so it will only cost 200ms. The third request need result of first two, we send it and cost 300ms. The last two requests also need the result of third request. We send this two concurrently, so it will cost 500ms.
So the cost compare to original sample is (200+300+500=1000ms) < (100+200+300+400+500=1500ms).
This Coroutine sample shows a very important point that Java can not replace it. Coroutine can write concurrent code in sequential blocking code style.
Why this simple idea is worthy? If we consider other solutions like handle the thread pool manually, CompletableFuture, Reactive Programming, etc. These techniques and Coroutine are base on top of background thread pool. But other solutions it hard to write it simple and readable. I show the CompletableFuture and Reactive Programming case below, if you have prettier version please feedback with me.
Obviously, Coroutine code style is more simple and readable than other. But I think the most important point is coding with right libraries and coding styles at right scenes. For example, if your teams is familiar with Reactive Programming or CompletableFuture. It’s totally ok to stay on that. But if we only compare to these techniques, obviously Coroutine is more easy to learn and write.
It’s worthy to try Coroutine now, come to join me with Spring Framework with Kotlin!
