Learning Spring with Kotlin – Sprint 0

I've been using spring and Kotlin together for nearly 3 years. Since then, a lot of Kotlin specifics have crept into Spring. Also, there's an effort to move to a fully declarative Kotlin DSL for driving spring (kofu), which gets rid of basically all anotations, AOP processing, and other magic that makes spring both nice and hard to debug. At this point, if you are using Spring and not using Kotlin: you are doing it wrong. You are missing out on a ton of stuff the Spring people did to support Kotlin. Yes Java is still supported but it is increasingly in the same way that Google hasn't completely deprecated Java for Android yet despite that obviously very much being a second class citizen in that ecosystem.

In short, if you are a conservative institution like a bank and evolving your tech stack at a glacial pace; yes you can still use Java. Everybody else, you probably should be using Kotlin.

My advice to anyone looking to do this is:

1) Do it, it's easy and you end up with better code. You can start simple and mix Java and Kotlin code. I would advice starting with some tests or some new features.

2) Beware of the java idioms and cruft in Spring and do things the Kotlin way. So, DSLs instead of annotations + AOP, co-routines instead of spring flux, immutable data classes instead of java beans, etc.

3) Spring has a lot of stuff and not all of it is great or even good. IMHO the added advantage of e.g. spring-cloud or spring-data is very limited and sometimes it's just very limiting/backwards. I ripped out spring-data on several projects where people naively supposed it was the easiest/best way to interact with Elasticsearch. It turns out it is neither. Spring cloud sounds nice until you realize most of the stuff you need is supported in the amazon driver but yet not exposed in spring-cloud. Also all the code samples on Amazon are for their own driver and not for spring-cloud.

4) Re-assess if you actually want to go anywhere near hibernate. IMHO it made a lot of sense when java beans were hard to write. Kotlin data classes take away most of that pain and there are some nice alternatives. Also, you should be using non blocking IO for talking to your DB and hibernate is still stuck on blocking IO. That in itself is a good reason to not use it on new projects.

Once you get a bit further, you'll find yourself wondering if ktor would work. The answer is probably yes. It's actually pretty good. Spring does a lot of things but ultimately do you really need all of that and the associated complexity?

If you're using Groovy you might as well use Grails[1]. It's built on top of Spring Boot but gives you Groovy interfaces to most of the things you'd care about.

[1] https://grails.org/

I just wish that Kotlin had a testing solution as great as Spock (groovy), or rspec for ruby, for that matter.

But you mention not using Hibernate. I fully agree myself, and used JOOQ, but what is your preference?

Kotlin is taking over the JVM ecosystem like Scala could only have dreamed of doing. The JetBrains team took one of Scala's more glaring weaknesses, the tooling support, and made it the foundational strength of Kotlin. 100% inter-op with Java. It's a first class citizen alongside Java in IDEA for a long time, since before the language was even production ready. Supremely clean, coherent, and most of all concise documentation pages. They got support from Google surprisingly early on in the Android world. They have a really nice, web-based playground hosted on the main docs domain at play.kotlinlang.org. etc...

I think it's a good sign when you see it start to creep into random, seemingly disjointed areas, like how Kotlin DSLs are invading a lot of areas of dev-ops/infra-as-code. It speaks to the strengths of the language rather than the passion of the supporting community, imo.

Performance driven purists can continue to doubt, but I'm betting long by a mile on Kotlin, all it will take is time, more and more frameworks and ecosystems will integrate Kotlin, and rough edges can be polished.

>I would advice starting with some tests

The way that Kotlin extension functions and DSLs breathe fresh air into JUnit testing is hard to fully communicate. For me at least, it makes writing test code actually not suck anymore, and even fun in some cases.