不要輕易在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包

參考資料

https://stackoverflow.com/questions/52363536/java-lang-nosuchmethoderror-com-google-common-collect-immutablesortedset-toimmu/52363643