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.

[professeur shadoko]

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.

ben justement c'est parce que j'ai un outil qui essaye d'être un cas général: je ne vais pas m'en sortir s'il faut que je découvre les particularités des classes X ou Y de Java que les programmeurs vont avoir subitement envie d'utiliser comme emballage de leur propres codes.
Ou bien alors on dit que l'on ne doit jamais utiliser l'introspection de classe pour faire des outils généraux.
Après re-lecture des specs je persiste à dire qu'il y a ambiguité.

[thelvin]

Il n'y a pas ambiguïté dans la définition. Elle est ce que tu en as compris, point barre.
On pourrait estimer qu'il y a ambiguïté dans l'utilisation par les classes de l'API de base Java... Alors en général je dois avouer qu'en fait j'en sais rien, je me suis pas penché dessus.

Mais dans le cas d'ArrayList. C'est pas pour t'embêter le tableau transient. Il est comme ça parce qu'on va pas sauvegarder 300 pointeurs nulls additionnels pour persister une liste de 300 éléments. C'est logique d'un point de vue persistance, d'estimer que le tableau n'a pas à être persisté et qu'il vaut mieux persister le vrai contenu de la liste.
C'est une approche de génie logiciel parfaitement justifiée.

Malheureusement Java ne propose pas de système générique pour décrire la manière de persister des classes qui ne peuvent pas l'être de la façon classique. On peut lui en faire le reproche, mais au bout d'un moment un langage doit avoir un scope défini, et moi je dis 'faut pas pousser. En tout cas les difficultés du monde réel, ça a rien à voir avec la sémantique de transient.

Le fait que représenter automatiquement des objets bien fichus pour l'usage général, soit difficile et nécessite de tester les classes habituelles, ça t'arrange pas. Ben, dommage. On est avec toi mais ça a rien à voir avec de la sémantique.

[professeur shadoko]

Il n'y a pas ambiguïté dans la définition. Elle est ce que tu en as compris, point barre.

Mais dans le cas d'ArrayList. C'est pas pour t'embêter le tableau transient. Il est comme ça parce qu'on va pas sauvegarder 300 pointeurs nulls additionnels pour persister une liste de 300 éléments. C'est logique d'un point de vue persistance, d'estimer que le tableau n'a pas à être persisté et qu'il vaut mieux persister le vrai contenu de la liste.
C'est une approche de génie logiciel parfaitement justifiée..

tout à fait: cela m'avait un peu échappé dans le feu de l'action.
Pour la sémantique ambiguë tu me permettras de ne pas être d'accord .....

[Alkhan]

Bonjour,

Pour la sémantique ambiguë tu me permettras de ne pas être d'accord .....

franchement, je ne trouve aucune ambiguïté sur la définition de transient :

A keyword in the Java programming language that indicates that a field is not part of the serialized form of an object. When an object is serialized, the values of its transient fields are not included in the serial representation, while the values of its non-transient fields are included.

ce qui te pose réellement problème est plus la mécanique de la sérialisation qui peux faire appelle aux méthodes "writeObject" et "readObject" !

[professeur shadoko]

Bonjour,
franchement, je ne trouve aucune ambiguïté sur la définition de transient :

euh... sauf erreur ou omission de ma part ce n'est pas la définition donnée dans les specs du langage.
pourquoi je vois une ambiguité: on peut utiliser transient pour deux raisons:
- ça ne fait pas partie de l'état persistant de l'objet (définition de la spec): exemple : variables membres temporaires utilitaires (comme un stream)
- on veut pouvoir mettre en place une personnalisation de la persistence avec des opérations particulières d'écriture/reconstitution de l'objet (souvent utiisée dans le cas de la Serialization)
le problème de la Serialization c'est qu'elle part du principe qu'elle est la seule à avoir autorité en ce domaine : les méthodes readObject/writeObject partent du principe qu'on a on ObjectStream .... ce qui est bizarre.
La vraie logique serait d'avoir un "PersistenceDelegate" et c'est effectivement ce qui a été rajouté lorsqu'on a voulu créer XMLEncoder/decoder sauf que PersistenceDelegate est lui même défini dans le contexte des beans.
(bon je reconnais que je ne maitrise pas la manipulation des persistence delegates de java.beans pour l'utiliser dans un contexte où de nombreux objets ne sont pas des beans ... mais c'est peut-être possible: un tuyau?)