Quelle est la meilleure alternative à la sérialisation Java?

Question

Je suis actuellement en train de travailler sur un projet qui doit persister toute sorte d'objets (dont la mise en œuvre, nous n'avons pas le contrôle) de sorte que ces objets pourraient être récupérés par la suite.

Nous ne pouvons pas mettre en œuvre un ORM parce que nous ne pouvons pas empêcher les utilisateurs de notre bibliothèque à temps de développement.

Notre première solution consistait à sérialiser avec le Java de sérialisation par défaut, mais nous avons eu beaucoup de difficultés à récupérer les objets lorsque les utilisateurs ont commencé à passer à des versions différentes d'un même objet (attributs changé les types, les noms, ...).

Nous avons essayé avec le XMLEncoder classe (transforme un objet en XML), mais nous avons découvert qu'il y est un manque de fonctionnalité (ne prend pas en charge les Énumérations, par exemple).

Enfin, nous avons également tenté de JAXB mais c'imposer à nos utilisateurs d'annoter leurs classes.

Toute bonne alternative?

Answer 1

C'est en 2011, et dans une classe commerciale de services web REST projet, nous utilisons les sérialiseurs à offrir à ses clients une variété de types de médias:

• XStream (pour XML, mais pas pour le JSON)
• Jackson (JSON)
• Kryo (un rapide, compact binaire format de sérialisation)
• Sourire (un format binaire qui vient avec Jackson 1.6 et versions ultérieures).
• Java Sérialisation D'Un Objet.

Nous avons expérimenté avec d'autres sérialiseurs récemment:

• SimpleXML semble solide, fonctionne à 2x la vitesse de XStream, mais nécessite un peu trop de configuration pour notre situation.
• YamlBeans avait quelques bugs.
• SnakeYAML eu un petit bug concernant les dates.

Jackson JSON, Kryo, et Jackson Sourire étaient tous significativement plus rapide que le bon vieux Java Sérialisation d'un Objet, d'environ 3 à 4,5 x. XStream est lent sur le côté. Mais ce sont tous des solides de choix à ce stade. Nous allons continuer de surveiller les trois autres.

Answer 2

http://xstream.codehaus.org/ est sympa.

Answer 3

dont la mise en œuvre, nous n'avons aucun contrôle

La solution est de ne pas le faire. Si vous n'avez pas le contrôle d'un type de mise en œuvre, vous ne devriez pas être serialising il. Fin de l'histoire. La sérialisation Java fournit serialVersionUID spécifiquement pour la gestion de la sérialisation des incompatibilités entre les différentes versions d'un même type. Si vous n'avez pas le contrôle de la mise en œuvre vous ne pouvez pas être sûr que les Id sont modifiées correctement lorsqu'un développeur changements de classe.

Prenons un exemple simple d'un "Point". Il peut être représenté par un cartésien ou polaire système de coordonnées. Il serait d'un coût prohibitif pour vous de construire un système qui peut permettre de faire face de manière dynamique avec ces sortes de corrections - il vraiment être le développeur de la classe, qui conçoit la sérialisation.

Bref, c'est votre conception qui est faux - et non la technologie.

Answer 4

La chose la plus facile pour vous de faire est encore d'utiliser la sérialisation, l'OMI, mais mettre plus de pensée dans la forme sérialisée des classes (que vous devriez vraiment faire de toute façon). Par exemple:

1. Définir de façon explicite les SerialUID.
2. Définir votre propre forme sérialisée, le cas échéant.

La forme sérialisée fait partie de la classe de l'API et de réflexion doit être mis dans sa conception.

Je ne vais pas entrer dans beaucoup de détails, car presque tout ce que j'ai dit vient de Efficace Java. Je vais plutôt vous référer à elle, spécialement les chapitres sur la Sérialisation. Il vous prévient de tous les problèmes que vous rencontrez, et fournit des solutions à ce problème:

http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683

---

Avec cela étant dit, si vous êtes encore en train d'examiner un non-sérialisation approche, ici sont un couple:

Sérialisation XML

Comme beaucoup l'ont souligné, c'est une option, mais je pense que vous devez toujours exécuter dans les mêmes problèmes de compatibilité. Cependant, avec le XML de l'ordonnancement, vous aurez espérons attraper ces tout de suite, puisque certains cadres peuvent faire quelques vérifications pour vous lors de l'initialisation.

La Conversion vers/à partir de YAML

C'est une idée que j'ai joué avec, mais j'ai vraiment aimé le format YAML (au moins comme une coutume toString() de format). Mais vraiment, la seule différence pour vous, c'est que vous seriez le regroupement pour YAML au lieu de XML. Le seul avantage, c'est que le YAML est un peu plus lisible que XML. Les mêmes restrictions s'appliquent.

Answer 5

google a mis au point un protocole binaire - http://code.google.com/apis/protocolbuffers/ est plus rapide, sa charge utile est inférieure à celle de XML - ce que d’autres ont suggéré comme solution de rechange.

L’un des avantages des tampons de protocole est qu’il peut échanger des informations avec C, C ++, Python et Java.