这个主要看Java项目所使用的Gradle的版本。
Gradle 3.4 新增了Java-library插件，java-library插件使用了新的依赖配置implementation和api。旧的依赖配置compile被废弃。
Gradle 3.4 之前的版本
java插件
apply plugin: 'java'
添加依赖
dependencies {
compile 'commons-httpclient:commons-httpclient:3.1'
compile 'org.apache.commons:commons-lang3:3.5'
}
Gradle 3.4+
使用java-library插件替换java插件
apply plugin: 'java-library'
新的依赖配置：implementation和api
dependencies {
api 'commons-httpclient:commons-httpclient:3.1'
implementation 'org.apache.commons:commons-lang3:3.5'
}
api和implementation两种依赖的不同点在于：它们声明的依赖其他模块是否能使用。
api：当其他模块依赖于此模块时，此模块使用api声明的依赖包是可以被其他模块使用。
implementation：当其他模块依赖此模块时，此模块使用implementation声明的依赖包只限于模块内部使用，不允许其他模块使用。
api： 跟 2.x 版本的 compile完全相同
implementation：使用了该命令编译的依赖，它仅仅对当前的Module提供接口。例如我们当前项目结构如下
LibraryA 中引用了 LibraryC 的库，如果对 LibraryC 的依赖用的是 implementation 关键字。 如下：
dependencies {
. . . .
implementation project（path：'：libraryC'）
}
那么LibraryC 中的接口，仅仅只能给 LibraryA 使用，而我们的 App Module 是无法访问到 LibraryC 提供的接口的，也就是将该依赖隐藏在内部，而不对外部公开。这就是implementation关键字的作用。
最佳实践建议
在Google IO 相关话题的中提到了一个建议，就是依赖首先应该设置为implement的，如果没有错，那就用implement，如果有错，那么使用api指令，这样会使编译速度有所增快。
那为什么要这么做呢？
答案是： 1. 加快编译速度。2. 隐藏对外不必要的接口。
为什么能加快编译速度呢？
这对于大型项目含有多个Module模块的， 以上图为例，比如我们改动 LibraryC 接口的相关代码，这时候编译只需要单独编译LibraryA模块就行， 如果使用的是api或者旧时代的compile，由于App Module 也可以访问到 LibraryC,所以 App Module部分也需要重新编译。当然这是在全编的情况下。
版本依赖关键字详解（2.0与3.0所有关键字）
compile（api）
这种是我们最常用的方式，使用该方式依赖的库将会参与编译和打包。
当我们依赖一些第三方的库时，可能会遇到com.android.support冲突的问题，就是因为开发者使用的compile依赖的com.android.support包，而他所依赖的包与我们本地所依赖的com.android.support包版本不一样，所以就会报All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes这个错误。
provided（compileOnly）
只在编译时有效，不会参与打包
可以在自己的module中使用该方式依赖一些比如com.android.support，gson这些使用者常用的库，避免冲突。
apk（runtimeOnly）
只在生成apk的时候参与打包，编译时不会参与，很少用。
testCompile（testImplementation）
testCompile 只在单元测试代码的编译以及最终打包测试apk时有效。
debugCompile（debugImplementation）
debugCompile 只在 debug 模式的编译和最终的 debug apk 打包时有效
releaseCompile（releaseImplementation）
Release compile仅仅针对 Release 模式的编译和最终的 Release apk 打包。
