使用net.ltgt.errorprone等组件突发java.lang.NoSuchMethodError编译异常求助

突然全员触发编译异常，这种情况大概率是依赖缓存损坏、老版本组件间的隐性兼容性冲突，或者依赖版本意外变更导致的。结合你用的这套比较老旧的技术栈，我整理了几个实用的排查方向：

1. 先清理Gradle缓存，排除缓存损坏问题 #

所有开发者同时出问题，有可能是团队共享的依赖镜像出了问题，或者本地缓存同步时损坏了。可以先试试强制清理缓存重新构建：

./gradlew clean build --no-build-cache

要是还不行，手动删除本地Gradle缓存目录（比如~/.gradle/caches），再重新拉取依赖编译，很多时候这类突发问题都是缓存搞的鬼。

2. 临时禁用ErrorProne，定位问题根源 #

ErrorProne 0.0.8是2017年的老版本，和JDK 1.8.0_162可能存在未被发现的兼容性触发点。你可以在build.gradle里注释掉ErrorProne的相关配置，然后执行：

./gradlew compileJava

如果编译能正常通过，那问题肯定出在ErrorProne和当前JDK/Guava的交互上，接下来就可以针对性处理ErrorProne的问题。

3. 检查依赖树，确认版本是否被意外变更 #

看看项目里有没有用动态版本依赖（比如没写死具体版本号的依赖），或者依赖锁定文件（如果有的话）是否被修改。执行下面的命令生成完整依赖树：

./gradlew dependencies

仔细核对Guava 21和ErrorProne 0.0.8的实际引入版本，有没有被其他依赖悄悄升级或者替换，这种隐性的版本冲突很容易触发编译器崩溃。

4. 尝试升级ErrorProne到兼容的较新版本 #

0.0.8版本实在太老了，后续版本修复了大量编译器兼容性问题。你可以试试升级到0.0.19版本（这个版本对Gradle 3.x支持比较好），修改build.gradle里的插件配置：

plugins {
    id "net.ltgt.errorprone" version "0.0.19"
}

升级后重新编译，大概率能解决老版本的兼容性问题。

5. 抓取详细编译日志，定位具体崩溃点 #

你提供的错误提示是通用的编译器异常，没有具体堆栈信息很难精准排查。可以用--info参数开启详细日志：

./gradlew compileJava --info

找到异常的完整堆栈跟踪，看看是哪个类、哪个注解或者哪个检查规则触发了编译器崩溃，这会帮你快速锁定问题所在。

另外附上你遇到的错误提示：

[system.err] 编译器(1.8.0_162)发生异常。请先在Bug Database中检查是否有重复问题，再通过Java错误报告页面提交Java编译器的Bug报告，并附上相关环境、代码等信息

内容的提问来源于stack exchange，提问作者srikant