- Using Java Code from Kotlin
- Using Kotlin Code from Java
- Best Practices for Interop
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Best Practices for Interop
To conclude this chapter, I want to summarize the major points by distilling best practices that follow from the concepts and pitfalls discussed. Following these practices helps make interoperability between Kotlin and Java even more seamless.
Writing Kotlin-Friendly Java Code
Calling Java code from Kotlin works seamlessly in nearly all cases. Still, there are some practices you can follow to avoid special cases of conflict and aid interoperability even further.
Add appropriate nullability annotations to all nonprimitive return types, parameters, and fields to avoid ambiguous platform types.
Use the accessor prefixes get, set, and is so that they are automatically accessible as properties from Kotlin.
Move lambda parameters to the end of signatures to allow for the simplified syntax where you can pull the lambda out of the parentheses.
Do not define methods that can be used as operators from Kotlin unless they indeed make sense for the corresponding operator.
Do not use identifiers in Java that are hard keywords in Kotlin12 to avoid escaping.
All of these make interoperability even more seamless and can improve the quality of your Java code as well, such as nullability annotations.
Writing Java-Friendly Kotlin Code
As you’ve learned, calling Kotlin code from Java entails several things to keep in mind that usually become clear when looking at the bytecode or decompiled Java code. There are also more practices you can follow to aid interoperability.
Provide expressive names for all files with top-level declarations to avoid the default FileNameKt naming of the class (which also leaks the language). Use @file:JvmName("ExpressiveName") for this and consider using @file:JvmMultifileClass if other closely related top-level declarations exist in a different Kotlin file.
If possible, avoid Unit return types in lambda parameters of methods that are supposed to be called from Java because this requires an explicit return Unit.INSTANCE in Java. Future versions of Kotlin may provide ways to avoid this problem.
Add a @Throws annotation for each checked exception in all methods if you want to be able to handle the exception in Java. This basically lets you set your own balance between checked and unchecked exceptions. For this, also consider possible exceptions thrown by methods called inside that method.
Do not expose read-only Kotlin collections directly to Java, for instance as return types, because they are mutable there. Instead, make defensive copies before exposing them or expose only an unmodifiable wrapper for the Kotlin collections, such as Collections.unmodifiableList(kotlinList).
Use @JvmStatic on companion object methods and properties to be able to call them directly on the containing class in Java. You can do the same for methods and properties of named objects (object declarations) as well.
Use @JvmField for effectively constant properties in companion objects that are not const (because const only works for primitive types and String). Without @JvmField, they are accessible from Java as MyClass.Companion.getEFFECTIVE_CONSTANT with an ugly getter name. With it, they are accessible as MyClass.EFFECTIVE_CONSTANT, following Java’s coding conventions.
Use @JvmName on methods where the idiomatic naming differs between Kotlin and Java. This is mostly the case for extension methods and infix methods due to the different ways in which they are called.
Use @JvmOverloads on any method that has default parameter values and is supposed to be called from Java. Make sure all generated overloads make sense, and reorder the parameters if not. Move parameters with default values to the end.
These best practices help you write idiomatic code in both Kotlin and Java even while mixing the languages. Most of these use Kotlin’s JVM annotations to fine-tune the way in which Kotlin compiles to Java bytecode.