何度も書いてますが
「デメリット多いので個人的に絶対使いたくない」
のですが、ここ数年なぜかほぼ自分がメンテしているjson4sというScala向けのjsonライブラリがあります。
それの4.1.0リリースしました
json4sダメならじゃあ何がいいの?というと、ひとまずplay-jsonかcirceあたりでしょうか。 とにかくjson4sのようにreflectionでシリアライズ、デシリアライズする系は絶対避けましょう。
https://github.com/json4s/json4s/releases/tag/v4.1.0
なぜgithubではなくここに日本語で書いてるのか?というと、英語で書くの面倒というか、そもそも正確に差分見たかったらどうせgithubでdiff見ればいいとか、最近はAIがまとめてくれるだろうし・・・(そうか?)
json4sに限らないですが、メンテコストを極限まで下げつつ最低限のメンテをやろうとすると、真面目なリリースノート書くのを省略するのがコスパがいいので・・・
(雑なリリースノート書けばいいのでは?となるが、もう雑ならいっそのこと書かなくていいのでは?という気持ちになってしまう)
上記のような理由なので、メンテしてる割に差分があまり思い出せないのですが
- 4.0.0のリリースが2021年
- 4.0.x系の最新のリリースがこれ書いてる時点の2025年11月時点で2023年の4.0.7
と、だいぶ昔なわけですが・・・。
一応
- 4.0.x系のx部分変わってもバイナリ互換保つ
- 4.1.x系のx部分変わってもバイナリ互換保つ
とする想定です。これ https://github.com/lightbend-labs/mima 使って検査してるので。
逆に4.0.xから4.1.xは一部互換壊れてる可能性があります。
「そういう場合はメジャーバージョン上げて5.xにするんじゃないの?」
という派閥もあり得ますが、そのあたりはだいぶ適当というか、それ以前もはっきり決まってないので、なんとなく4.1.xにしました。
思い出せる範囲で非互換変更や重大な変更を列挙しておくと
- 他の人が持っていたjson4s.orgのドメインが失効したので、自分がそれ引き継ぐのもだるいので、mavenのgroupIdをorg.json4sからio.github.json4sに変えた
- 古いままでもpublish不可能ではないが、セキュリティ上それはまずいので
- どうせならpackage名も変えるべきだったか?と後から思ったがやってない。今後package名変更やるか未定
- リフレクションでのシリアライズとデシリアライズでScala 3対応した
- とりあえずテストは通るけど、パフォーマンスの懸念とか謎・・・
- compiler依存になるし、この問題があるので本当に使いたくない
- https://xuwei-k.hatenablog.com/entry/2024/06/17/091340
- 4.0.xにbackportするべきか悩んだが、まぁそろそろ4.1出しちゃえばいいか、とおもったので。今のところ4.0.xにはbackportしない、かも(詳細未定)
- extのmoduleからjoda-time分離した
- https://github.com/json4s/json4s/pull/1708
- 今時joda-time使うべきではないし、java.time部分使いたいだけなのにjodaの依存ついてくるのはうざいと思ったので
- とはいえ、java.time部分はtimezone保存されないとか、ミリ秒より細かい精度保持不可能とか、問題だらけなので、いずれにせよext部分というかjson4s自体の使用を絶対におすすめしないですが
- jacksonのversionが結構上がった
- jacksonが頻繁に微妙に互換壊したversionリリースするせいで(?)、世間ではjacksonのversion衝突が頻繁に起こって辛い
- 互換とセキュリティupdateを天秤にかけて、json4sの4.0.x系でjacksonどこまで上げていいのか謎問題
- json4sにはjacksonに依存せずに独自parseするmoduleもあるが、それはそれでなんか細かい部分の挙動が怪しくて、そっち使うのも怖いので、いずれにせよ辛いので、何度も言うけどjson4s使うのはやめよう
- 他にも何かやってる気がするけど思い出せない・・・(思い出したら追記するかも)
それで、4.1.xリリースしたので、master branchは4.2.xか5.xの開発、となるわけですが、(とはいえそれらの安定版をリリースするのは数年先?)、
ひとまず以下のようなことをやって、4.2.0-M1としてリリースしておきました。
- Scala 2.12を切り捨て
- https://github.com/json4s/json4s/pull/1717
- cross buildそんなに負荷でもないけど、いつかは切り捨てるべきだし、そろそろ頃合いじゃないでしょうかね
- それに伴う整理いくつか
- jacksonを2.xから3.xにupdate
- https://github.com/json4s/json4s/pull/1725
- groupIdもpackageも全部色々変わっていて、すごい互換壊れてる
- 一部対応が無理やり感があるというか、ひとまずテストは通ったけど、これでいいのか自信がない
- 丁寧にやるならjackson 2系と3系でcross buildするとか、そのためにrepository分ける?とかの選択肢もあり得るが、面倒なので今のところやる予定なし
- CIでのJavaの最低のversionを8から17に
- jackson 3が17以上必須なので
- どうせScala 3の次のLTSもそうなるし https://xuwei-k.hatenablog.com/entry/2025/03/06/095513
- jackson関係ない部分で(リリース時に)可能な範囲で8との互換を保つのかどうか?の詳細は未定
- deprecatedになってるmethodやclass一気に消した
今後、あと何するのか?などの詳細は未定というか、自分の気分次第ですが、ひとまず雑な報告でした。
そういえば "scala.reflect.Manifest" を使っていてScala 3で警告が出るのをどうにかするべきだけど、簡単にできるいい案が思いついてないまま、というのはありますね・・・。