Kotlin: Challenges in JVM language design

Challenges in JVM Language Design

Andrey Breslav JetBrains

http://kotlin.jetbrains.org

+

+Kotlin

n  Statically typed

n  Compiles to JVM byte codes or JavaScript

n  JVM version is Java compatible both ways

n  Intended for industrial use n  Designed for READABILITY n  Relies on simple (but powerful) abstractions n  Performance is a priority n  Tooling matters

n  Open Source (Apache 2) n  http://github.com/JetBrains/Kotlin

+Disclaimer

n  This talk is NOT an introduction to Kotlin

n  A few highlights J n  Extension functions

n  Type-Safe builders

n  Primary constructors

n  Delegated properties

n  Please refer to http://kotlin.jetbrains.org for more information

+Challenge 0

Compiler vs IDE

+IDE Services

Highlight file

Find Usages

Find Declaration

+Find Usages

Foo

File

File

File

Word Index

symbol

Foo

Foo

Foo

Foo

Foo

Foo

Foo

words

resolve

+2 in 1

Compiler • Analyze all code

(once)

IDE • Analyze one file • Resolve one reference

+

Java String s = null; s.length();

Errors At Runtime

Kotlin val s: String s.length() val s: String? = null s.length()

Errors At Compile Time

= null

Nullable type

Check and use val s: String? = … if (s != null) { s.length() }

Check and exit if (s == null) return s.length()

Rock’n’Roll s?.length()

+Java (as seen from Kotlin)

public class JavaClass { ! public String foo(List<String> l) {…} !} !

String

String?

List<String>

List<String?>

List<String>?

List<String?>?

+Annotations

public class JavaClass { ! @NotNull! public String foo(@NotNull List<String> l) {…} !} !

String

String?

List<String>

List<String?>

List<String>?

List<String?>?

+External Annotations

public class JavaClass { ! public String foo(List<String> l) {…} !} !

@NotNull @NotNull

annotations.xml

+

JAR File

class Foo { String getName() { … } }

Nullable or Not?

<XML/>

@NotNull

KAnnotator

Inferring annotations

+Inferring Annotations

n  Well-known problem n  A little out of fashion

n  Best tool to date: Julia by F. Spoto of Università di Verona

n  Expensive license

n  Challenge: n  Good open source implementation

n  Support for Generic Types

n  Performance

+Nullable types: Summary

Challenges •  What’s nullable

in Java?

Gains •  Static Type

Safety

How the Types Flow “Smart casts”

+Demo: Expression Evaluator

+Smart Casts and Vars

var x: String? = getNullableString() !! if (x != null && x.length > 0) { ! ... ! } !

+Smart Casts and Loops

var x: String? = getNullableString() !! if (x != null) { ! while (cond1) { ! x.length! if (cond2) { ! x = someNullableExpr! } ! else { ! ... ! } ! } ! } ! •  Backtracking

•  Restrictions

+Challenge

n  Fast algorithm for n  Flow-based typing

n  respecting bottom type,

n  mutable variables,

n  loops

n  and extension functions (not presented above)

JDK Collections interface List<E> { E get(int index); E set(int index, E value); }

Read-only /** read-only */ List<Foo> getFoos() { return unmodifiableList(l); }

Errors At Runtime

Cool Collections interface List<E> { E get(int index); } interface MutableList<E> extends List<E> { E set(int index, E value); }

Read-only List<Foo> getFoos() { return l; // may be mutable }

Errors At Compile Time

Safe Compatible

Cool Collections JDK Collections

catch errors early self-documenting code

no wrapping/repackaging existing API’s work

Intuitive ? extends Foo

print(List<? extends Foo> foos) print(foos: List<Foo>)

Iterable<out  T>  

Collec/on<out  T>  

List<out  T>   Set<out  T>  

MutableIterable<T>  

MutableCollec/on<T>  

MutableList<T>   MutableSet<T>  

java.lang.ArrayList<T>   java.u/l.HashSet<T>  

Kotlin Collections

JDK Collections

Rare luck

Kotlin Collections

Safe

Compatible

Co-variant

+Collections: Challenges

Infer? •  For Java

Classes

Generalize? •  To arbitrary

hierarchies

Generics

+List of Anything: Java

// Java !void print(Collection<Object> list) { ! for (Object item : list) { ! System.out.println(item); ! } !} !

List<Object>

Collection<String>

? extends Object

+Declaration-site variance

class Producer<out T> { ! fun produce(): T {…} !} !

fun print(p: Producer<Any>) { ! ... !} !

Producer<Any>

Producer<String>

•  Produces T •  Doesn’t consume T

+

class Producer<out T> { ! fun produce(): T {…} !} !

•  Covariant •  Produces T •  Doesn’t consume T

Co- and Contra-variance

class Consumer<in T> { ! fun consume(t: T) {…} !} !

•  Contravariant •  Doesn’t produce T •  Consumes T

class Box<T> { ! fun get(): T {…} ! fun set(t: T) {…} !} !

•  Invariant •  Produces T •  Consumes T

+Use-Site Variance

fun print(p: Array<Any>) { ! ... !} !

Array<Any>

Array<String>

66% wildcards can not be replaced by declaration-site

variance

+Use-Site Variance

fun print(p: Array<out Any>) { ! // Can’t call set() !} !

Array<Any>

Array<String>

+Mixed-Site Variance

Designed with the help from Ross Tate from Cornell University

http://www.cs.cornell.edu/~ross/publications/mixedsite/

+Summary

n  Type system design n  Generics

n  Flow-based typing

n  Interoperability n  Mapping Java types to Kotlin (and back)

n  Re-using Java collections

n  IDE vs Compiler n  Uniform implementation good for both scenarios

n  Incrementality

http://kotlin.jetbrains.org