Why Android change 'compile' to 'implementation' configuration in Gradle dependencies?

Question

As seen in Android Studio 3.0 (canary 3.0), we now add depedencies by declaring implementation instead of compile configuration.

// Before
compile 'com.android.support:appcompat-v7:25.3.1'

// Currently
implementation 'com.android.support:appcompat-v7:25.3.1'

We can still use compile, but I would like to understand:

• What is the difference between implementation and compile configuration?
• Why do Android Gradle build change to use implementation as default?

Answer 1

Thanks to the really useful link from @petter, I would like to add a summary as following.

It means that Android Gradle build starts to use the java-library plugin instead of its previous java plugin. This plugin introduces the exposed API concept with two configuration to declare dependencies.

1. api

should be used to declare dependencies which are exported by the library API

For example, in a case that you are building a Java (or Android) library which is used by other apps. If you use any third-party library and you want to expose its API to your library's consumer also, you should declare like this.

api 'commons-httpclient:commons-httpclient:3.1'

2. implementation

should be used to declare dependencies which are internal to the component.

When developing Android app, our app module is the end point which does not need to expose any part externally. implementation should be used.

implementation 'org.apache.commons:commons-lang3:3.5'

The previous compile configuration works the same as api. The implementation, however, brings the following benefits.

• dependencies do not leak into the compile classpath of consumers anymore, so you will never accidently depend on a transitive dependency
• faster compilation thanks to reduced classpath size
• less recompilations when implementation dependencies change: consumers would not need to be recompiled
• cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that
  distinguish exactly between what is required to compile against the
  library and what is required to use the library at runtime (in other words, don't mix what is needed to compile the library itself and
  what is needed to compile against the library).