Based on feedback from the developer community, we recently decided to build a new Java SDK for our API to make integrating with our API easier for Java developers. As someone with virtually no Java experience, I started exploring the Java ecosystem to see what I was getting myself into. The more I looked into things the more I came across Kotlin.

Kotlin describes itself as:

A statically typed programming language targeting JVM, Android, JavaScript & Native

A while back, one of our developers gave a Lunch & Learn presentation on Kotlin when it was first introduced, and I remember one of its biggest selling points was interoperability with existing Java code. It came across as a friendlier, more modern version of Java.

The idea of this new language providing developers with a more helpful way to approach JavaScript led me down the road of writing the new SDK in Kotlin. The process has been pretty straightforward and enjoyable so far. Let’s take a look at what I’ve learned along the way about publishing a Kotlin library that can be used by Java.

Generate and Build with Gradle

I rarely start a new project without using a generator; especially when I’m not familiar with the language I’m working in. It’s too easy to forget something or to make a simple mistake. Luckily, I came across Gradle.

Gradle has a Kotlin generator built in. Just create a directory, cd into it, and run gradle init to run the generator. Once you’re done, you can run gradle tests to make sure everything works.

mkdir my-kotlin-lib
cd my-kotlin-lib
gradle init
gradle test

Publish with Jitpack.io

Next we can publish our newly created library with JitPack. This is as simple as publishing our library on GitHub as a public repository.

In my case, I also had to add a couple plugins to my build.gradle.kts file:

plugins {
  // ...
  id("java-library")
  id("maven-publish")
}

From there, you can include the library in another project. For example,

dependencies {
  implementation("com.github.Dwolla:dwolla-v2-kotlin:master-SNAPSHOT")
}

For more info, be sure to check out the JitPack docs.

Java Interop

The Kotlin docs have an entire section on calling Kotlin code from Java. You can call Kotlin code from Java out of the box, but there are a few things you can do to tailor your Kotlin code for Java clients. Here are some of the strategies I used.

@JvmField

The @JvmField decorator is one tool I found myself using quite a bit. Let’s look at the following Kotlin code:

class Person(@JvmField val name: String)

By default, we would only be able to call personInstance.getName() from our Java code. By adding the @JvmField, we can call personInstance.name instead.

@JvmOverloads

Another helpful annotation is @JvmOverloads. From the Kotlin docs:

Normally, if you write a Kotlin function with default parameter values, it will be visible in Java only as a full signature, with all parameters present. If you wish to expose multiple overloads to Java callers, you can use the @JvmOverloads annotation.

What does this mean in practice? Let’s update our previous code with an overloaded method:

class Person(@JvmField val name: String) {
  @JvmOverloads fun greet(person: Person? = null) {
    val hello = person == null ? "Hello" : "Hello ${person.name}"
  	println("$hello, my name is $name")
  }
}

By adding the @JvmOverloads annotation to the greet function, we can now call this method in Java using either of the two signatures:

personInstance.greet(new Person("John"));
personInstance.greet();

What about java.util.Optional?

Since Java doesn’t support nullable types, I looked into using java.util.Optional in my Kotlin code instead of Kotlin’s nullable types (e.g. String?). After looking into it more closely, I decided against using java.util.Optional for my particular use case as it didn’t make much sense. This article from the University of Washington goes into detail on the pros and cons of using java.util.Optional.

Over the course of evaluating java.util.Optional, I discovered that Kotlin automatically adds @Nullable and @NotNull annotations to your code which, at the very least, will provide warnings when writing Java code as long as your editor recognizes the annotations. While I haven’t looked into it much, it sounds like other tools such as Nullness Checker are available which can treat these warnings as compilation errors to prevent you from shipping code with errors.

Should you consider writing a Java library in Kotlin?

I was initially skeptical of writing an SDK in Kotlin that targeted Java, but I’m glad we did. Since Kotlin was more similar to other languages I’ve used in the past, the learning curve wasn’t too hard to get past. Additionally, we get to support two languages with one codebase due to Kotlin’s 100% interoperability with Java. If I had a prior experience in Java, choosing Kotlin as the featured language for our Java SDK may have been a different story.

The biggest takeaways for me were that writing a Java library with Kotlin can be done and the process isn’t too difficult. All in all, I would certainly look into writing your next Java library in Kotlin as it contains many features that make it an attractive, fun, and powerful language to work with.

Stay Updated with Dwolla