1

私は次の 2 つの JSON ライブラリを考えていました。

  • グーグル・グソン
  • JSON.Simple
  • Xストリーム

Google Gson は非常に優れており、引数のないコンストラクターを持つクラス オブジェクトをシリアル化できます。JSON.Simple は、非常に使いやすい API を備えています。ただし、シリアライゼーションとデシリアライゼーションの両方に関して、これらの JSON/オブジェクト マッピング ライブラリがどの程度壊れるか、つまり、オブジェクトをマーシャリングできなくなる可能性があります。

次のシナリオの場合:

  • クラスのネスト、つまりクラス内のクラスなど
  • クラス内のクラスの非常に長い文字列値とそのようなもの
  • オブジェクトのサイズ、つまり巨大なバイトを含むオブジェクト

マーシャリングがもはやそれを取ることができない、または壁にぶつかるシナリオは何ですか?

この種のフレームワークをアプリケーションのバックボーンとして使用する場合に何が問題になるかを理解するために、ここで大声で考えています。そして、発生する可能性のある潜在的な癖をどのように予測できるか。

アップデート：

また、移植性に関しては、特にオブジェクトの配布を扱う場合に、マーシャリング (非) 化についてどの程度対応できるかについてです。たとえば、「シリアル化された」オブジェクトは、異なる CPU、JVM などを使用して別のマシンを介して送信され、「逆シリアル化」されて何らかの方法で使用されることを意図しています。

4

1 に答える 1

0

ここには 2 つの制限があります。JSON の制限とマーシャリング ソフトウェアの制限です。

最初のものは明らかです：

  • JSON はグラフをシリアライズできません。JSON には「コンテンツ」しかないため、循環関係を JSON で作成することはできません。

コードの例:

class Bar { List<Drink> menu = new ArrayList<Drink>(); }
class Drink { List<Bar> servedIn = new ArrayList<Drink>(); }

public void main() {
    Bar b = new Bar();
    Drink whiskey = new Drink();
    b.menu.add(whiskey);
    whiskey.servedIn.add(b);
    serialize(b);
    // a naive serialization will keep serializing
    // a smart serialization will not include the Drink.servedIn field or throw an error
}

2 番目の制限は、マーサリング ソフトウェアとその構築方法によって異なります。簡単に言えば、オブジェクト グラフの 2 倍のメモリが必要になります。1 つはシリアル化されたフォーム用で、もう 1 つは非シリアル化されたフォーム用です。一部のパーサーはよりスマートで、メモリ要件を削減するストリーミングを提供します。

于 2013-04-03T09:19:27.593 に答える