Slide 1
Slide 1 text
Tokyo
Svetlana Isakova
@sveta_isakova
What’s new in Kotlin?
Slide 2
Slide 2 text
Kotlin developers
0
750
1500
2250
3000
2016 2017 2018
156K
700K
2.2M
Slide 3
Slide 3 text
Timeline
… …
2017 Official on Android
2010 Project started
2016 Kotlin 1.0
2018 Kotlin 1.3
Slide 4
Slide 4 text
Kotlin evolution
Kotlin 1.2
Kotlin 1.0
Kotlin 1.1
Kotlin 1.3
Coroutines (experimental)
Coroutines get stable!
Multi-platform projects can target Kotlin/Native (experimental)
Multi-platform projects (experimental)
Kotlin/Native (experimental)
Kotlin gets stable!
Slide 5
Slide 5 text
Agenda
• Kotlin evolution
• “Experimental” features
Slide 6
Slide 6 text
Agenda: experimental features
• Inline Classes
• Contracts
• Immutable Collections
• Flows
• Multiplatform Projects
Slide 7
Slide 7 text
Principles of Pragmatic Evolution
Language design is cast in stone,
but this stone is reasonably soft,
and with some effort we can reshape
it later.
Kotlin Design Team
* The real sculpture made by José Manuel Castro López
Slide 8
Slide 8 text
Principles of Pragmatic Evolution
• keeping the language modern
• comfortable updates
• feedback loop
Slide 9
Slide 9 text
KEEPing the language modern
https://github.com/Kotlin/KEEP
KEEP = Kotlin Evolution
and Enhancement Process
contains language proposals
and the corresponding discussions
Slide 10
Slide 10 text
Comfortable updates
• Deprecation warnings in advance
• Automatic migration
Slide 11
Slide 11 text
Feedback loop with the community
• Kotlin the community
• Kotlin team listens to the community
• The community members influence
the Kotlin evolution
Slide 12
Slide 12 text
Contributors from all over the world
…
Slide 13
Slide 13 text
Experimental
features
Slide 14
Slide 14 text
Experimental features
The goal: to let new features be tried
by early adopters as soon as possible
Slide 15
Slide 15 text
Experimental Language Features
• you need to explicitly opt in at the call site
to use experimental features
compileTestKotlin {
kotlinOptions {
freeCompilerArgs += "-Xinline-classes"
}
}
Slide 16
Slide 16 text
Experimental API for Libraries
• can be publicly released as a part of the library
• may break at any moment
Slide 17
Slide 17 text
@ShinyNewAPI
class Foo {
...
}
Experimental API
@Experimental
annotation class ShinyNewAPI
You can mark your new class or function as experimental
Slide 18
Slide 18 text
Using experimental API
@UseExperimental(ShinyNewAPI::class)
fun doSomethingImportant() {
val foo = Foo()
...
}
Slide 19
Slide 19 text
• feedback loop for new features and API
Experimental: Summary
Slide 20
Slide 20 text
Inline classes
Slide 21
Slide 21 text
Inline classes
• can wrap values without additional
overhead
• currently an experimental feature
Slide 22
Slide 22 text
Duration API
• KEEP: Duration and Time Measurement API
• status: experimental in Kotlin 1.3.50
• uses inline classes
Slide 23
Slide 23 text
Refining API: trying primitive args
fun greetAfterTimeout(millis: Long)
greetAfterTimeout(2) // meaning 2 seconds?
Too easy to make a mistake
Slide 24
Slide 24 text
Refining API: trying overloads
fun greetAfterTimeoutMillis(millis: Long)
fun greetAfterTimeoutSeconds(seconds: Long)
greetAfterTimeoutSeconds(2)
Too verbose
Slide 25
Slide 25 text
Refining API: trying class
fun greetAfterTimeout(duration: Duration)
greetAfterTimeout(Duration(2))
Extra object is allocated
class Duration(val value: Long)
Slide 26
Slide 26 text
Inline classes to the rescue
inline class Duration(val value: Double)
fun greetAfterTimeout(duration: Duration)
fun greetAfterTimeout_(duration: Double)
Under the hood:
No extra object is allocated! ✓
Slide 27
Slide 27 text
Inline classes constraints
inline class Duration(val value: Double)
fun greetAfterTimeout(duration: Duration)
inline class can define only one val property
Slide 28
Slide 28 text
Creating Duration
fun greetAfterTimeout(duration: Duration)
greetAfterTimeout(2.seconds)
✓
Explicit units in the code
val Int.seconds
get() = toDuration(DurationUnit.SECONDS)
Slide 29
Slide 29 text
Inline classes: summary
• KEEP: inline classes
• help to improve API and avoid extra
allocations
• you can go and try it out
Slide 30
Slide 30 text
Contracts
Slide 31
Slide 31 text
inline fun run(block: () -> R): R = block()
inline fun run(block: () -> R): R {
contract {
callsInPlace(block, InvocationKind.EXACTLY_ONCE)
}
return block()
}
Changes in standard library
Slide 32
Slide 32 text
Changes in standard library
inline fun run(block: () -> R): R {
contract {
callsInPlace(block, InvocationKind.EXACTLY_ONCE)
}
return block()
}
inline fun run(block: () -> R): R = block()
Slide 33
Slide 33 text
We know something about run,
that the compiler doesn’t
val answer: Int
run {
answer = 42
}
println(answer)
Compiler error:
Captured values initialization is forbidden
due to possible reassignment
Slide 34
Slide 34 text
val s: String? = ""
if (!s.isNullOrEmpty()) {
s.first()
} Compiler error:
Only safe (?.) or non-null asserted (!!.) calls
are allowed on a nullable receiver of type String?
We know something about isNullOrEmpty,
which the compiler doesn’t
if (s != null && s.isNotEmpty()) {
s.first()
}
✓
Slide 35
Slide 35 text
Kotlin Contracts
…allow to share extra information
about code semantics with the compiler
Slide 36
Slide 36 text
inline fun run(block: () -> R): R {
contract {
callsInPlace(block, InvocationKind.EXACTLY_ONCE)
}
return block()
}
Contract: block lambda
will be always called once
val answer: Int
run {
answer = 42
}
✓
Slide 37
Slide 37 text
fun String?.isNullOrEmpty(): Boolean {
contract {
returns(false) implies (this@isNullOrEmpty != null)
}
return this == null || this.length == 0
}
Contract: if the function returns false,
the receiver is not-null
val s: String? = ""
if (!s.isNullOrEmpty()) {
s.first()
}
✓
Slide 38
Slide 38 text
Contract = explicit statement about function behaviour
Why can’t compiler just implicitly
infer such information?
Because then such implicitly inferred information:
- can be implicitly changed
- can accidentally break code depending on it
Slide 39
Slide 39 text
• handy functions (run, isEmptyOrNull)
are even more useful
• contract DSL will change
• more use-cases in the future
• you can define contracts for your own
functions
Contracts: Summary
Slide 40
Slide 40 text
Immutable
Collections
Slide 41
Slide 41 text
Standard library: Collections
MutableList
List
read-only
Slide 42
Slide 42 text
Immutable collections
MutableList
List
ImmutableList
PersistentList
truly
immutable
supports
modification
read-only
Slide 43
Slide 43 text
Persistent collection modifications
val list = persistentListOf(1, 2, 3)
val newList = list.add(4)
println(newList) // [1, 2, 3, 4]
Modification operation returns new collection:
Under the hood, newList shares parts of data
structure with the original list
Slide 44
Slide 44 text
Persistent collection modifications
val list = persistentListOf(1, 2, 3)
val newList = list.builder().apply {
add(4)
add(5)
}.build()
println(newList) // [1, 2, 3, 4, 5]
Applying several operations:
Slide 45
Slide 45 text
• KEEP: Immutable Collections
• Will be part of the standard library in
the future (no promised date)
• You can go and try it out
Immutable Collections: summary
Slide 46
Slide 46 text
Flows
Slide 47
Slide 47 text
Flow
• suspend-based reactive stream
flow { emit(value) }
.map { transform(it) }
.filter { condition(it) }
.catch { exception -> log(exception) }
.collect { process(it) }
Slide 48
Slide 48 text
Integration with RxJava
Use extension functions:
• flow.asPublisher()
• publisher.asFlow()
Slide 49
Slide 49 text
Backpressure
• Backpressure happens automatically
thanks to suspension mechanism
Slide 50
Slide 50 text
Flows: summary
• bring reactive streams to coroutines library
• currently in an experimental state
• will get stable soon
Slide 51
Slide 51 text
Multi-platform
Projects
Slide 52
Slide 52 text
expect fun Char.isUpperCase(): Boolean
public actual fun Char.isUpperCase(): Boolean =
java.lang.Character.isUpperCase(this)
Now:
fun Char.isUpperCase(): Boolean =
java.lang.Character.isUpperCase(this)
Before:
expect / actual in standard library
Slide 53
Slide 53 text
Multi-platform projects
Browser
Kotlin/JS
Android
Kotlin/JVM
iOS
Kotlin/Native
Server
Kotlin/JVM
common
code
Slide 54
Slide 54 text
Sharing common code
• Sharing business logic
• Keeping UI platform-dependent
• The shared part might vary
Slide 55
Slide 55 text
Common code
• you define expect declarations in the common
code and use them
• you provide different actual implementations
for different platforms
Slide 56
Slide 56 text
Time measurement example
expect fun measureTime(action: () -> Unit): Duration
Expected platform-specific API:
Expected API can be used in the common code:
measureTime {
// operation
}
Slide 57
Slide 57 text
Platform-specific Implementations
expect fun measureTime(action: () -> Unit): Duration
actual fun measureTime(action: () -> Unit): Duration {
// implementation using System.nanoTime()
}
actual fun measureTime(action: () -> Unit): Duration {
// implementation using window.performance.now()
}
actual fun measureTime(action: () -> Unit): Duration {
// implementation using std::chrono::high_resolution_clock
}
Kotlin/JVM
Kotlin/JS
Kotlin/Native
Slide 58
Slide 58 text
Common code
• can use the standard library
• can define expect declarations and use them
• can use other multi-platform libraries
Slide 59
Slide 59 text
Multi-platform libraries
• Standard library
• Ktor HTTP client
• kotlinx.serialization
• kotlinx.coroutines
• … and more
Slide 60
Slide 60 text
Many apps already in production
Going Native: How I used Kotlin Native to Port 6 years
of Android Game Code to iOS in 6 months
Shipping a Mobile Multiplatform Project on iOS &
Android
Your Multiplatform Kaptain has Arrived: iOS release is
powered by Kotlin Multiplatform
Slide 61
Slide 61 text
Multi-platform projects: summary
• a modern approach to multi-platform
development
• you can easily tune what parts you
want to be shared
• you can go and try it out
Slide 62
Slide 62 text
More about Kotlin
Slide 63
Slide 63 text
No content
Slide 64
Slide 64 text
Kotlin course at Coursera
Slide 65
Slide 65 text
Hands-on lab “Intro to coroutines & channels”
http://kotl.in/hands-on
Slide 66
Slide 66 text
Have a nice Kotlin!