Discussion :

[MinesesII]

Bonjour,

Je n'ai pas trouvé la réponse à ma question sur internet donc je viens vers vous pour éclaircir un problème que je rencontre.

J'ai mis en place une sérialisation d'une classe en vue de l'exporter dans un fichier.

J'ai fais pas mal de modifs sur cette classe depuis et maintenant je n'arrive plus à importer mes fichiers. Malheureusement, comme un idiot, je n'ai pas gardé l'ancienne version. Ce que je souhaite juste aujourd'hui c'est récupérer les variables (2 int et un tableau)qui sont contenues dans les fichiers afin de les réexporter avec le nouveaux formats.

Est-ce possible et comment ?

[divxdede]

Je n'ai jamais vraiment tenté l’expérience, mais je tenterais de procéder comme suit:

- Je fixerai un seralVersionUID dans ta classe correspondant à celui utilisé dans ton fichier. Tu dois pouvoir l'obtenir dans l'exception levée (au pire en debug)
- Aprés, je rendrais ma classe Externalizable et j'implémenterais mon readExternal() ou je ferais les readInt() et co dans le bon ordre (par rapport a ce qu'il y a dans ton fichier)

L'idéal aurait été d'avoir la version d'origine pour deseraliser. Il faut vraiment garder à l'esprit que la sérialisation n'est pas ce qui se fait de mieux pour les stockages de "longue durée"

[MinesesII]

Merci de ta réponse.

Que préconise tu pour le stockage de longue durée ?

[adiGuba]

Salut,

J'ai fais pas mal de modifs sur cette classe depuis et maintenant je n'arrive plus à importer mes fichiers.

Quels sont les modifications qui ont été apporté ?

Selon les cas le fait d'utiliser le même serialVersionUID devrait suffire, comme l'indique divxdede.
S'il n'est pas défini, la moindre modification mineure engendre un nouveau UID qui casse la compatibilité...

Que préconise tu pour le stockage de longue durée ?

Perso pour du long terme j'éviterais la sérialisation. Ca peut être casse-gueule à gérer.


Une solution en standard serait d'utiliser XmlEncoder, qui permet de transformer une classe en XML via le constructeur par défaut et les getter/setter.
Alors certes c'est toujours fortement lié à Java (nom de classes, type, etc.), mais cela reste du XML lisible par n'importe quel programme, et éventuellement modifiable par batch.


Mais perso j'aime bien utiliser le JSON. C'est encore plus léger et plus simple à "partager" entre différente application.
Il n'y a rien en standard mais la librairie Gson est très complète : https://sites.google.com/site/gson/gson-user-guide


Le gros avantage des format XML/JSON, c'est qu'il sont lisible par un humain, et donc facilement modifiable.
Le désavantage c'est que c'est un peu plus verbeux... mais cela se compresse plutôt pas mal donc tu peux coupler cela avec du GZIP par exemple



a++

[professeur shadoko]

Une solution en standard serait d'utiliser XmlEncoder, qui permet de transformer une classe en XML via le constructeur par défaut et les getter/setter.
Alors certes c'est toujours fortement lié à Java (nom de classes, type, etc.), mais cela reste du XML lisible par n'importe quel programme, et éventuellement modifiable par batch.


Mais perso j'aime bien utiliser le JSON. C'est encore plus léger et plus simple à "partager" entre différente application.
Il n'y a rien en standard mais la librairie Gson est très complète : https://sites.google.com/site/gson/gson-user-guide


Le gros avantage des format XML/JSON, c'est qu'il sont lisible par un humain, et donc facilement modifiable.
Le désavantage c'est que c'est un peu plus verbeux... mais cela se compresse plutôt pas mal donc tu peux coupler cela avec du GZIP par exemple

petit bémol toutefois: la doc de XMLEncoder est probablement une des plus déficientes de Java
faire des choses toutes simples avec des composants qui ne sont pas strictement des beans (ce qui est souhaitable dans bien des cas) peut demander de gros efforts de compréhension.
autre format: YAML (J'ai une légère allergie à JSON ... allez savoir pourquoi )
Ceci dit le format sérialisé comporte aussi des informations intéressantes qui permet de faire joujou avec les CLassLoader (cf. JINI)
(Pour des besoins internes j'ai developpé un autre format texte (de type clef=valeur -récursif-) qui marche très rapidement .... mais bon c'est pas du standard)

[thelvin]

petit bémol toutefois: la doc de XMLEncoder est probablement une des plus déficientes de Java
faire des choses toutes simples avec des composants qui ne sont pas strictement des beans (ce qui est souhaitable dans bien des cas) peut demander de gros efforts de compréhension.

Le but n'est pas de produire un format XML que l'on avait en tête, mais de faire une sérialisation qui sera en XML plutôt qu'en binaire opaque. Cela permet d'être plus robuste au changement, et au pire, de fabriquer des outils qui passent de l'un à l'autre sans difficulté.

Ce n'est pas ce dont on a l'habitude avec du XML, mais ça fait ce que ça doit faire. (Pour le coup, du JSON aurait été plus pertinent, mais ce n'était pas à la mode à l'époque.)

[professeur shadoko]

Le but n'est pas de produire un format XML que l'on avait en tête, ....

je le sais bien ... mais pour l'avoir utilisé pour faire des journalisations d'objets , je trouve que l'utilisation de XMLEncoder/decoder est très loin d'être évidente du fait d'une doc indigente.
par indigente je veux dire: la doc existe mais le rédacteur pense que l'on est au courant de tous les pourquoi et comment des mécanismes internes (les PersistenceDelegate sont croquignolets et il faut une sacré dose d'aspirine pour les utiliser correctement)

[thelvin]

Oui ben il arrive très vite un moment où ça ne suffit pas non plus et où il va falloir regarder les options plus élaborées de persistance. Personnellement cela ne m'étonnait pas.

[BorisTheBear]

Le XML/YML/JSON c'est bien quand on veut partager des infos avec des applis commerciales.

Sinon, fais ton propre format. Ou utilise une lib qui fais tout ( du genre Kryo )