Jackson は、一般的なシナリオと、注釈サポートのための優れた設計の選択を好む傾向があります。
あなたのケースは非常にまれなシナリオです。異なるコンテキストで 2 つの異なる意味を持つ 1 つのフィールドがあります。通常、これは、相手側の消費者に厄介なロジックを追加するため、好ましいデータ形式ではありません...それぞれの場合に「Json」プロパティが何を意味するかを判断する必要があります。2 つの異なるプロパティ名を使用するだけで、消費者にとってよりクリーンになります。次に、各プロパティの存在をチェックするだけで、取得している代替を知ることができます。
Java クラスの設計も不十分のようです。クラスは、あるコンテキストではフィールドが許可されているが、別のコンテキストでは許可されていない、このタイプのコンテキストまたはモードを持つべきではありません。
これは主にデザインの匂いであり、シリアル化ロジックではないため、Java クラス階層を修正するのが最善の方法でしょう。
class BaseClass {
}
class SubClassWithItems {
public List<TwoDArrayItem> getItems() {
return items;
}
@JsonProperty("Json")
public void setItems(List<TwoDArrayItem> items) {
this.items = items;
}
}
class SubClassWithType {
public String getType() {
return type;
}
@JsonProperty("Json")
public void setType(String type) {
this.type = type;
}
}
そうすれば、実行時の状態に基づいて、クラスに異なるフィールドのセットがありません。ランタイム状態がクラスに含まれるフィールドを駆動している場合、Map
.
それを変更できない場合は、カスタムのシリアライゼーションが残っています。