[MUSIC PLAYING]
JEFFREY VAN GOGH: Hi, my name is Jeffrey van Gogh.
I'm a tech lead on Android Studio with a focus
on programming languages.
Today, I'm going to talk about the state of Kotlin on Android.
For those who have not looked at Kotlin before,
here's a brief overview.
Kotlin is a modern programming language,
and it has many features that aid productivity.
It comes with things like nullability support in the type
system to help you avoid no pointer exception at runtime.
Shorter syntax through lambdas makes callback code
more succinct and readable.
Here, you see a call to an extension function,
which is a feature to make helper code more discoverable
and avoid polluting your code with utils.everywhere.
In this example, that call is made
as part of a template expression, which
is a compile-time checked alternative to string format
with an elegant syntax.
The last highlight of this example
shows using properties to provide a level of abstraction
over getters and setters and allow assignment syntax.
Android has officially supported Kotlin since 2017
and there is good reasons why we fell in love with Kotlin.
First of all, the language takes care of a lot of boilerplate,
allowing the developer to spend more time focusing
on the business at hand.
Next, Kotlin's strong-typed system
helps to prevent runtime issues, like NullPointerExceptions
and string format issues.
Of course, it will be hard to get
started with Kotlin without seamless interoperability
with the Java programming language,
allowing for a gradual adoption of Kotlin
into existing projects.
Finally, coroutines provide an elegant way
to do this asynchronous programming,
avoiding spaghetti code often associated with callbacks.
And it's not just us who have embraced Kotlin.
A recent survey shows that developers who adopt Kotlin
are 50% more likely to be very satisfied
with their programming language.
That same survey shows that 60% of Android pro developers
are using Kotlin in their code base and 70% of top 1,000 apps
on the Google Play Store are using Kotlin code.
The credit for creating and maintaining Kotlin, of course,
goes to JetBrains and its wonderful team of engineers.
Since officially supporting Kotlin three years ago,
Google has stepped up to help this awesome project.
Together with JetBrains, we have formed a foundation for Kotlin
to ensure the language ages well.
For example, through a careful process of vetting breaking
changes, our contributions extend
beyond policies and reviews.
Google has a team of engineers contributing to the Kotlin
compiler as their full-time job, currently
focused on helping get the new IR backend and frontend
compilers ready.
We're also working on building Kotlin-related tooling,
such as Kotlin symbol processing about which we'll
learn more later in this talk.
Here is an overview of some of the ways
that we expanded Kotlin support in Android in the last year.
On the library side, we added new Kotlin-first libraries
such as Paging 3.0 and Jetpack Compose.
We also added new Kotlin extensions
for Play Core and Google Maps.
These make using the existing APIs more Kotlin-idiomatic.
As Android developers, you spend a lot
of time interacting with the Android SDK.
That's why in Android 11, we added
more nullness annotations, making your calls to those APIs
safer.
Developers' productivity comes from great tooling.
And as such, we have added built-in Android Kotlin
live templates, which allow you to use shorthand
to add common Android constructs into your Kotlin app.
At the same time, new Kotlin-specific lint checks
help you make Kotlin code more language idiomatic.
This is especially useful as you're
transitioning from the Java programming language to Kotlin.
Looking at the compiler tool chain, R8, our shrinker tool,
contains new Kotlin-specific optimizations.
For example, eliminating intrinsic
checks when it can prove that the whole application doesn't
need them.
Materials to help you learn Kotlin are also expanding.
For example, "Kotlin Vocabulary" is a new YouTube series
that explains specific Kotlin keywords in each video.
Looking at the documentation, we have updated our Kotlin page
on developers.android.com with all
of our latest code labs and guidance
for getting started with Kotlin.
Finally, KotlinEverywhere, the program
that we ran together with JetBrains and Kotlin
enthusiasts, reached over 30,000 developers.
Last year was another really big year for Kotlin.
And while we're big fans of Kotlin,
we want to reassure you that Android is not dropping support
for writing apps in Java.
Kotlin is an important contributor to the Java
ecosystem and any improvement to the larger ecosystem
also benefits Kotlin developers.
So I wanted to take a brief detour
and show some of the improvements
that we have made in the last year for developers targeting
the Java ecosystem, no matter what language.
We've been working on [INAUDIBLE] desugaring
to enable using new newer Java language features in existing
versions of Android.
This support has been stable in the last few releases
and in Android Studio 4.2 we will
turn desugaring of Java 8 language features
on by default.
As library support is as important as features,
Android 11 adds a few additional API,
such as off methods on collections.
To avoid having you wait for these new APIs
to land on most devices, we introduced the ability
to desugar core Java language libraries, such as streams
and time, starting at Android Studio 4.0.
This makes it easier to use general purpose open
source libraries on Android.
This library desugaring functionality
was built in close partnership with Google's internal tooling
team.
As you can imagine, within Google, we're
also doubling down on Kotlin.
Over 55 of our apps are now using Kotlin.
And here you see a few of Google's most popular apps
that have already started using Kotlin in their code base.
Our large internal code base counts over a million lines
of Kotlin code.
We've recently started using Kotlin for server-side code,
as well.
I personally had the pleasure of writing some code
analysis in Kotlin and then running
that code at scale inside of [INAUDIBLE] on thousands
of cores.
As part of us building Kotlin support for internal code base,
we've added Kotlin support to some of our core libraries,
such as gRPC and ProtoBuf.
The gRPC work has recently been open sourced
and ProtoBuf will follow soon.
We're also using our large internal code base
to help vet the new compiler work that will
be available in Kotlin 1.4.
And speaking of Kotlin 1.4, it is currently
available through the early access preview program
and brings many improvements.
On the compiler side, this includes language additions,
type inference improvements, and generating type annotations
in byte code of Java 8 plus targets.
On the library side, 1.4 brings a common reflection
API, program configuration for Kotlin reflection,
and new contracts.
The release also brings a slew of performance improvements
all across the board.
Let's take a deeper look at some of the new language additions.
From an early point, Kotlin has supported
SAM, or Single Abstract Method conversions
for interfaces defined in the Java programming language.
However, as Kotlin supports higher order functions
natively, it did not support this for Kotlin interfaces.
1.4 adds the notion of fun interfaces.
Instances of the fun interface can
be created using lambda syntax and this feature
will make exposing Kotlin APIs to Java consumer even easier.
The next feature I want to showcase
is a small addition to the language,
but I believe it's a powerful one.
Up until Kotlin 1.3, parameter lists
were not allowed to have a trailing comma
for the last element.
1.4 removes this restriction.
By allowing the trailing comma, the code looks more symmetrical
and it will cause fewer distractions in code review,
as adding new entries will no longer highlight
multiple change lines.
These new features help with productivity, for sure.
However, the biggest thing that will help your productivity
is tolling performance.
We've heard you, and both JetBrains and Google
are working hard in this area.
The new front end compiler, which I mentioned earlier,
will deliver large improvements.
But, as writing a new compiler is a large undertaking,
we're going to make sure to compiler is not
only fast, but also correct.
It'll be a while before this is available
in the stable releases.
So we need to make sure we add additional performance
gains in the meantime.
We have been working on support in the Kotlin Gradle plugin
to make annotation processors more incremental,
as well as helping annotation processor authors make
their annotation processors ready for incremental runs.
To help track IDE performance issues,
Google and JetBrains teams have been organizing combined
performance hackathons.
These have led to numerous improvements in Kotlin 1.3.60
and above.
On the Gradle side, we're working with Gradle.inc
to make drastic changes to its model
for incremental compilations under a project and instance
execution.
Combined with additional caching for faster up to date checks,
we are seeing up to 30% improvements
in controlled experiments.
This work is under heavy development
and expect more news in the coming months.
One topic around performance I want to talk about
is a new project called Kotlin Symbol Processing.
Our data shows that many Kotlin builds are significantly slowed
down by annotation processors.
The Kotlin tool chain needs to perform
lots of magic to make these run seamlessly between Java
and Kotlin, leading to these performance concerns.
My team has been working on Kotlin Symbol
Processing, or KSP, as an alternative to this.
Instead of using cat, developers can now
build lightweight plugins that run as part of the Kotlin
compilation process.
KSP allows for incremental resolution of symbols.
And from porting some existing annotation processors,
we are seeing 30% to 40% faster compilations.
KSP comes with a rich set of APIs
and provide access to all Kotlin symbols,
including ones that are not available in the Java
programming language, such as properties,
function types, et cetera.
KSP is multi-platform ready, so you
can write your single processor once and use it on all target
platforms your project uses.
We're launching a developer preview of KSP today.
And while it's not quite ready for production usage,
we want to invite existing annotation processors authors
to give it a spin and provide us with feedback
via the short link visible in the slides and the video
to description below, or via the KSP Slack
channel on Kotlinlang.org.
So far, you've seen a lot of great things
for both Kotlin and Android.
But this is the Android 11 beta launch show,
so let's briefly talk about Android 11.
At Android 11, we have deprecated the AsyncTask class.
And let's be honest, it's been an API
with a fair share of problems to begin with.
So what should you use instead?
Well, developers have turned to various custom solutions,
including threads, executors, higher level library searches,
or RxJava or Guava.
And with Kotlin, there is one more contender,
and that is coroutines.
Coroutines are the Kotlin way for doing
asynchronous programming, with full support in the language
and library since version 1.3 was released
over 1 and 1/2 year ago.
Here, you see a small example using coroutines
to perform an asynchronous call to receive
server-side data, followed by asynchronous code
to store that data in the local database, again followed
by a UI update.
Coroutines code is executed in a scope.
In Android, we have libraries to tie the lifetime of these calls
into the Android lifecycle.
These features allow you to schedule
execution of network and database excess
on the I/O background thread.
Async network calls can be made through libraries like retrofit
that support coroutines out of the box.
And here, we're using rooms coroutine support
to store the data on the device without locking the UI thread.
Finally, we passed a value onto the view model
could be displayed in the UI.
With all these asynchronous steps,
the IDE clues you in on any asynchronous behavior
with the icon on the left side of your code.
Today, we're officially recommending coroutines
as the way to do asynchronous programming in Kotlin.
And if you haven't adopted Kotlin yet
and are struggling with asynchronous programming,
this is another great reason to take a closer look at Kotlin.
You might wonder why so many developers chose
to pick coroutines as their async solution
and why we stand by their choice with
our official recommendation.
Coroutines are particularly good fit for mobile applications
running on Android.
Structured concurrency helps developers
scope the work through the application lifecycle
and prevent minor leaks.
Next to this, callback-free code is easier
to read and less error prone, while building support
for cancellation and natural exceptions handling
helps ensure that error cases is treated gracefully.
Many of our APIs already support using coroutines.
To enter the world of coroutines,
we have created special made coroutine scopes that
allow you to run async code inside of your models
and within these scopes, you can make
use of the coroutine support in various Jetpack libraries.
For EXAMPLE in the Android room library, which
provides structured database access,
you can easily access databases without blocking
the main thread through coroutines.
Meanwhile, longer running tasks are often
modeled through jobs inside WorkManager.
With coroutine worker, you can easily model job cancellation.
Both of these are extensions to existing libraries.
In some of our new libraries, we started with coroutines
from the ground up.
A great example is our paging 3.0 library.
And lastly, new Jetpack composed API
will rely heavily on coroutines.
As composing coroutines compliment each other
splendidly, composal functions declare
snapshots that react to change over time
and suspending functions provide that change over time.
So what does this recommendation mean for Java users and people
who have adopted other higher level asynchronous programming
libraries?
The great thing about the coroutines library
is that it makes it entirely possible
to write interrupt support for both libraries.
For example, paging will ship with RxJava,
and Listenablefuture compatible APIs.
Conversely, for libraries that have not yet
adopted coroutines APIs, you can use many third party adapters,
such as the ones that converts task-based API from Google Play
services to coroutine suspend calls.
And you can even write your own.
We recognize that many of you will
want to begin learning about coroutines.
And we've made sure that you're covered.
Over the previous months, we have
been updating our learning materials, including
our coroutine codelabs.
Multiple coroutine articles covering a large range
of topics, from basics to deep dives,
into coroutine internals.
And finally, you can check out our conference talks
from Android Dev Summit, Kotlin Conf,
as well as specially-recorded coroutines intro videos.
You can find links to all our content in the video
description below.
To wrap things up, I hope it's clear to see
that Android loves Kotlin.
The language helps developers be more productive
and makes them happier with their tool set.
We continue to expand support for Kotlin within Androids
and Google is expanding its own use of Kotlin,
both on their Android apps as well as on the server.
Google is working closely with JetBrains
to make the language and tools even better.
Kotlin 1.4 will bring many enhancements
and we would love to hear your feedback on Kotlin Symbol
Processing.
Coroutines are now a recommended way
of doing asynchronous programming on Android
for Kotlin developers, as it provides
a structured, easy way and less error-prone way
to do to the many asynchronous tasks
that Android developers need to code all the time.
For those new to Kotlin we hope our continuously expanding
documentation, codelabs, and videos
helps you get started easily.
And with that, thanks for watching.
[MUSIC PLAYING]