Discussion :

[professeur shadoko]

Bonjour à toutes et à tous ....
La définition de "transient" dans les specs "Variables may be marked transient to indicate that they are not part of the persistent state of an object."
mais voilà: j'ai mon propre utilitaire pour une "Serialization" du pauvre (je passe sur les détails mais grosso-modo il s'agit d'offrir à des codes sur le réseau une vision "lisible" d'objets pour lesquels le ClassLoader local ne dispose pas de la classe).
Bien gentiment je ne prends pas en compte les champs de l'objet qui sont "transient" .... SAUF QUE
ça ne marche pas pour des objets comme ArrayList ....pourquoi? parce que les données contenues (en fait un tableau) sont marquées transient!
raison: celà permet au code de personnaliser la Serialization
sauf que j'estime que c'est une violation du contrat de "transient" (des données qui font partie de l'état persistant sont marquées ainsi!) ! : du coup ma propre "Serialization" ne marche pas!
Votre avis sur cette question?

[tchize_]

Pas pour moi. Le tableau ne fait pas partie de l'état persistent de l'arraylist. Et pour cause, l'état persistent de l'arraylist, c'est ce que fait writeObject plus bas dans la classe. Et le contrat par rapport à la sérialization dit bien que tu devrais utiliser ce writeObject.

[professeur shadoko]

Pas pour moi. Le tableau ne fait pas partie de l'état persistent de l'arraylist. Et pour cause, l'état persistent de l'arraylist, c'est ce que fait writeObject plus bas dans la classe. Et le contrat par rapport à la sérialization dit bien que tu devrais utiliser ce writeObject.

je me suis mal exprimé: je ne peux pas utiliser writeObject puisque je n'utilise pas d'ObjectOutputStream et je n'utilise pas la Serialization.
En d'autre termes: si tu as un système de persistence perso qui opére par introspection des objets tu ne peux pas te fier à "transient".
A mon pas très humble avis il y a un détournement de sémantique: les "trucs" de la Serialization devraient tenir compte des champs transient mais ne devraient pas créer de champ transient pour faire face aux besoins de personnalisation de l'E/S. Un champ qui fait fonctionnellement partie de l'état persistant mais qui aussi ne peut être sauvegardé "tel quel" (par exemple une référence à un autre objet qui sera remplacé par une information pour reconstituer de manière personnalisée le graphe à la lecture) devrait être certes manipulé par des codes spécifiques de persistance/serialization mais ne devrait pas être "transient" .
maintenant on peut arguer effectivement que le tableau en question est un détail interne de la réalisation et qu'alors une méthode devrait rendre des données permettant d'analyser l'objet pour reconstitution .... sauf que si tu n'es pas dans une optique de Serialisation/E/S standard tu es fichu.
Si je repars du problème de départ: j'ai besoin d'éclater certains objets (d'ailleurs pas forcément Serializable!) en une liste mot-clef/valeur simple (j'ai des critères pour en refuser certains qui sont alors Serializé à la mode "MarshalledObject"- s'ils sont Serializable-); ceci pour permettre l'accès en réseau à des informations décomposées (d'autres agents sur le réseau reconstituent ces objets à partir de leur état décomposé).
Bref quand mes utilisateurs m'ont envoyé des ArrayList -> on reçoit un objet vide.
Je fais quoi maintenant?

[tchize_]

La spec de transient te renvoie bien vers java.io.Serializable pour les détails de comment doit se comporter un service de persistence. Donc selon moi, tu devrais utiliser ObjectOutputStream. Rien ne t'empeche de faire ta propre implémentation plutot que d'utiliser celle par défaut.

Pour le reste, si tu persiste à vouloir joyeusement violer les objet en allant accéder à leurs tripes et leurs champs privés, autant ignorer le flag transient alors, ils ne te concerne pas selon moi :/

[professeur shadoko]

La spec de transient te renvoie bien vers java.io.Serializable pour les détails de comment doit se comporter un service de persistence. Donc selon moi, tu devrais utiliser ObjectOutputStream. Rien ne t'empeche de faire ta propre implémentation plutot que d'utiliser celle par défaut.

c'est exclu, le système n'a rien à voir avec un stream d'E/S

Pour le reste, si tu persiste à vouloir joyeusement violer les objet en allant accéder à leurs tripes et leurs champs privés, autant ignorer le flag transient alors, ils ne te concerne pas selon moi :/

il s'agit en effet d'un utilitaire assez général qui concerne toutefois des catégories particulières d'objets de diagnostic internes au projet. Comme il y a sur le projet une megach** de programmeurs je ne vais pas pouvoir faire un outil qui reprenne tous les cas possibles au cas pas cas (donc oui je les déshabille!).
Je persiste et signe dans mon affirmation que "transient" a une définition ambiguë qui concerne en fait deux aspects: partie de l'état persistant et champ faisant l'objet d'un traitement special au moment de la Serialization.
Dans le premier cas je ne peux pas ignorer le champ "transient" mais je peux pour le second cas.
Provisoirement j'ai fait ceci: si le champ est "transient" mais Serializable je le prends quand même.... mais c'est probablement pas général.

[thelvin]

En fait je vois pas spécialement pourquoi c'est transient que tu accuses. C'est les ArrayList qui marchent pas comme tu veux, pour la raison qu'elles utilisent transient.

Dans la mesure où les Collection (ni d'ailleurs aucun objet ou presque de l'API Java SE, reconnaissons-le) ne définissent pas leur comportement vis-à-vis de persistance, elles se contentent de faire de leur mieux eu égard au système de persistance qu'elles connaissent, c'est à dire Serializable : ça y marche parfaitement et elles bouffent pas de la place inutile pour le tableau de backing en faisant comme ça.

Si ce choix fait par une classe que tu n'as pas conçue toi-même ne te convient pas, tu peux toujours utiliser l'API de cette classe pour faire un cas particulier. Je ne vois pas le problème, et je ne vois pas en quoi le mot-clé transient dont cette classe ne t'a pas parlé une seule seconde, a quoi que ce soit à voir là-dedans.