IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Java Discussion :

Problème avec la sémantique de "transient"


Sujet :

Langage Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 76
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Par défaut Problème avec la sémantique de "transient"
    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?

  2. #2
    Expert éminent
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 482
    Par défaut
    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.

  3. #3
    Membre Expert
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 76
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Par défaut
    Citation Envoyé par tchize_ Voir le message
    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?

  4. #4
    Expert éminent
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 482
    Par défaut
    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 :/

  5. #5
    Membre Expert
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 76
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Par défaut
    Citation Envoyé par tchize_ Voir le message
    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.

  6. #6
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 582
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 582
    Par défaut
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

Discussions similaires

  1. Formulaires : problème avec les slashes et les quotes
    Par GarGamel55 dans le forum Langage
    Réponses: 1
    Dernier message: 12/10/2005, 15h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo