This talk is to help the kotliners understand the caveats of the default interoperability features provided by Kotlin and provides a few tips for interoperability to make Java developers life easier.
4. Why is there so much hype?
• Unveiled on July, 2011 by JetBrains and released Feb, 2016
• Received First Class support at Google I/O 2017
• A much better Java
• Provides support similar to other modern languages
• A boon for Java programmers writing verbose code
8. Kotlin Adoption
• Very soon, Kotlin is going to overtake Java (For Android)
• Libraries are popping up with Kotlin support
• New libraries are developed using Kotlin
• Sample apps and code are in Kotlin
• Medium is filled with wonders of Kotlin
9. Kotlin is growing and people
are Adopting it
So Why Bother about Java Developers?
10. Problems in Adopting Kotlin
• Have to learn an all new language 😫
• Team members not willing to learn a new language
• Company is not willing to spend time and money on R&D
• Fear of breaking what is already working fine
• Hard to find Kotlin experts to get the work done
11. Most of it is not their fault!
A lot of factors come into play that stops their adoption
12. What goes on in a Java developer's mind?
• The world is moving on leaving them behind
• See a new blog? It is in Kotlin
• An awesome library that they want? It is developed and
optimized for Kotlin
• Left with the default implementation of Kotlin
interoperability support
14. How Kotlin helps with interoperability
• Kotlin works out of box with Java (mostly)
• Java classes and methods can be used directly from Kotlin
• Kotlin classes and functions can be used from Java
• With very little effort, you can make Java developers’ life much
easier and write better looking code
16. Think about access scopes
What you think is invisible is available in plain sight!
1
17. Visibility Modifiers - Kotlin
• Private fields in Kotlin stay private in Java
• Private top-level declarations turns out to be package-local
declarations
• Protected members in Java are accessible to other classes in same
package
• Internal members become public after some name-mangling
• Public stay public
18. Be mindful of the class name
Name the class to make more sense
2
27. Does not show the receiver type. Might want
function name to give more context
fun String?.isNullorEmpty(): Boolean {
return this != null && this.isEmpty()
}
Kotlin
void nullOrEmptyDemo(String s) {
boolean nullorEmpty =
Utils.isNullorEmpty(s);
}
Java
41. Call properties by their names
There is no need of an accessor for everything
6
42. Accessing Properties by Name
• There are three scenarios where the properties of a
class can be accessed directly without getters and
setters from Java
• When the property is a `const`
• When the property is a `lateinit`
• When the property is annotated with `@JvmField`
43. class AmazingClass {
companion object {
const val BASE_URL_GOOGLE
= "www.google.com"
val BASE_URL
= "www.droidcon.at"
}
}
Kotlin
54. fun increaseValue(
givenValue: Int,
increaseBy: Int = 1): Int {
return givenValue + increaseBy
}
Kotlin
void increaseValueDemo() {
DemoKt.increaseValue(60,1);
}
Java
DemoKt.increaseValue(60);
This is an error. No methods match such signature
59. fun writeBytes(bytes: ByteArray) {
val file = File(“file_path")
val fos = FileOutputStream(file)
fos.write(bytes)
fos.close()
}
Kotlin
This line is going to throw
an exception
60. fun writeBytes(bytes: ByteArray) {
val file = File(“file_path")
val fos = FileOutputStream(file)
fos.write(bytes)
fos.close()
}
Kotlin
void exceptionDemo() {
byte[] bytes = new byte[];
DemoKt.writeBytes(bytes);
}
Java
Does not throw any compile time errors.
Silently crashes at Runtime
61. fun writeBytes(bytes: ByteArray) {
val file = File(“file_path")
val fos = FileOutputStream(file)
fos.write(bytes)
fos.close()
}
Kotlin
@Throws(IOException::class)
Document the exceptions that might
be thrown
62. fun writeBytes(bytes: ByteArray) {
val file = File(“file_path")
val fos = FileOutputStream(file)
fos.write(bytes)
fos.close()
}
Kotlin
@Throws(IOException::class)
void exceptionDemo() {
byte[] bytes = new byte[];
DemoKt.writeBytes(bytes);
}
Java
Shows a compile time error and provides an
option to surround with try catch block
63. Working with Function Types
Function types which return Unit might not be what you want
9
64. The pitfalls of Function Types
• Fan of higher order functions and lambdas?
• Kotlin higher-order functions are a very nice feature to use but should be used
carefully.
• If your function type returns `Unit`, then, when used from Java, it has to return
`Unit.INSTANCE` which is unidiomatic
• Alternatives are to use a SAM (Single Abstract Method) interface in Java or Kotlin
• This issue will soon be fixed in one of the Kotlin releases and until then, you can
use Function Types bearing in mind the inconveniences caused to Java consumers
67. interface Callback {
fun doSomething(value: Int)
}
fun lambdaExampleInterface(
callback: Callback) {
callback.doSomething(3)
}
Kotlin
We have a SAM interface
written in Kotlin
69. interface Callback {
fun doSomething(value: Int)
}
fun lambdaExampleInterface(
callback: Callback) {
callback.doSomething(3)
}
Kotlin
Kotlin
lambdaExampleInterface(object : Callback {
override fun doSomething(value: Int) {
//do something here
}
})
70. Java
interface Callback {
void doSomething(int value)
}
Kotlin
fun lambdaExampleInterface(
callback: Callback) {
callback.doSomething(3)
}
We have a SAM interface
written in Java
74. Collections - Handle with Care
• In Kotlin, collections are by default immutable (list, set, map etc)
• Meaning, you cannot add or modify values in the collection
• If a mutable version is required, the request should be explicit to
create a mutable version of the collection
• When exposing immutable collections through public APIs, Java
consumers can receive them and make changes to it, causing
inconsistency