Gradle 5.0: How to Fix Deprecated Features and Update a Kotlin Project

Why is Gradle Crying "Deprecated Features" and What to Do About It?

Have you ever launched a Kotlin project build and seen a frightening message: Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0? If so, you are not alone. This question has gathered thousands of views on Stack Overflow, and today we will analyze it inside and out.

Imagine: you are writing in Kotlin, everything works, but Gradle suddenly starts being fussy. It says: "Hey, you are using old features that I will remove in version 5.0!". It's like your favorite coffee machine telling you that tomorrow it will stop accepting old cups. Unpleasant, but solvable.

In this article, we will not just show how to remove the error. We will compare three approaches to the solution: from a quick "patch" to professional refactoring. You will learn why Gradle considers your code deprecated and how to rewrite it in a modern way.

What are Deprecated Features in Gradle?

Deprecated features are those parts of the API that the Gradle developers plan to remove in the future. They are left for backward compatibility, but it is no longer recommended to use them. When you see this warning, Gradle is literally saying: "Your project will build now, but after updating to version 5.0 — it won't."

Most often, the problem lies in:

\n
• Outdated plugins (e.g., old versions of kotlin-gradle-plugin)
\n
• Implicit dependencies (using compile instead of implementation)
\n
• Groovy scripts that are not adapted for Kotlin DSL
\n
• Direct calls to deprecated methods in build.gradle
\n

Approach 1: Quick Fix — Suppressing Warnings

The simplest (but not the most correct) path is to just tell Gradle: "Shut up and work." It's like taping over the Check Engine light with duct tape. The car will drive, but the problems remain.

Add the following block to build.gradle.kts (Kotlin DSL):

tasks.withType<Wrapper> {\n    gradleVersion = "4.10.3" // freezing the version\n}\n\n// Or suppressing the warning\nallprojects {\n    tasks.withType<AbstractCompile> {\n        options.isDeprecation = false\n    }\n}

Pros: fast, requires no code changes, the build passes.

Cons: you are not solving the problem, just postponing it. When migrating to Gradle 5.0+, the project will break. Additionally, you miss important performance and security improvements.

When to use: only if you urgently need to build the project and have no time for refactoring. But be sure to schedule a proper solution.

Approach 2: Migration to Modern Configurations

This is the "sweet spot." You are not just plugging the error, but putting the project in order. Let's break down typical problems using a Kotlin project as an example.

Replacing compile with implementation/api

The old way of declaring dependencies — compile — was deprecated back in Gradle 3.0. Instead, use implementation and api.

Was (Groovy):

dependencies {\n    compile 'org.jetbrains.kotlin:kotlin-stdlib:1.3.72'\n    compile 'com.squareup.retrofit2:retrofit:2.9.0'\n}

Now (Kotlin DSL):

dependencies {\n    implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.0")\n    implementation("com.squareup.retrofit2:retrofit:2.9.0")\n}

The difference is simple: implementation hides the dependency from module consumers, speeding up the build. api makes it visible, like the old compile.

Updating the Kotlin Plugin

Old versions of kotlin-gradle-plugin often use deprecated Gradle API. Check the current version on kotlinlang.org and update