Sebastiano Poggi

In recent years, Kotlin has been a hot-button topic in the JVM community; the usage of the language is constantly increasing, from mobile to backend projects. One of Kotlin’s advantages is its great degree of interoperability with Java right off the bat.

Calling into any Java code from Kotlin just works. Kotlin understands Java perfectly well, but there’s one minor annoyance that may present itself if you’re not following Java best practices to the letter: the lack of non-nullable types in Java. If you don’t apply nullability annotations in Java, Kotlin assumes all those types have unknown nullability—they’re so-called platform types. If you’re certain they will never be null, you can coerce them into a non-null type with the !! operator or by casting them to a non-null type. In either case, you’ll get a crash if the value is null at runtime.  The best way to handle this scenario is to add nullability annotations such as @Nullable and @NotNull to your Java APIs. There are a variety of supported annotations: JetBrains, Android, JSR-305, FindBugs, and more. This way, Kotlin will know the type nullability, and when coding in Java you’ll receive additional IDE insights and warnings about potential nulls. Win-win!

When invoking Kotlin code from Java, you should find that while the majority of the code will work just fine, you may see quirks with some advanced Kotlin language features that don’t have a direct equivalent in Java. The Kotlin compiler has to adopt some creative solutions to implement them in bytecode. These are hidden when in Kotlin, but Java isn’t aware of these mechanisms and lays them bare, resulting in a usable but suboptimal API.

Top-level declarations are an example. Since the JVM bytecode doesn’t support methods and fields outside of classes, the Kotlin compiler puts them in a synthetic class with the same name as the file they’re in. For example, all top-level symbols in a FluxCapacitor.kt file will appear as static members of the FluxCapacitorKt class, from Java. You can change the synthetic class name to something nicer by annotating the Kotlin file with @file:JvmName("FluxCapacitorFuncs").

You may expect members defined in a (companion) object to be static in bytecode, but that’s not the case. Kotlin under the hood moves them into a field named INSTANCE, or a synthetic Companion inner class. If you need to access them as static members, just annotate them with @JvmStatic. You can also make (companion) object properties appear as fields in Java by annotating them as @JvmField.

Lastly, Kotlin offers optional parameters with default values. It’s a very convenient feature, but unfortunately, Java doesn’t support it. In Java, you need to provide values for all the parameters, including the ones that are supposed to be optional. To avoid this, you can use the @JvmOverloads annotation, which tells the compiler to generate telescopic overloads for all optional parameters. Ordering of the parameters is important as you don’t get all possible permutations in the overloads, but rather one extra overload for each optional parameter, in the order in which they appear in Kotlin.

To summarize, Kotlin and Java are almost entirely interoperable out of the box: that’s one of Kotlin’s advantages over other JVM languages. In some scenarios, though, a minute of work on your APIs will make its usage much more pleasant from the other language. There’s really no reason not to go the extra mile, given how big of an impact you can make with such little effort!