Kotlin is a statically typed language that compiles to JVM bytecode or JavaScript. It is designed for readability and relies on simple but powerful abstractions. The talk discusses challenges in designing Kotlin, including mapping Java types to Kotlin, implementing flow-based typing for smart casts, and reusing Java collections while making them safer to use. Generics and variance were also challenges addressed in Kotlin's type system design.

1. Challenges
in
JVM Language
Design
Andrey Breslav
JetBrains

2. http://kotlin.jetbrains.org

3. +

4. +
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

5. +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

6. +
Challenge 0
Compiler vs IDE

7. +
IDE Services
Highlight file
Find
Usages
Find
Declaration

8. +
Find Usages
Foo
File
File
File
Word
Index
symbol
Foo
Foo
Foo
Foo
Foo
Foo
Foo
words
resolve

9. +
2 in 1
Compiler
• Analyze all code
(once)
IDE
• Analyze one file
• Resolve one reference

10. +

11. 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

12. 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()

13. +
Java (as seen from Kotlin)
public class JavaClass {!
public String foo(List<String> l) {…}!
}!
String
String?
List<String>
List<String?>
List<String>?
List<String?>?

14. +
Annotations
public class JavaClass {!
@NotNull!
public String foo(@NotNull List<String> l) {…}!
}!
String
String?
List<String>
List<String?>
List<String>?
List<String?>?

15. +
External Annotations
public class JavaClass {!
public String foo(List<String> l) {…}!
}!
@NotNull @NotNull
annotations.xml

16. +
JAR File
class Foo {
String getName() { … }
}
Nullable or Not?
<XML/>
@NotNull
KAnnotator
Inferring
annotations

17. +
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

18. +
Nullable types: Summary
Challenges
• What’s nullable
in Java?
Gains
• Static Type
Safety

19. How the Types Flow
“Smart casts”

20. +
Demo: Expression Evaluator

21. +
Smart Casts and Vars
var x: String? = getNullableString()!
!
if (x != null && x.length > 0) {!
...!
}!

22. +
Smart Casts and Loops
var x: String? = getNullableString()!
!
if (x != null) {!
while (cond1) {!
x.length!
if (cond2) {!
x = someNullableExpr!
}!
else {!
...!
}!
}!
}! • Backtracking
• Restrictions

23. +
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)

25. 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

26. 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

27. 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>)

28. 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

29. Rare
luck
Kotlin Collections
Safe
Compatible
Co-variant

30. +
Collections: Challenges
Infer?
• For Java
Classes
Generalize?
• To arbitrary
hierarchies

31. Generics

32. +
List of Anything: Java
// Java!
void print(Collection<Object> list) {!
for (Object item : list) {!
System.out.println(item);!
}!
}!
List<Object>
Collection<String>
? extends Object

33. +
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

34. +
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

35. +
Use-Site Variance
fun print(p: Array<Any>) {!
...!
}!
Array<Any>
Array<String>
66% wildcards
can not be replaced
by declaration-site
variance

36. +
Use-Site Variance
fun print(p: Array<out Any>) {!
// Can’t call set()!
}!
Array<Any>
Array<String>

37. +
Mixed-Site Variance
Designed with the help from Ross Tate from Cornell University
http://www.cs.cornell.edu/~ross/publications/mixedsite/

38. +
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

39. http://kotlin.jetbrains.org