Every time I have used Kotlin instead of Java I enjoyed it and did not regret it. But somehow I still meet some reservations regarding Kotlin with both managers and sometimes developers.

This Post will address your fears as a (Java) developer regarding the use of Kotlin and elaborate a bit on what Kotlin will gain you. There is a similar post on this blog addressing managers (German version here) which will probably also be good reading for you.

Fears

• It might be incompatible with framework X
  • Now I can’t fully take this fear away. But I have yet to encounter a major incompatibility for which there was no good workaround. For example Mockito does not play nicely with Kotlin (partly because ‘when’ is a keyword in Kotlin) but there is a very nice shim library for Kotlin mockito-kotlin that fully fixes the issues. All major Java frameworks are either very Kotlin friendly (such as Spring Boot) or Kotlin is able to adapt easily without issues (like Java EE).
• I need my code analysis tools like FindBugs
  • There is detekt and also a plugin for SonarQube in addition to rules that, SonarQube provides its own rule set for Kotlin and last but not least IntelliJ IDEA probably has the best static code analysis out there. You will not miss out on anything.
• I need my test coverage reports to work properly
  • There used to be problems with Jacoco and Kotlin’s generated code such as getters but those problems are long gone. This days it works just fine. The combination of Jacoco and SonarQube in half recent versions just works.
• I can’t just rewrite my software in Kotlin
  • And you also don’t need to. Kotlin and Java can interact and coexist with each other easily – even in the same maven module (I’m sure the same is true for other build systems too). As far as I know IntelliJ IDEA contains both a lot of Java and a lot of Kotlin code.
• It’s too much to learn Kotlin
  • If you know Java you are already able to read and understand Kotlin with only checking for specific concepts every now and then. Also Kotlin’s API is very often just based on standard Java APIs you already know. I personally spent about a day reading about Kotlin concepts, playing a bit with the language and learned the rest on the go. I probably would not have needed to spend that day. After about one or two weeks you should be at least as productive with Kotlin as you are with Java. Also a good way to start off with Kotlin is to write test code in Kotlin.
• A new programming language. The documentation might be bad
  • Let me assure you, it is quite good. It also often links to language concepts where they are used and thus makes it very easy to learn the language on the go.

Gains

• improved readability
  • Kotlin has less boilerplate code and a lot of self explaining syntactic sugar combined with a library of very intuitively usable functions. This makes Kotlin code generally more concise and easier to understand. Which again lowers the risk of bugs. One of the probably less expected examples of this is the option to have function names containing spaces. This way you can name tests with a proper sentence explaining what the test does.
• null safety
  • While you can use nullable types in Kotlin they are not the default and the API makes only rarely use of it. Null safety in Kotlin is transferred into the type system and thus will be checked by the compiler. This probably all NullPointerExceptions that were your fault. When dealing with Java libraries null checks are mandantory and thus will be handled. This eliminates the bane of all Java programmers.
• better defaults
  • Variables are final because we only rarely reassign then; classes are final because inheritance should be used with care; classes and functions are public because we usually want to use them from the outside and who uses package private often anyway?
• functions are first class citizens
  • You can finally get rid of all those useless *Utility and *Helpers classes with only static methods. Also the Kotlin API is much more friendly for functional programming styles while not restricting you to such a programming style. You can use classes when appropriate and functions when appropriate – no emulation of either necessary.
• extension functions for good code structure and readability
  • Extension functions look like you are adding public functions you don’t own. But you really don’t. Because you have to import them the code will be properly decoupled but from the reader’s perspective you can still have very intuitively readable code. For example you could extend your entity with a toDto() function. This function is not located in the entities package/module but within your conversion logic and in the end you can still use Tell Don’t Ask.
• less boilerplate code
  • Now some other gains described here work in this direction (like better defaults). But this is not limited to those. In general Kotlin takes away so much boiler plate code. It is designed very well for major use cases. For example data classes readily provide equals, hashCode, toString and copy functions. No need for Lombok, IDE generated versions of those which don’t age well or even hand written versions. Less boilerplate code -> fewer bugs in boilerplate code -> fewer bugs.

Summary

Do not fear Kotlin there will also be many worthy gains. I definitely recommend Kotlin over Java.