lift-jsonの代わりにjson4sを使うべき？

scala

http://github.com/json4s/json4s

READMEの先頭だけ訳

java の json ライブラリを除いて、現在少なくとも6つのjsonライブラリが存在します。そして、それらのライブラリのAST*1は、とても似ています。このプロジェクトの狙いは、それらのscalaのjsonライブラリから使える、一つのASTを提供することです。

今後最終的にどうなるのかよくわかりませんが、「jsonのライブラリいっぱいあるし、統一的に扱いたいよね？」的な感じらしいです。まだ2012年8月くらいから作り始めたばかりで、比較的新しいです。


そして、READMEの続きや、ソースコード見てもらうとわかると思いますが、実際はほぼコアの部分がlift-jsonそのものです。scalazのモジュールも、現状はlift-jsonのscalazの部分を持ってきただけのようです。あと、ドキュメントもlift-jsonそのままコピペしてある部分があって*2、まだこのblog書いている時点ではちゃんと整理されてないようです。


だがしかし、lift-jsonにおいて
JFieldはJValueを継承するべきではない！
わけですが、その点が改善されています。
個人的には、この点が改善されているというだけでも、json4sを使う利点がある気がします。*3

その、「JFieldはJValueを継承するべきではない！」問題は、一年くらい前からわかっていたのに、lift-jsonのmasterには*4結局まだ取り入れられてないです。以下、そのあたりの議論の参考リンク

そして、実際に試してないので現状どのくらい使えるのかよくわかりませんが、MongoDBのBSON用のモジュールもあって
https://github.com/json4s/json4s/tree/623b4c47d1d1b59330a7713045a4bf2a0afe9b24/mongo/src/main/scala/org/json4s/mongo
そのあたりも統一的に扱えるようにする狙いがあるようです。


あと、すでに、最新のdispatchに、json4sのモジュールがあります。

https://github.com/dispatch/reboot/blob/0.9.3/project/build.scala#L26-32

追記:
salatというライブラリも、lift-jsonからjson4sに移行したようです

https://github.com/novus/salat/commit/285b555dc1bb1eadebce13572d60de598cdd12b9

他にも

https://groups.google.com/d/topic/scala-user/UFuskXHE4zQ/discussion

今後

  • lift自体からは、jsonのモジュールがなくなって、このjson4sに依存するようになるのか*5
  • lift-jsonとjson4sがそれぞれ別々に進化するのか？

はよくわかりません。*6

まだそれほど多く使われてないし、ドキュメント未整備な部分があったり、ソースコードも単にコメントアウトされてるだけの部分が少し残っていたり、今後の方針がいまいちよくわからない部分もありますが*7
作ってる人はScalatraのコミッターで有名な人だったり、すでにdispatchにおいて採用されていたり、まぁそもそも現状コア部分はlift-jsonそのものなので、そういう意味では信頼おけるし、
今後どうなるか(みんなlift-jsonの代わりにjson4s使うようになるのか？)、かなり注目するべきライブラリな気がします。

*1:訳注: abstract syntax tree 抽象構文木

*2:まぁコアがlift-jsonそのものなので、べつにそれで構わないといえばそうなのですが

*3:逆に現時点では、それ以外の明確な利点が具体的にはよくわかってないんですが(複数のjsonライブラリを使うときとか、それを抽象化したいときとか便利なんだろうか？)、誰かそのあたり解説してください・・・

*4:まぁ互換性壊れるので

*5:現状そんな話は全くでていないようですが

*6: 個人的には、ほとんど同じなのに別々に進化するのは微妙だから、liftからjsonの部分完全に切り離して、liftがjson4sに依存が望ましい気もするけど・・・？

*7: もしかすると、それとも現状で大体完成で、たいして変更する気ないんだろうか？