導讀:工程編譯的時候好好地,怎么一運行就報各種的NoSuch***Error,猜測可能是jar包沖突了,但是究竟是和哪個jar包沖突了呢。
關鍵詞:jar包沖突,NoSuchFileldError,NoSuchMethodError
問題背景
前段時間寫代碼的時候想借助一下fastjson的Feature.OrderedField來解決json亂序的問題,只需要增加一個參數即可,像下面這樣
JSON.parseObject("...", Feature.OrderedField)
,idea檢查是沒有任何問題的,但是跑單元測試的時候竟然報NoSuchFiledError(找不到Feature.OrderField),我猜測可能是jar包沖突了,所以下一步就是找出到底是和哪個jar包沖突了。
解決方法一
最開始我以為是maven傳遞依賴了老版本的fastjson包,所有我嘗試使用“mvn dependency:tree”來輸出項目中的所有jar包依賴一看究竟,但是結果讓人大跌眼鏡,整個項目只依賴了1.2.58版本的fastjson包,傳遞依賴的猜測隨之破滅。
解決方法二
我仔細分析了報錯的堆棧信息,報錯只是說Field找不到,但是Field所屬的Class是可以找到的,那有沒有一種辦法可以通過Class找到所屬的jar包呢?最終通過度娘找到了一種辦法,貼出來供大家使用
try{
JSON.parseObject("...", Feature.OrderedField)
}catch(Throwable e){
String loc = "";
String urlLoc = "";
try {
loc =
Feature.class.getProtectionDomain().getCodeSource().getLocation().getFile();
urlLoc = URLDecoder.decode(loc, "UTF-8");
} catch (Throwable e2) {
}
logger.info("** loc=" + LOCATION + "; URLLoc=" + URLLOCATION);
}
水落石出
最終找到了導致沖突的jar原來是公司自研的消息隊列提供的producer client,在這個jar包內部將fastjson的源碼直接打到了jar包里面,所以在不同的jar包內竟然出現了包名和類名都一樣的class,下面這個圖是jar包內部的目錄結構,這種使用第三方工具包的方式我也是第一次見,感覺挺坑的(耦合太嚴重),最終我沒有使用fastjson來解決我的問題,而是借助了Gson將這個問題繞過去了。

總結
主要介紹了兩種找出沖突jar包的方式,第一種是使用“mvn dependency:tree”的方式,但是這種方式存在局限性,就像前面說到的那種,兩個看似不相干的jar包內竟然出現了包名和類名都一樣的class,第二種是直接通過class對象獲取jar包全路徑的方式,這種方式更通用,但是需要改動一點代碼。
十一假期最后一天,祝大家返程愉快,如果覺得對你有用,請點一下推薦。
