前段时间写代码的时候想借助一下fastjson的Feature.OrderedField来解决json乱序的问题&＃xff0c;只需要增加一个参数即可&＃xff0c;像下面这样

JSON.parseObject("...", Feature.OrderedField)

&＃xff0c;idea检查是没有任何问题的&＃xff0c;但是跑单元测试的时候竟然报NoSuchFiledError(找不到Feature.OrderField)&＃xff0c;我猜测可能是jar包冲突了&＃xff0c;所以下一步就是找出到底是和哪个jar包冲突了。

解决方法一

最开始我以为是maven传递依赖了老版本的fastjson包&＃xff0c;所以我尝试使用“mvn dependency:tree”来输出项目中的所有jar包依赖一看究竟&＃xff0c;但是结果让人大跌眼镜&＃xff0c;整个项目只依赖了1.2.58版本的fastjson包&＃xff0c;传递依赖的猜测随之破灭。

解决方法二

我仔细分析了报错的堆栈信息&＃xff0c;报错只是说Field找不到&＃xff0c;但是Field所属的Class是可以找到的&＃xff0c;那有没有一种办法可以通过Class找到所属的jar包呢&＃xff1f;最终通过度娘找到了一种办法&＃xff0c;贴出来供大家使用

try{  JSON.parseObject("...", Feature.OrderedField)}catch(Throwable e){    String loc &＃61; "";     String urlLoc &＃61; "";     try {           loc &＃61;              Feature.class.getProtectionDomain().getCodeSource().getLocation().getFile();      urlLoc &＃61;  URLDecoder.decode(loc, "UTF-8");   } catch (Throwable e2) {        }        logger.info("** loc&＃61;" &＃43; LOCATION &＃43; "; URLLoc&＃61;" &＃43; URLLOCATION);}

水落石出

最终找到了导致冲突的jar原来是公司自研的消息队列提供的producer client&＃xff0c;在这个jar包内部将fastjson的源码直接打到了jar包里面&＃xff0c;所以在不同的jar包内竟然出现了包名和类名都一样的class&＃xff0c;下面这个图是jar包内部的目录结构&＃xff0c;这种使用第三方工具包的方式我也是第一次见&＃xff0c;感觉挺坑的(耦合太严重)&＃xff0c;最终我没有使用fastjson来解决我的问题&＃xff0c;而是借助了Gson将这个问题绕过去了。

总结

主要介绍了两种找出冲突jar包的方式&＃xff0c;第一种是使用“mvn dependency:tree”的方式&＃xff0c;但是这种方式存在局限性&＃xff0c;就像前面说到的那种&＃xff0c;两个看似不相干的jar包内竟然出现了包名和类名都一样的class&＃xff0c;第二种是直接通过class对象获取jar包全路径的方式&＃xff0c;这种方式更通用&＃xff0c;但是需要改动一点代码。