A popular approach is packaging by technical concerns. But this approach has some drawbacks. Instead, we can package by feature and create self-contained and independent packages. The result is a codebase that is easier to understand and less error-prone.

Maintainable and readable test code is crucial to establish a good test coverage which in turn enables implementing new features and performing refactorings without the fear of breaking something. This post contains many best practices that I collected over the years of writing unit tests and integration tests in Java. It involves modern technologies like JUnit5, AssertJ, Testcontainers, and Kotlin. Some recommendations might be obvious to you, but some might conflict with what you’ve read in books about software development and testing.

Exceptions are a common mean to handle errors. However, they have some drawbacks when it comes to compiler support, safety and traceability. Fortunately, we can leverage Kotlin’s sealed classes to create result objects that solve the mentioned problems. This way, we get great compiler support and the code becomes clean, less error-prone, easy to grasp and predictable.

MongoDB’s dynamic schema is powerful and challenging at the same time. In Java, a common approach is to use an object-document mapper to make the schema explicit in the application layer. Kotlin takes this approach even further by providing additional safety and conciseness. This post shows how the development with MongoDB can benefit from Kotlin and which patterns turned out to be useful in practice. We’ll also cover best practices for coding and schema design.

“Kotlin is great and I really want to use it. But how can I convince my management?” This is the most frequent question I get asked after a talk. In this post, I explain how we introduced Kotlin and show arguments, strategies and tricks that can increase your chances of success. I keep the fingers crossed for you!

Unit Testing in Kotlin is fun and tricky at the same time. We can benefit a lot from Kotlin’s powerful language features to write readable and concise unit tests. But in order to write idiomatic Kotlin test code in the first place, there is a certain test setup required. This post contains best practices and guidelines to write unit test code in Kotlin that is idiomatic, readable, concise and produces reasonable failure messages.

Hibernate is my daily business. And it bugs me. Hibernate adds non-trivial complexity to your application and restricts the flexibility in terms of the query capabilities and the class design. Fortunately, there are many alternatives available. In this post, I like to recap some drawbacks of Hibernate and present an alternative: Do-it-yourself ORM with plain SQL, Spring’s JdbcTemplate and compact mapping code powered by Kotlin.

With Kotlin we can write code that is easy to understand, short, expressive and safe. Sounds like clean code, doesn’t it? In this post, I go through some recommendations and principles of clean code and consider if Kotlin can help to fulfill this rules or not. Moreover, I show restrictions and points, where we should be careful. At the end, I discuss if Kotlin leads to “a dark or a bright path”.

In order to take full advantage of Kotlin, we have to revisit some best practices we got used to in Java. Many of them can be replaced with better alternatives that are provided by Kotlin. Let’s see how we can write idiomatic Kotlin code and do things the Kotlin way.

Coding with Kotlin is great fun. But things are getting really interesting when we try to use Kotlin in conjunction with popular frameworks like Spring Boot and Vaadin. The development with those frameworks can benefit a lot from Kotlin. However, we have to pay attention to some pitfalls.

We at Spreadshirt have started to use the JVM language Kotlin in a couple of services. This ended up in great enthusiasm. Kotlin allows us to significantly reduce the boilerplate and to write more robust and readable code. In fact, I don’t want to write Java anymore. In this post I like to show you why.