From Java to Kotlin and back (II): Calling Kotlin from Java

Enrique López-Mañas
Mar 7 · 4 min read

This article is part of a series. You can find the remaining article of the series here:

From Java to Kotlin and back (II): Calling Kotlin from Java

From Java to Kotlin and back (III): Calling Java from Kotlin

In the previous article, we explored how Java and Kotlin can interact with each other, and some considerations in this regard. In this second edition, we will keep reflecting on some relevant aspects to consider when Java is calling Kotlin.

Properties in classes

Likely the first Kotlin feature highlighted when we heard about the language, data classes. Data classes are mainly thought to hold data with some extra functionality allowed, and hence called Data classes. We like them because they automatically generate some functions (getters, setters, toString(), copy(), equals() and hashCode()), which otherwise we need to manually create. For instance, a data class containing just var name : String will compile into the following in Java:

Data class compiled in Java

If the name of the var starts with is, then the resulting getter will start with the prefix is. For instance. if we have var isYoung: Boolean, the resulting setter will be:

Resulting setter of an “is” attribute

Keep in mind that this does not only work for boolean types, but for any type.

Naming with JvmName

We explored in the previous article some usages for @JvmName, and I would like to provide some more ideas.

For instance, whereas Kotlin supports Optional values, in Java we do not really name it that way. So if we are designing extension functions that might be called for Java, we might want to provide them a different name so they are idiomatic enough for our Java code. Let’s check the following code:

Kotlin class with idiomatic naming

asOptional will likely confuse our Java peers, and what they are looking for underneath is whether a variable is potentially nullable or not. Hence, we specify @JvmName(“ofNullable”), to change the resulting JVM name. This will be called as follows in Java:

Java calling JvmName function

Note also that Java can access the different types of the sealed class.

Default methods in Java interface

Since Java 1.8, Java interfaces can contain default methods. Without getting too much into detail, they enable you to add new functionality to an existing interface, ensuring compatibility with code written for older versions of those mentioned interfaces. The following link explains in detail how they work.

If we want to make all non-abstract members of a Kotlin interface becoming default for any Java class that implements them, we need to compile the code with the following option:


Let’s see this in practice. Consider the following interface with a default method and that we are compiling with -Xjvm-default=all:

Default interface Kotlin

This will be implemented in a Java class as follows:

Java class implementing default interface

And of course, Java will be able to call all the functions of the interface:

Java class calling default methods

An interesting tweak is that, of course, Java can also override all the default functions. So if in our example, functionA()needs to have a custom implementation in the class implementing it, we can safely override it.

Getter and Setter renaming

Occasionally we might want to rename our getters and setters. A typical case is when returning an attribute can be composed by operations on some other attributes (for instance, something like returning a name with getName() that adds some sort of prefix or evaluation to determine the complete string being returned). We can easily do it with the annotations @get:JvmName and @set:JvmNameas follows:

Changing getters and setters


Kotlin is null-safe, Java is not null safe. When we are calling Kotlin functions from Java we can always pass a null as a non-null parameter. Kotlin generates runtime checks for all public functions that expect non-nulls. This provokes a NullPointerException in the Java code immediately. Be mindful when defining nullable and non-nullable parameters in functions, since what in Kotlin is a pleasant experience might become a party of runtime Exceptions in your Java code.

Using the type Nothing in Java

Or technically, not using it, since there is no natural counterpart in the Java world. In fact, it is interesting because java Void accepts null, but Nothing doesn’t. It is in fact a complex problem in Computer Science that we can philosophically tackle in another tackle, since we are trying to represent nothing with something, and we are biological creatures that deal with physical manifestation of items in our world. Leaving nothingness aside, the Nothing type gets represented with a raw type in Java, so keep this in mind when working with Nothing:

Nothing in Java


This article has explored some more tips on calling Kotlin code from Java. The following article of the series will explore the reverse side of the river, and we will learn how Kotlin can code with legacy Java code, and which considerations we need to keep in mind.

I write my thoughts about Software Engineering and life in general on my Twitter account. If you have liked this article or it did help you, feel free to share, 👏 it and/or leave a comment. This is the currency that fuels amateur writers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store