建议json处理使用fastjson

[xiaohulu]

json处理既有gson，也有jackson，建议统一使用fastjson

[binarywang]

好建议，我之前也注意到，需要根据项目特点做个选择

[xiaohulu]

json lib, gson, jackson和fastjson，在项目中我是一路用过来的，无论是性能还是功能的完整性上，最后选型为fastjson.现在json处理组件，缺少一个类似日志的slf4j的标准接口，要是有这个库的话，具体实现就可以交由用户选择了。我现在项目中使用的是jackson，使用这个微信库之后，项目中就有三个json库了。

[binarywang]

感谢你的宝贵建议，如果有意向，可否加入我们的开发组进行相应的改造？

[xiaohulu]

可以，深感荣幸。

[binarywang]

@xiaohulu 你接受下邀请吧，查看邮件或访问组织首页。

[binarywang]

@xiaohulu 没动静了？请问最近有计划么？

[xiaohulu]

在想具体的调整方式。梳理清楚了就开始整。

[xusheng1987]

跟楼主一样的问题，用了这个工具，项目里同时存在三种json工具，fastjson，gson，jackson，建议统一成一个

[xiaohulu]

@xusheng1987 你建议使用哪个json工具呢？

本想彻底转换为fastjson，但是发现项目中有使用jackson转换xml文档的操作，看来使用jackson处理xml部分还要保留。

[binarywang]

jackson的代码我看了可以去掉，没问题。但就我个人来说，还是不太倾向于使用fastjson，主要是因为其javadoc精简到了极致，至少我看到的大部分都没有。不过也无所谓了，如果能让代码清晰易懂，还是值得的。

[xusheng1987]

@xiaohulu 我用的fastjson

[hbrls]

+1 实际用的是 fastjson

+1 的确找不到什么文档，万幸 API 命名比较易懂

[xiaohulu]

在重构过程中遇到了，使用gson注解的实体对象。本想让项目不依赖于具体的任何第三方实现，但是因为fastjson，jackson和gson都自己定义了一套注解类。只要使用任一注解，就必然依赖第三方类了。

大家有没有更好的办法呢？

[binarywang]

jackson的注解代码我看了是用于序列化使用的，去掉影响不大，gson的注解代码不能转换为fastjson的么？要不你把目前重构的代码push到某个位置，我们一起分析下看怎么做比较合适？

[xuyang2]

jackson是最稳妥的选择，为何要换fastjson？
那点些微的序列化反序列化的性能差异真的已经成为各位系统的性能瓶颈了吗？
https://mvnrepository.com/tags/json

[binarywang]

@xuyang2 确实jackson在国际上比较流行，具体差异也确实不太大，原项目最初使用的gson，jackson只是后来由于个别需求加入的。

[ft1226766]

@xiaohulu 如果你确实需要降低依赖，可以参考SpringMVC那些messageCoonverter的实现方式，即检测系统中是否存在fastjson，jackson或者gson的相关类，根据情况注册不同的messageCoonverter。这样处理以后，只有具体的messageCoonverter子类依赖fastjson，jackson或者gson，并且使用者可以注册自己的messageCoonverter，这样最灵活。

[xiaohulu]

@ft1226766 谢谢，这部分实现已经参考slf4j和springMVC的功能做到了，现在就剩下json注解，因为json注解是放在每个实体对象上的，无法做到彻底解耦依赖。

@xuyang2 主要工作不是替换掉谁，而是希望能做到让项目只依赖于公共接口，这样就支持任何一种json具体实现了。

现在遇到的困难是注解类的依赖，每个json库，都有自己的一套注解。大家有没有好的建议。

如果这块做不到的话，我的重构工作要放一放了，只要能做到将gson切换到jackson就可以了。

[binarywang]

@xiaohulu 我确认了下，jackson的注解是我之前自己为方便序列化转换微信自有的时间加入的，确实耦合性比较强，现在已经去掉了

[ft1226766]

@xiaohulu 目前Json没有标准注解，要完全去掉注解类的依赖，我想有个可行的办法是自己定义一套Json注解，自己解析注解，然后调用具体的JSON库实现功能，就可以自由切换到gson或者jackson，不需要再去修改注解了。

[aimilin6688]

最后是怎么处理的？

[binarywang]

既然没有好的方案，暂时关闭掉了

[Skqing]

fastjson +1