Java : Jackson による JSON デシリアライズ時の型解決方法

Pocket

こんにちは。松本です。

ポリモーフィズムはオブジェクト指向言語の魅力のひとつですが、これがオブジェクトと JSON のマッピングを複雑にするなあと度々感じています。

汎化された型として定義されたプロパティ(フィールド)を持つオブジェクトを JSON からデシリアライズするには、型解決に関する定義やロジックをコードや設定として組み込むことになります。ここに、モデルクラスの設計と、JSON のエンティティ設計の間でトレードオフが発生することがあり、ケースに応じた最適な設計/実装が必要になるわけです。

私が扱うソフトウェアのライフサイクルの特性上、繰り返される追加開発に対し、保守性/拡張性を維持することは大きな関心ごとです。クラス関係の妥当性や理解しやすさ、変更時の影響範囲の抽出しやすさ、クラス数、コード量、実装難易度など、様々なトレードオフスライダーを頭に描きながら、最適だと考える選択を行います。

この「JSON デシリアライズ時の型解決」にどのような方式を採用するかという設計、実装も、そんな選択に頭を悩ますひとつなのです。

と、背景を説明すると少々大げさな書き出しになりましたが、JSON ライブラリの Jackson を使った型解決方法の選択肢をいくつかご紹介しようという記事です。

型解決に失敗するってどういうこと?

次のコードは Java + Jackson を使ったサンプルです。

shape フィールドの型が Shape インターフェースであり、実行時にバインディングされるのは、その実装クラスである Rectangle や Triangle のインスタンスです。

実行すると、シリアライズには成功しますが、デシリアライズは型解決ができずに失敗します。

例外メッセージにあるように、shape フィールドをデシリアライズしようとしたけど Shape は抽象型(インターフェース)だからインスタンス化できないよ!と怒っています。

このサンプルコードの場合、shape フィールドは Rectangle クラスのインスタンスとしてデシリアライズされるのが、期待する動作です。

【型解決方法1】 @JsonTypeInfo(use = Id.CLASS)

もっとも簡単お手軽な方法です。

先ほど型解決に失敗したサンプルコードを改造し、@JsonTypeInfo アノテーションを使って Shape インターフェースに型解決方法を定義しています。

@JsonTypeInfo アノテーションの use 属性に Id.CLASS を指定することで、Shape オブジェクトをシリアライズした JSON 内に "@class" というキーが追加され、その値として実装クラス名が書き出されます。デシリアライズ処理ではこの値に基づいて型解決が行われます。

実行結果はこれ。

クラス名が出力されてしまうことがセキュリティ面で良くないケースもありそうです。そこが問題にならないなら、実装クラスを追加してもコード変更の必要がなく、拡張性は良さそうです。

保守面を考えると、クラス設計変更を阻害する要因にもなるので注意が必要です。例えば実装クラスのクラス名が変更された場合、古いクラス名が使われた JSON をデシリアライズしようとすると、型解決に失敗してしまいます。

【型解決方法2】 @JsonTypeInfo(use = Id.NAME) + @JsonSubTypes

これも簡単な方法です。

型解決方法1との違いは、Shape インターフェースに付けられた @JsonTypeInfo アノテーションの use 属性値が Id.NAME に変わり、さらに @JsonSubTypes アノテーションが追加されたことです。

シリアライズ後の JSON 内に "@type" というキーが追加され、その値に識別名が書き出されます。デシリアライズ時の型解決は、@JsonSubTypes アノテーションに定義された識別名と実装クラス名のマッピングが使われます。

実行結果です。

型解決方法1と比べ、識別名を使うことによって保守性が高まり、セキュリティへの懸念も無くなっています。その引き換えとして、実装クラスが追加される度に @JsonSubTypes アノテーションにマッピングを追加しなければならなくなった点が面倒なところです。

この方法では @JsonSubTypes アノテーションの定義により、親クラス(ここではインターフェースである Shape)の定義内に、子クラス(実装クラス)への参照が出来てしまいます。この相互リンクが気になるなら、この方法はお勧めできません。子クラスが親クラスの内部クラスとして定義されているようなケースなら最適でしょう。

【型解決方法3】 @JsonTypeInfo(use = Id.NAME) + SubtypeResolver

型解決方法2と似ていますが、マッピングの定義に @JsonSubTypes を使わず、ObjectMapper オブジェクトに NamedType オブジェクトとして登録することで代替しています。

JSON へのシリアライズ結果は型解決方法2と同じです。

サンプルコードでは簡素化するため、NamedType オブジェクトを ObjectMapper オブジェクトに直接登録していますが、この NamedType オブジェクトは registerSubtypes() メソッド内部で SubtypeResolver オブジェクトに追加されます。デシリアライズ時の型解決は、この SubtypeResolver オブジェクトに設定された識別名と実装クラス名のマッピングが使われます。

実行結果です。

この方法では、型解決方法2で気になった相互リンク問題が解消します。また、識別名/実装クラス名のマッピング定義にアノテーションを使わないので、マッピングの設定を柔軟にできるというメリットがあります。

これを採用したクラスのシリアライズ/デシリアライズには、マッピングが定義された ObjectMapper オブジェクトを必ず使う、という実装ルールをどうやって徹底するかがポイントになります。

【型解決方法4】 @JsonTypeInfo + @JsonTypeIdResolver

多少、面倒ですが非常に柔軟な型解決方法です。

Shape インターフェースに @JsonTypeIdResolver アノテーションをつけ、型解決を担うクラスがどれであるかを定義しています(サンプルでは ShapeTypeIdResolver クラス)。

これも JSON へのシリアライズ結果は型解決方法2と同じです。

@JsonTypeIdResolver アノテーションで指定した TypeIdResolver の実装クラスの idFromValue() メソッドや idFromValueAndType() メソッドで実装クラスから ID への変換を行い、typeFromId() メソッドで ID から実装クラスの変換を行います。

ここで言う ID とは、@JsonTypeInfo アノテーションの use 属性の定義によって決定する情報で、サンプルでは "@type" キーに対する値として書き出された識別名のことです。

実行結果はこれです。

TypeIdResolver の実装クラスを作ることで型解決に関するロジックが書けるので、複雑な型解決にも最適です。その引き換えとしてコード量が多くなり、テストコードの作成量が増えてしまいます。

【型解決方法5】 ミックスイン

いわゆるミックスインです。

サンプルコードは MixIn クラスを使って型解決方法2と同じことを実現しています(サンプルでは ShapeMixIn クラス)。

型解決には、モデルクラス自身ではなく MixIn クラスに付けられたアノテーションが使われます。

ObjectMapper オブジェクトに MixIn クラスを登録するのを忘れないようにしましょう。これによって、ShapeMixIn クラスに付けられた @JsonTypeInfo アノテーションと @JsonSubTypes アノテーションが、まるで Shape インターフェースに付いているかのように動作します。

実行結果はこれ。

MixIn は、モデルクラスの設計と、JSON のエンティティ設計を分離でき、クラス設計がすっきりします。

サンプルには含めていませんが、モデルクラスのコンストラクタやメソッドにアノテーションを付けるようなケースも、MixIn クラスのコンストラクタやメソッドにアノテーションを付けることで代替できます(スタティックメソッドもミックスイン可能です)。

あえて難点を言えば、モデルクラスの拡張や変更に対し、MixIn クラスの変更を追随させなければならないケースがあることです。ここが、改修時の影響範囲として漏れないよう何らかの工夫が必要です。

モデルクラスにアノテーションがつけられない場合はどうすればいいの?

Java の基本 API や、外部ライブラリのクラスを汎化した型としてモデルクラスのプロパティ(フィールド)に定義するケースでは、少々工夫が必要です。

ここまでの型解決方法のほとんどが、対象となるモデルクラスに @JsonTypeInfo アノテーションを付けていました。しかし Java の基本 API や外部ライブラリに含まれるクラスにはアノテーションをつけることができません。ミックスインならこの点は解決しますが、ミックスインが使えないケースもありえます。

実は、@JsonTypeInfo アノテーションはプロパティ(フィールド)にも付けることが出来ます。つまり、対象プロパティ(フィールド)に定義を書けばいいわけです。

サンプルコードでは、field1 フィールドに対し @JsonTypeInfo アノテーションを追加しています。

同じ Object 型のフィールドである field1 と field2 に対し、main() メソッド内でともに Long 型の 100 を代入し、それをシリアライズしてからデシリアライズしています。

結果は次のようになります。

field1 は Long 型としてデシリアライズされ、field2 は Integer 型としてデシリアライズされています。これは、field1 に対して @JsonTypeInfo アノテーションで "@class" キーで実装クラス名を書き出すようにしたからです。

ここで肝となるのは、@JsonTypeInfo の include 属性に JsonTypeInfo.As.EXTERNAL_PROPERTY を指定することです。これによってキー ”@type” や "@class" が、対象プロパティ(フィールド)と同列のメンバーとして挿入されるようになります。

最後に

本文では触れませんでしたが、JSON に自動挿入される "@type" や “@class” といったキーは、@JsonTypeInfo アノテーションの property 属性で変更できます。セキュリティ面からも、この属性を使ってキーを変更しておいた方が良いでしょう。

Jackson には、ここで紹介しなかった型解決方法もいくつかあります。執筆当初は Serializer や Deserializer を使った型解決についても扱うつもりでしたが、記事が長くなりすぎたので諦めました。

それにしても、Java オブジェクトと JSON のマッピングもO/R マッピング同様で一筋縄ではいかないものです。

Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です