Context with receivers is a new experimental Kotlin feature. So let’s explore this feature a bit and see what it is all about.

One of the great features of Kotlin is its interoperability with Java code. This allows you to easily call 'traditional' Java code from your Kotlin code, but it also helps you the other way around: calling Kotlin code from Java.

Sometimes, a little extra work is needed to make some shiny Kotlin feature work with Java code. For example, Kotlin supports default parameter values, which are not supported in Java. In this case, the @JvmOverloads annotation can be used to generate overloads for functions that contain parameters with default values. This annotation does not only work on functions, but can also be applied on constructors. In this post I will explain how to use this feature on the primary constructor, as it might be confusing where to place the annotation.

After completing the Kotlin for Java Developers Course on Coursera I was looking for an excuse to put my freshly gained Kotlin knowledge into action. I decided to address my frustration about the large amount of falsely detected movements by one of my security camera’s.

One of the core components of that solution is a REST API that receives an image and returns a list of detected objects. I decided to develop that using Kotlin, KotlinDL and KTor.

This blog posts describes the core components of the solution. The source code of the example is available at GitHub.

Spring Security provides a lot of convenience to develop secure web applications. However, it relies strongly on a SecurityContext stored in a thread-local (inside the SecurityContextHolder class). If not mitigated, this causes issues in multi-threaded contexts. When using Kotlin Coroutines, there is an additional abstraction layer where you don’t really know (and don’t want to know) on which thread(s) your code will be running. Luckily, there is a relatively easy solution!

How would you like to use your favorite backend language to develop frontend? In this blogpost I’ll show you how to compile a small kotlin example to WebAssembly and how to run the output in your browser.

When code evolves we usually deprecate old code. Sometimes we come across deprecations without any hints with what to replace it with. Kotlin has a solution for this by allowing you to specify a replace instruction.

For example, we created have an old REST client.

Kotlin data classes and annotations go really well together, but it is easy to mess it up.

When dealing with Maps in Kotlin, sometimes we’re only interested in entries for which the value is not null. Although the Kotlin Standard Library contains a filterValues function that seems to be appropriate, this function does not do any type conversions, resulting in a Map which won’t contain null values, but is still a Map with values of a nullable type according to the compiler. There is a feature request for the JetBrains team to add this functionality, but for now it has not been implemented (yet?).

If you write lots of Kotlin code you might have noticed that it is annoying to write the named parameters when calling functions or when creating a new instance of class.

I found an IntelliJ IDEA plugin named 'Kotlin Fill Class' that does this for you. https://plugins.jetbrains.com/plugin/10942-kotlin-fill-class

The Kotlin standard library contains a lot of helper functions on top of the Java standard library for our convenience. Some of those functions help us in converting between different data types. For example, the String.toInt() function converts a number formatted as String to its Int representation. But how do we accomplish the same with a Char? Spoiler alert: NOT by using Char.toInt(), but by using Char.digitToInt()!

Functions defined in Kotlin companion objects are often seen as the 'equivalent' of static methods in Java. Although there are some similarities, there are also some caveats you should be aware of. For example, how to use method references (or, to be pedantic: function references) to refer to functions defined in a companion object.

It’s quite common in a microservice style architecture to provide a type-safe client library that other services can use to communicate with your service. This can be package with a Retrofit client published to nexus by the maintainer of the service. Some projects might also generate that code from a OpenAPI spec or a gRPC proto file.

However, when we expose some of these APIs to the frontend, we lose the types. In this post I suggest a way to publish your backend API types as an NPM package. The frontend can then depend on these typings. Using typescript you now have compile time type safety and code completion. To see a sneak peak, scroll to the end :).