我在网上找不到我的问题的答案(也许我搜索得不够好,因为我仍然是这方面的新手)。
谁能告诉我Jackson和Gson是否实现了标准JSR 353: Java™ API for JSON Processing。我想使用标准代码编写。
这个链接有回复(显然是杰克逊创始人),它基本上说杰克逊没有实现 JSR:
Tatu Saloranta 于 2014 年 1 月 26 日晚上 8:21 回复
我不是 JSR-353 的忠实粉丝(我认为这是一个很大的失败),除非发生严重的事情,否则 Jackson 核心不会实现 JSR-353。使用数据绑定没有任何好处;既因为实现没有带来任何东西(没有一个特别快),也没有实现所有数据绑定需求(base64编码,多格式支持功能) - 最糟糕的是所有现有(反)序列化器需要重写使用新的,功能较弱的 API。Jackson 的基线需要成为 Java 8。所以我看不出有什么好处。
然而,反过来也是可能的;可以有一个基于 Jackson 流包的 JSR-353 实现,这已经完成了:
https://github.com/pgelinas/jackson-javax-json。
或者,为了使 Jackson 能够读取/写入 JSR-353 JSON 对象类型,需要一个简单的数据类型模块。前段时间我写了一篇:
https://github.com/FasterXML/jackson-datatype-jsr353
因此,如果 Java 开发人员最终遵循“标准”轨道,Jackson 也可以继续前进。
谷歌没有(不能?)对 JSR 投票,我也找不到Gson 的路线图上的任何内容表明他们愿意遵守。
利用:
其他两个答案是正确的,但已过时。正如他们所解释的,Jackson 没有直接实现任何 JSR。
然而:
因此,您现在确实可以使用 Jackson 以外的 JSON 库编写标准代码。
不,既不本地实现此 API,也没有计划(据我所知)来实现它。就 JCP 标准而言,这就是 DOA;它提供的东西很少(简化的流式 API,根本没有数据绑定),而且几乎没有任何人实现它的动机,除了为已实现的 JSR 集添加兼容性复选框。
https://github.com/pgelinas/jackson-javax-json/上提供了一个基于 Jackson 的 JSR-353 实现,但是,如果您真的认为基于此 API 编写代码是个好主意。