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.<p>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.<p>My advice to anyone looking to do this is:<p>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.<p>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.<p>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.<p>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.<p>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?