DEV Community: Pavel Sveda

[Boost]

Pavel Sveda — Fri, 26 Dec 2025 13:39:54 +0000

adiozdaniel

Dec 18 '25

Are We Losing Our Manners in Software Development?

#discuss #performance #softwaredevelopment

Comments 31

3 min read

Apple Silicon chip performance in Android development

Pavel Sveda — Sun, 11 Apr 2021 09:12:42 +0000

After many years when Intel and AMD dominate the world of workstation CPUs with x86 chips there seems a new era to come. The era of ARM.

Apple has introduced its ARM-based Apple Silicon M1 chip in late 2020 and the first benchmarks were for a lot of people too good to be true.

Motivation

I'm an Android developer so what bothers me most is how performant is the chip in Android development.

Official benchmarks are great to get some overview about CPU capabilities but they cannot answer my question as they are mostly based on rendering video or running demanding games which is a different kind of task.
Also it would not be fair to do the comparison right away at the end of 2020 as the Android ecosystem was not compatible with Apple Silicon chips natively and the tools were running through the Rosetta 2 application compatibility layer.

Now, after a few months since Apple Silicon launch there are first OpenJDK builds with native support and Gradle supports it natively since version 7.0. That's all we need to make an Android project build times comparison!

Test

We have 4 competitors in the test:

2019 Dell Precision 5530, i7-8850H, 6 cores/12 threads, 32 GB RAM
2020 MacBook Pro 16", i7-9750H, 6 cores/12 threads, 16 GB RAM
2021 MacBook Pro 13", M1, 8 cores/8 threads, 16 GB RAM
2021 MacMini, M1, 8 cores/8 threads, 16 GB RAM

The test is to be done on 3 selected Android projects:

Small project (13k LoC, 1 APK, 1 module)
Medium project (37k LoC, 1 APK, 36 modules)
Bigger project (144k LoC, 6 APKs, 30 modules)

To compare the build times, I would first run the gradlew assembleDebug to warm up the Gradle daemon and fetch all the dependencies and then make an average build time from 5-10 runs of the same task in offline without any help of cached results:
gradlew assembleDebug --offline --rerun-tasks --profile

Main questions to ask are:

Will MacBook Pro 13" with M1 chip beat the bigger Intel-based brother?
Will MacMini beat the MacBook Pro 13" with the same HW equipment thanks to its desktop nature and possible more power or better cooling?
Will 8 cores be enough for modularized projects?
Will 16 GB of RAM be enough even for bigger projects?

Results

Here are the average build times for competitors on the test projects. Some were run both with Gradle 7.0 with native Apple Silicon support and Gradle 6.8 that uses Rosetta 2 compatibility layer.

Small, single-module project cannot be parallelized much but the M1 chip did the job in half the time then Intel i7 chip in MacBook Pro 16".
Gradle 7.0 with native Apple Silicon support is certainly faster than Gradle 6.8 that uses Rosetta 2, but the difference is almost negligible.

Similar results are to be seen on medium and well modularized project. Dell's and Mac's 12 threads Intel i7 chip were still too slow against M1.

On bigger project the difference in speed isn't so enormous but still the M1 outclassed the rivals. In this run the MacBook Pro 16" did a worse job than the technically slower Dell Precision probably due to smaller RAM.

Answers

I leave the results evaluation on each of you but let me just try to answer the main questions:

1. Will MacBook Pro 13" with M1 chip beat the bigger Intel-based brother?
Yes, no doubt about it!

2. Will MacMini beat the MacBook Pro 13" with the same HW equipment thanks to its desktop nature and possible more power or better cooling?
No, this test didn't show any difference in performance of those two. Maybe when an IDE and Emulator will be running for 8 hours a day the MacMini might be more stable but that would be a more subjective observation.

3. Will 8 cores be enough for modularized projects?
Yes, the difference in performance on single-module and highly modularized project were similar.

4. Will 16 GB of RAM be enough even for bigger projects?
Yes-ish. Macs with M1 chip were fine with 16 GB RAM during the test but the older MacBook Pro 16" seems to have a problem on the bigger project. Also, IDE and Emulator were off during the test so in real-world use it might be a little limiting. One way or another, the power of M1 would overcome this limitation.

Main article image by Jason Corey on Unsplash.

What's new in Android Gradle Plugin 3.6

Pavel Sveda — Sun, 03 May 2020 08:15:49 +0000

February 2020 was quite busy as we got 4.1 Canary release of Android Studio and Android Gradle Plugin (AGP), former 4.0 Canary was bumped to Beta and we got Stable version of 3.6.
Android Gradle Plugin 3.6 is the last version in 3.x series and the last version that will work with Gradle 5.x. In tradition of minor version updates, it brings few smaller enhancements, but this is time it has also a new Feature with big F.

View Binding (docs)

What is the most famous function on Android?
Probably View.findViewById(). For various reasons developers are trying to avoid using it as much as possible.
There is a complete history of 3^rd party libraries and frameworks like Kotlin Android Extensions, Butter Knife or Android Annotations that are trying to hide it behind a nicer API or annotations.
Also Google contributed to this list with Data Binding that also might serve as a replacement for binding Views defined in layout.xml and i.e. Fragment's code, although it is maybe too heavy to be used for binding views only.
Maybe this was the reason why a new Google tool called View Binding was created.

How does it work?

I won't go into details about what it does and how you can use it as we have already a plenty of other blog posts out there.
But there is one technical detail I didn't find anywhere. From the docs:

Once view binding is enabled in a module, it generates a binding class for each XML layout file present in that module.

But who generates the code?

It cannot be an Annotation Processor as in comparison to Data Binding, View Binding is said to require no annotation processing for faster compilation.
It cannot be Kotlin Compiler Plugin as View Binding works also for Java code.

I cannot find the answer anywhere, so I asked the author. It turns out that View Binding is a standalone tool that consist of three components.

Code Generator

This is the actual View Binding's engine.
It creates a ViewBinder.kt model for each layout in the project that requires a *Binding class to be generated.
Then there is ViewBinderGenerateSource.kt that takes the outputs of Data Binding XML layout parser and generates binding code using JavaPoet.

Artifact: androidx.databinding:databinding-compiler-common (link)

Build Hook

Code generation is invoked by Android Gradle Plugin during build. There is no much difference from how Data Binding is configured in TaskManager.java.

Artifact: com.android.tools.build:gradle (link)

Feature API

Last piece of the puzzle. View Binding has a tiny public API available to developers that consists of single class: ViewBinding.java. It serves as marker interface for all generated *Binding classes.

Artifact: androidx.databinding:viewbinding (link)

So, who generates the code?

Annotation Processors tend to be problematic in terms of configuration and performance.

Kotlin Compiler Plugins tend to be problematic to work with Java code (joke).

View Binding tend to be tiny, simple and quick. It shows us that sometimes there is a better way how to solve a problem out of "standard tools". In this case, it is one's own code generator baked to the Android Gradle Plugin.

Maven Publish plugin support (docs)

Android Gradle Plugin 3.6 is not all about View Binding. If you are on a bigger project where dependencies are not shared as source code dependency but rather as compiled artifact dependency through artifact repository, it might be handy for you that AGP now supports Gradle's built-in Maven Publish plugin.
For most of the projects this might save a few tens lines of Gradle publishing logic.

Enhancements on R class generation

R class serves as a static list of application resources known at compile time. As projects grow their R classes might easily get a few hundred thousand or even million lines of code that need to be compiled.

To optimize the build performance AGP 3.6 starts to generate the Java bytecode directly so you don't have compile it. It means that instead of R.java file in build/generated directory you can find R.jar file in build/intermediates.

Another change is that there is only one R class generated per library module. This forces you to have a unique package name for each project module. If you need help with this requirement, there is a check introduced in AGP 3.4 that might serve you.

But what is the main reason that R classes are so big? By default, the module R class contains references to all module resources but also inherits all references from other module dependencies.
Example: Do you depend on Material Design Components library in your base module? Sorry, all of your project module R classes will contain few thousand of MDC fields. Bummer!
But there is a cure. AGP 3.3 introduces not very well documented flag. When you enabled it in gradle.properties:

android.namespacedRClass=true

it prevents references from dependencies being included in your module R class.
It also makes your module better isolated from architecture point of view as, unless you use explicitly import R class from other module, you can use only your module's resources. It prevents you to accidentally use a drawable or a string from another module.

New default packaging tool (docs)

It is called zipflinger and you should not care unless you are doing some custom app packaging magic or so.
In such case, or in case you are somehow struggling with the new packaging tool, you can disable it in gradle.properties:

android.useNewApkCreator=false

Conclusion

So that's it for Android Gradle Plugin 3.x series. Next time let's check what's new in Gradle 6.x and Android Gradle Plugin 4.x !!!

What's new in Android Gradle Plugin 3.5

Pavel Sveda — Mon, 20 Apr 2020 17:59:20 +0000

Android Gradle Plugin 3.5 came out in August 2019 as a part of Project Marble that focuses on making Android Studio and build tools more stable and polished. Thus, the only notable update is Data Binding now supports incremental annotation processing.

Incremental annotation processing on Android

Having Data Binding annotation processor support incremental processing is just a small part of much bigger puzzle. Let's have a look on how annotation processing on Android evolves and what configuration do we need to run it incrementally.

Short history of annotation processing on Android

The source-level annotation processing first appeared in Java 5 long before we heard about Android.

Annotation processing in context of Android development appeared around 2013 with libraries like Dagger or Butter Knife that helps to reduce writing boilerplate code i.e. for Android system bindings.

But, as Android projects grew, the build times become longer. And there appeared the need for incremental annotation processing that promises to lower the build times.

Gradle's part

The first step for incremental annotation processing is to have a support during build orchestration in build system - Gradle in our case. It took a couple years to make it, but finally in April 2018 Gradle 4.7 came out. Unfortunately, the incremental annotation processing is challenging and it was not possible to have for all the annotation processors incremental out of the box.

Annotation processor libraries

Gradle 4.7 came with a new annotation processing API that allows annotation processors to work incrementally. In Gradle 5.0 the incremental annotation processing was optimized for performance.

Anyway, the Gradle annotation processing API has one big limitation: to run an annotation processor incrementally, all of the build annotation processors must be incremental. If only one of them does not adopt the new Gradle API, no one can run incrementally.

So now it is annotation processor author's turn to adopt it and Gradle team is very supportive in this. Soon there was a list of major annotation processing libraries in Gradle docs describing their state on journey to incremental.

Today, two years later, there is still quite a lot of work to be done for some libraries.

Kotlin troubles

When Kotlin 1.0 has been released in 2016 it had an extra ordinary interoperability with Java. With one exception, annotation processing. Java annotation processing, baked to javac compiler, does not work with Kotlin source code at all, so there was a need for completely new tool: kapt (Kotlin Annotation Processing Tool).

The first kapt implementation was quite cumbersome to use as there was no way for Kotlin source code classes to refer to any code generated by the annotation processor.

The second version of kapt overcome this problem by generating stubs of Kotlin classes, but there were still issues with injecting values into fields etc.

So there came the complete re-write known as kapt3 and everything was good. Until Gradle 4.7 appeared with incremental annotation processing, that works for Java but not for Kotlin and we had another challenge for kapt.

It took another year. In April 2019 Kotlin 1.3.30 has been released with kapt supporting incremental annotation processors in an experimental mode. Later that year Kotlin 1.3.50 came out with stable implementation of incremental annotation processing support enabled by default.

Conclusion

Let's sum it up. If you want your annotation processors to run incrementally, you need to do three steps:

Make sure you are using Gradle 5.0 or newer.
Check that all of your annotation processors are configured to run incrementally. Some do this by default, some need to be configured (overview in Gradle docs might help).
If you have Kotlin code, make sure that you are using Kotlin 1.3.50 or newer.

Happy incremental annotation processing!

What's new in Android Gradle Plugin 3.4

Pavel Sveda — Sat, 04 Apr 2020 20:24:39 +0000

This post is part of Gradle for mobile developers series that highlights Gradle Build System features useful for every developer on mobile project (mainly Android project). To extend this effort I'd like to cover also releases of Android Gradle Plugin (AGP). There are many blog posts presenting new features of Android Studio, but not much presenting the Android Gradle Plugin itself.

I'll start with Android Gradle Plugin 3.4, released in April 2019, as it was the first version that builds on top of Gradle 5.x version only (which correlates with my previous Gradle 5.x series posts).

R8 enabled by default

R8 is a new tool used in Android build pipeline introduced in Android Gradle Plugin 3.2 as feature preview and now being enabled by default for everyone. It is responsible for:

shrinking = removing unused code and resources, code obfuscation, and optimizations (replaces ProGuard)
desugaring = backporting of newer Java version language features to Android Java version (replaces AGP internal desugar tool)
dexing = converting Java bytecode to Dalvik bytecode (replaces dx)

R8 is able to do all these steps at once, and comparing to the previous build pipeline, R8 is faster while lowering the APK output size. It saves the time by parsing inputs just once, and creates smaller outputs (APKs or bundles) using broader optimizations. Also, the fact that the entire tool is developed by Google and open-sourced creates a promise of even more features in the future.

If you want to know more about R8, there is no better source then the R8 blog series by Jake Wharton.

For some time, there will be an option to switch back to the old build pipeline, but I recommend migrate to R8 as soon as possible.
To switch back, define these flags in gradle.properties:

  android.enableR8.libraries = false  # Switch to the old pipeline for library modules
  android.enableR8 = false            # Switch to the old pipeline for all modules

Compatibility with ProGuard

R8 holds the most of the configuration and feature compatibility with ProGuard by default. There are some configuration elements ignored, mainly for optimizations not supported by R8. The only problem I struggled with was with Gson library. ProGuard has an implicit support for it that R8 does not have, so you need to add few extra rules if you use Gson in project, in my case:

  -keepattributes *Annotation*
  -keep class * implements com.google.gson.TypeAdapterFactory
  -keep class * implements com.google.gson.JsonSerializer
  -keep class * implements com.google.gson.JsonDeserializer
  -keep class com.myapp.**Dto { *; } # this keeps all model classes using Gson in app

Full mode

The compatibility with ProGuard is good for current projects migrating to R8, but if you are starting a new project and want to get more from R8, you can enable the Full Mode:

  android.enableR8.fullMode = true

This applies additional optimizations, that can further reduce app size. However, you might need a few extra keep rules to make it work. One such example is Retrofit library that actually fixed it internally and publish new keep rules with the library. The only thing you need to do is update Retrofit to version 2.6.0 or newer.

New lint check dependency configurations (docs)

Lint dependency configurations allow you to consume or publish custom Lint rules. This might be interesting for you in two cases:

Your application consumes custom Lint rules defined locally for your project. In the project's build.gradle.kts a dependency on module with custom Lint rules is defined by lintChecks configuration (actually this was introduced already in Android Gradle Plugin 3.0).
Your library publishes custom Lint rules to consumers. In previous versions this was defined by the same lintChecks configuration, but in Android Gradle Plugin 3.4 there is a new lintPublish configuration created directly for this purpose. It should allow library authors to use one set of custom Lint rules internally to enhance quality of library code, and publish another set of Lint rules for library consumers to enhance its use in consumer applications.

  dependencies {
    lintChecks project(':lint-private') // Lint rules to be executed on library code
    lintPublish project(':lint-public') // Lint rules to be executed on consumer application code
  }

Unique Package Names

There is an interesting paragraph in the AGP 3.4 release notes:

The correct usage of unique package names is currently not enforced but will become more strict on later versions of the plugin. On Android Gradle plugin version 3.4, you can opt-in to check whether your project declares acceptable package names by adding the line below to your gradle.properties file:

android.uniquePackageNames=true

Actually, I didn't find any details for this requirement. But having one package name used only in one project module seems a good thing anyway, so why not enabling this check right now and having no migration issues in the future, right?

Build Speed Degradation

This is not a feature, rather negative impact observed after migration of few projects to new Android Gradle Plugin version. The build started to be much slower and log was clogged by warnings:

  Daemon shut down due to memory pressure

The reason in my case was R8 use more memory than ProGuard and once Gradle Daemon hits the memory limit, Java Garbage Collector has been executed very often, thus the speed degradation.

The resolution is simple: give Gradle build more Java Heap space. You can configure it in project's gradle.properties file:

  org.gradle.jvmargs=-Xmx2g

It is not a good practice to set the new memory limit by guess. Gradle build needs enough memory to run smoothly. But if you set the memory limit too high, it might affect how your computer and operation system runs and more memory may actually lead to slower build times.

But there is a tool that helps you to find the proper value, Gradle Build Scan.

With default setting (-Xmx512m) the build uses all the memory (and probably needs more). Build Scan output:

With adjusted setting (-Xmx2g) the build has some memory reserve and runs smoother (and faster). Build Scan output:

On mid-size projects (roughly 200k LoC and 50+ Gradle modules) its fine to set memory limit to 3GB or 4GB.

Conclusion

Thank you for reading and stay tuned for next Android Gradle Plugin release reviews.

What's new in Gradle 5.6 (for mobile developers)

Pavel Sveda — Sun, 22 Mar 2020 11:10:38 +0000

Gradle 5.6 has been released in August 2019 as the final release for Gradle 5.x and brings a lot of features as a preparation for Gradle 6.0.

Test fixtures

When you are writing a library module, you structure the code in source sets:

Production code is placed to src/main/kotlin and shared with modules that depend on it.
Test code is placed to src/test/kotlin and is not shared anywhere.

The missing piece here is Test Fixtures code.

Test Fixtures code is placed to src/testFixtures/kotlin and shared with any test source set (src/test/kotlin) of modules that depend on it.

What is it good for? You can share common pieces for writing tests, such as Test Assertions or fake test data to avoid test code duplication as your consuming modules don't need to create them on their own again and again.

First, I was super excited about this! But when I tested it on real Android project, the feature appeared not compatible with Android Gradle Plugin at all (it works for plain Java projects only).

Anyway, Android Tooling team has already start working on this (see Issue 139762443 and Issue 139438142), so 🤞.

Central management of plugin versions with settings script (docs)

If you are not using buildSrc included build to organize the build logic you might end up specifying version of Gradle plugins in plugins {} block for every module of your project. This approach has few constrains as you are not able to read the version i.e. from gradle.properties.

To address this Gradle 5.6 introduces a new way of specifying plugin version in root settings.gradle.kts file (also with gradle.properties support):

    val helloPluginVersion: String by settings // reads value from `gradle.properties`
    pluginManagement {
        plugins {
            id("org.gradle.sample.hello") version "${helloPluginVersion}"
        }
    }

Then in the module's build.gradle.kts file the plugin declaration don't need to specify the version anymore:

    plugins {
        id("org.gradle.sample.hello")
    }

Fail the build on deprecation warnings (docs)

If you want to be 100% build warning free, you can configure Gradle to fail the build for any Gradle deprecation warning. Just add this to gradle.properties:

    org.gradle.warning.mode=fail       # other options are all/summary/none

Correct handling of file name case on case-insensitive file systems (docs)

Fixes issues with Copy and similar Gradle tasks on case-insensitive file systems like NTFS (Windows) or APFS (macOS).

Conclusion

That's it for Gradle 5.x releases. Please stay tuned for the Gradle 6.0 blog post. 😉

What's new in Gradle 5.2-5.5 (for mobile developers)

Pavel Sveda — Sun, 22 Mar 2020 10:12:54 +0000

On our road through history of Gradle versions and their value to mobile developers we already stop at Gradle 5.0 and Gradle 5.1.
In this post I'd like to summarize minor updates in Gradle 5.2 - Gradle 5.5 versions together as they do not add much to our story individually.

Gradle 5.2 (docs) - February 2019

The only mentionable change is a package of Annotation processor improvements that makes your life together with them a little bit easier.

Gradle 5.3 (docs) - March 2019

There are two features I'd like to point out, that won't affect your project builds directly, rather being important for the future enhancements.

Type-safe accessors in precompiled script plugins (docs)

Behind this mouthful set of Gradle specific buzzwords is a technical change that simplifies the way how to structure the build logic.
This topic is a candidate for a blog post on its own, but in short it is about moving all the Gradle build logic pieces out of your build.gradle.kts files to buildSrc directory which is a so called "included build" for every Gradle project.
Till then, Gradle User Guide has a standalone page for this topic called "Organizing Gradle Projects".

Gradle Module Metadata 1.0 (docs)

Gradle Module Metadata (GMM) were created as a replacement for Maven pom.xml files as those are simply not rich enough to solve many dependency management problems.
This is not something that mobile developers will directly work with every day. The main reason I'm excited about this is it allows building Kotlin Multiplatform projects with Gradle. From the docs:

The publications of a multiplatform library may include a special 'root' module that stands for the whole library and is automatically resolved to the appropriate platform-specific artifacts when added as a dependency, as described below.

Gradle will automatically consume published Gradle Metadata, but publications don't include any module metadata by default. To enable it , add enableFeaturePreview("GRADLE_METADATA") to the root project's settings.gradle.kts file.

Gradle 5.4 (docs) - April 2019

Android developers don't need to care about this release as both Support running Gradle with JDK12 (not much used among Android developers) and Support for Swift 5 (samples) do not really matter to them.

Gradle 5.5 (docs) - June 2019

If you work in a large organization that distributes custom Gradle binaries for its internal purposes (yeah, it happens), you can now define the organization-wide gradle.properties that will configure Gradle environment for everyone who is using such distribution.
This configured properties have the lowest precedence of any gradle.properties and properties defined in other locations will override values defined here.

I will cover the Gradle 5.6 version (last release for Gradle 5.x) in the next post.

What's new in Gradle 5.1 (for mobile developers)

Pavel Sveda — Sun, 22 Mar 2020 09:13:11 +0000

Gradle 5.1 came in January 2019 as a first minor update of Gradle 5.0 with few feature updates.

Repository to dependency matching (docs)

Official documentation states that:

It is now possible to match repositories to dependencies, so that Gradle doesn't search for a dependency in a repository if it's never going to be found there.

    repositories {
        maven(url = "https://nexus.mycompany.com") {
            content {
                includeGroupByRegex("""com.mycompany.*""")
            }
        }
    }

Well, that's nice. You know that your company internal dependencies can't be in any other public repository, so you tell Gradle and it saves some time when searching for them. But not every project have private dependencies in company internal repository.
However this feature has yet another use case. Maybe you read the article "A Confusing Dependency" by Márton Braun about how easy is to populate fake library to jcenter() repository. When you just do not trust some repository enough to use it in general but you still need it because the library you want is not available anywhere else, you can at least limit the use of such repository:

    repositories {
        jcenter {
            content {
                includeGroup("org.koin") // Koin is not available anywhere else
            }
        }
    }

Gradle Kotlin DSL 1.1 (docs)

Kotlin DSL 1.1 is a first update of Kotlin DSL feature originally introduced in Gradle 5.0 (you can read more about Kotlin DSL in my previous post).
The update is mainly focused on polishing the DSL syntax.
We can now use lambdas in the Gradle APIs, we have type-safe accessors for dependencies, and kotlin-dsl plugin tasks are now all cacheable which positively affects build speed.

Configuration avoidance for Tasks (docs)

From time to time you need to configure custom Gradle task as part of the build and unfortunately there is not a single way how to do this.
Historically when one defined a new task it has been configured eagerly (create) with all its dependencies in every build you run. And if you did not call such task during the Gradle run all the time spent on its configuration was wasted.
As a part of Gradle's continuous effort to speed up the build speeds a "Configuration avoidance APIs" were introduced as Preview in Gradle 4.9 and became stable in Gradle 5.1.
It allows us to configure a task in a lazy manner (register). In fact, you won't configure a Task this way but just a TaskProvider that creates a Task only once it is really needed during a Gradle run.
It might sound complicated but the only thing you need to do is to replace

   tasks.create("myTask", MyTask) {...}

   tasks.register("myTask", MyTask) {...}

And that's it! 🎉🎉🎉
If you are interested in more details, I recommend you to read this blog post.

What's new in Gradle 5.0 (for mobile developers)

Pavel Sveda — Sun, 22 Mar 2020 09:11:58 +0000

In this series I'll go through the list of recent Gradle versions and pick the most useful features for the users of Gradle build system (a.k.a. developers), but ignoring updates that target plugin creators and large system admins. The features will be picked in context of a mobile (Android) app project, but most of it is applicable also to any JVM related or Kotlin Multiplatform projects.

For the first post in this series we will go back in time to the end of 2018 when Gradle 5.0 has been released. The reason is that Gradle 5.x versions are still very recent, but more important, for the first time in history, Gradle 5.0 comes with an alternative to Groovy for writing configuration scripts -> Kotlin 🎉🎉🎉

Gradle Kotlin DSL (docs)

This is big! Actually, Gradle Kotlin DSL is not just about adding another programming language for writing configuration scripts. Introducing of this feature is actually a game changer for many teams I know to give Gradle a try, and these are the main reasons why:

IDE & tooling support

Yes, with Gradle Kotlin DSL the IDE can actually assist you with writing the script, you can use refactoring or read the Gradle API code documentation!!!
Well, to be fair, some of those features were introduced to the top-used IDEs also for Groovy DSL, but those were just few chosen features that were backed directly to the IDEs that not always work well.
With Kotlin it's a different story. Gradle Kotlin scripts (*.gradle.kts files) are processed on the fly when you write the code so the IDE works in very similar way as when you write your app's code and all the nice stuff we will love just works here.

Type safety

No more blindly trying to write some Groovy code and running the Gradle over and over again still failing due to wrong type/method call error. Now you know what plugin class you are dealing with, you can overview its methods, and in case of an error a syntax highlighting will guide immediately.

Gradle API polishing

Gradle was built on top of Groovy "magic" features that allows you to use the same syntax for calling properties and functions, shortcuts for working with collections or methodMissing concept.
But when a thoughts about introducing new language arise it was obvious that it won't be possible without a solid and kind of language "independent" API. Don't take me wrong, Gradle is a JVM tool and always will be (at least in near future), but the new Gradle Java API standardization is kind of "neutral" for these purposes, and helps the Gradle eco-system a lot.

Gradle Kotlin DSL ain't all ☀️ and 🌈, but it just started with version 1.0 and will receive updates in future Gradle versions.

Build caching (docs)

Build Cache feature has been introduced already in Gradle 4.0, but Gradle 5.0 enables it in many more scenarios so it can rapidly speed up your build without not much effort (at least for your local builds).

Incremental Java compilation (docs)

Stable enough and it Just Works^TM!

Incremental annotation processing (docs)

Introduces new annotationProcessor configuration so Gradle can handle Java annotation processors correctly to avoid needless re-compilations. To make it work with Kotlin kapt annotation processors you need to use Kotlin 1.3.30 or newer. But don't forget that this feature must be first supported by annotation processor plugin itself.
Please read What's new in Android Gradle Plugin 3.5 post for more information about the history and proper configuration of incremental annotation processing with Java and Kotlin.

BOM support (docs)

Gradle 5.0 introduces a notion of a platform that is used for consuming Maven BOM files. This helps with introducing libraries like Firebase Android SDK where one need to be careful about selecting right components with compatible versions. With BOM support you can replace

dependencies {
  implementation("com.google.firebase:firebase-analytics:17.2.2")
  implementation("com.google.firebase:firebase-auth:19.2.0")
  implementation("com.google.firebase:firebase-firestore:21.3.1")
}

with

dependencies {
  implementation(platform("com.google.firebase:firebase-bom:24.5.0"))
  implementation("com.google.firebase:firebase-analytics")
  implementation("com.google.firebase:firebase-auth")
  implementation("com.google.firebase:firebase-firestore")
}

Periodic Gradle cache cleanup (docs)

Gradle binaries and project dependency artifacts in Gradle cache are checked every day and removed if not used for last 30 days. Neat!

And that's it! Stay tuned for the next posts por this series.