不要轻易在java ext 目录放任何三方jar包
今天在编写一个简单spi 应用demo的时候，在编译时总有一个其他的错误，如下：
ERROR Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project userloginspi: Fatal error compiling: java.lang.NoSuchMethodError: com.google.common.collect.ImmutableSet.toImmutableSet()Ljava/util/stream/Collector; -> [Help 1] (org.apache.maven.cli.MavenCli:1091)
因为这个插件一直使用 ，而且类似的代码也写过不可能出问题的，首先怀疑的是maven 工具，但是发现没问题，这个错误的提示实际上是一个guava 包版本的问题，但是项目依赖的guava 已经包含功能了，而且很高了，尝试过以下几个调试
解决流程
- maven 构建提启用调试
添加-X 发现依赖的包包含代码，没有问题 - 只能google了
大家的说法都是guava 版本，突然看到有人说，guava 已经在classpath了，实际上错误也符合，然后突然想起，当时为了测试yugabytedb 的cdc 功能
在ext 目录copy 了一个jar 包，因为guava 包在java 开发中如此的方便，基本都会依赖的，删除jar包 ，重新运行问题解决
说明
一般放置三方jar 包到java 的ext 目录，仔细阅读下jar包实现的功能吧，不然排查起来问额就太费事了，折腾了好几个小时，还好最后解决了。
一个经验教训：不要轻易在java ext 目录放任何三方jar包
