Jackson替换fastjson的几个坑

最近fastjson漏洞频出，于是公司要求将所有的应用fastjson引用都换成jackson。这期间改造了大量应用，踩出来的坑珠峰倒进去估计也填不满。

首先是fastjson本身的一些小问题，由于其封装度很高，写起来比较偷懒。老应用中很多同事的偷懒写法，改的我几乎吐血。例如JSONArray，看似是对JSON对象的数组的封装，实际上什么都能放，就是一个List<Object>，众所周知泛型写Object是最偷懒的写法，对后来者实在是太不友好了。。。遇到JSONArray的使用，改造时只能先写成List<Object>，再小心翼翼的根据上下文，转换出具体类型。

说到类型转换，就不得不提JSONObject特别亲民的一系列getString()，getBigDecimal接口，写起来那叫一个方便。老应用中RESTFul接口的RequestBody也不定义Bean，直接JSONObject接着就完事，想用String就getString，当JSONObject被替换成Map的时候，再转String就不能直接用类型转换了，因为getString是兼容了其他不是String的类型的，当然也不能用String.valueOf方法，因为null类型的处理会有偏差。所以遇到这种情况，只能乖乖的自己写一个类型转换的工具类。每次看到这种情况，我真的很想把开发的老哥揪回来问一句，你定义一个bean不香吗？

说到香，就不得不再说说我们新的真香--Jackson。fastjson在中文互联网之所以流行，顾名思义，它非常的fast。我做了一个简单的测试，分别使用fastjson和jackson，将一个Map转换成json字符串，测试结果如下

1.png

偶买噶，性能也相差无几。当然需要注意的是，自己封装jackson的工具类时，ObjectMapper最好写成单例，不然性能差不多会低上10倍吧。工具类的更换比业务逻辑的修改更容易踩坑。

说到坑，就不得不提Jackson的几个坑。在json字符串转换成bean时，jackson默认是大小写敏感的，也就是说，如果json中字段名是User，而bean的字段名是user，Jackson是不认识的，直接抛异常。解决起来倒是不复杂，ObjectMapper添加配置:
ObjectMapper mapper = new ObjectMapper();
mapper.configure(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES,true);

此外，当json中的字段，bean中不存在时，jackson并不会忽略它，默认是抛出异常。稍微有点违反直觉。通过加配置也能解决：
ObjectMapper mapper = new ObjectMapper();
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);