Using Project Kotlin for Android

UsingProjectKotlinforAndroid

Statically-typed,highly-interoperableaugmentationtotheJavalanguage.

Author: @JakeWharton

Created: 2015-01-20

Updated: 2015-01-26

Note:



This is a copy (and slight edit) of a document that was presented internally at Square. It

advocates the use of the Kotlin language for developing Android apps.

Table of Contents

Introduction

Other Awesome Things

Use Cases

Utility Methods

RxJava, Listeners

Mock Mode & Test Fixtures

Technical

Feature Implementation

Runtime

Build Integration

IDE Support

New Language

Jack & Jill

Resources

Introduction

Kotlin is a language by JetBrains, the company behind IntelliJ IDEA and other (sweet) tools, and

is purpose built for large-scale software projects to improve upon Java with a focus on

readability, correctness, and developer productivity.

The language was created in response to limitations in Java which were hindering development

of JetBrains' software products and after an evaluation of all other JVM languages proved

Interoperability

The most important feature of the Kotlin language and runtime is its core focus on

interoperability. Unlike other JVM alternative languages (most specifically: Scala), idiomatic

Kotlin should be able to easily call Java as well as have idiomatic Java easily call into Kotlin. In

fact, you should never know that you are crossing that boundary in either direction.

The runtime of Kotlin exists only to support the language features making it extremely lean. The

java standard library types, collections, etc. are all reused and ultimately are augmented for

greater utility through some of the subsequently mentioned features.

(See the Kotlin documentation for more.)

Lambas

'nuff said.

Since null is unavoidable, there are many ways to deal with it.

}

suggesting.

By pushing nullability into the type system, traditional workarounds like optional are not needed.

This is especially important on Android whose heap and garbage collector are much more

sensitive to tiny and/or short-lived objects. Java 10 will push Optional onto the stack, but we'll

all be dead before Android sees that.

Due to the aforementioned heap and GC concerns, Android uses null a lot. Like a lot

Since all references are nullable in Java, Android code is often littered with unneeded null

checks or experiences crashes due to dereferencing something which was not thought to be

null. Moving this into the type system will eliminate this ambiguity removing both the noisy,

needless checks and a large majority of inadvertent exceptions.

}



println(x.last()) // Prints "!".

Half of Guava* and 2/3rds of the Cash app* is comprised of static utility methods. While this

wouldn't eliminate their presence, it would allow you to use them directly on the types for which

they were implemented. This is a big win for readability. Death to the plurals (Collections), the

numbereds (Collections2), and the 'util' suffixeds (StringUtils).

* Not even remotely a true statistic

(See the Kotlin documentation for more.)

DataClasses

Akin to what value types in Java 10 are hoping to accomplish, data classes are those which

exist only to group data in a semantic, immutable type. We currently use AutoValue to simulate

value types in an easy fashion.

This class gives you equals, hashCode, toString for free. Each component is exposed by a

read-only property of the same name. There is also a copy method for changing values into a

new instance.

}

(See the Kotlin documentation for more.)

OtherAwesomeThings

● Classes and methods are final by default. You can declare them open if you want

extensibility.