bonjour,
 
J'aurais besoin de savoir si un objet que l'on me passe en paramètre est Serializable ou pas.
Donc il existe bien le "instanceof", mais ca ne repond qu'à 50% de mon pb: en effet, si l'objet est serializable, mais contient d'autres objets qui ne le sont pas, ca n'en tient pas compte.  
Quelqu'un aurait une idée pour savoir si un objet (et les objets qu'il contient) est Serializable (ie: etre sûr que ca plantera pas quand je ferai un writeObject par exemple) ?

je vois pas ou est le problème... étant donné qu'il implémente une interface, tu n'as pas à te préoccuper de l'implémentation qui est faite derrière ! à partir du moment ou le instanceof t'indique que l'objet est de type Serializable, alors tu peux utiliser ses méthodes ! sans parler du fait que readObject et writeObject renvoient IOException en cas de souci !

ben oui mais on peut supposer que le gusse qui a créé la classe a quand même eu le bon gout d'implémenter l'interface et de s'assurer que tout était pris en compte
 
edit: le fourbe a supprimé son post

je dis de la merde

les methodes read/writeObject ne doivent pas necessairement etre implementées pour qu'un objet soit serialisable.
je crois.

Ca c'est vrai par contre.

 
Je me suis mal fait comprendre: je dois realiser une communication entre 2 JVM via une socket, et l'utilisation d'un writeObject sur un ObjectOutputStream. L'objet que je vais faire passer dans le tuyau doit donc etre Serializable, mais EGALEMENT tous les objets rattachés à cet objet (ses attributs)
Ex: L'objet A est serializable, mais contient un objet B qui ne l'est pas. Si je fait un writeObject(A), ca plante (NotSerializableException) car B n'est pas serializable. Or, (A instanceof Serializable) retourne pourtant "true"
 
Ma question est: y-a-t-il un moyen de savoir avant de faire le writeObject si tout va bien se passer (ie: qu'aucun objet non serializable n'est present)
 
Et le "je catch la NotSerializableException" n'est pas une solution, car elle laisse le stream dans un etat pas joli-joli (dixit la javadoc)

ben euh } finally { hein ...
mais pour vérifier en amont, je sais pas trop non plus, et même si de fait ça serait plus élégant, tu dois quand meme fermer ton stream et liberer les ressources qu'il fait dans ton block finally..

 
ou un mwinmwin.CloseableCloseable ?

ouais google:CloseableCloser

ah ok
ben non, jvois pas non plus

Bon, ben j'ai rien trouvé sur le net non plus...
 
La soluce, c'est serialiser vers un tableau de byte, voir si ca se passe bien, et ensuite serialiser via le writeObject. Mais bonjour la perte de perf: 2 serialisations

C'est possible avec un chtit coup d'introspection
 

 
EDIT : ça ne vérifie que le 1er niveau, je prépare une version un peu plus "sioux" qui va tout vérifier

D'un autre côté, faire une classe sérialisable dont les membres ne le sont pas, c'est un peu maso...

ça fera pas avancer le smilbik, mais chui d'accord avec post_it...
 
si la classe est serializable, elle l'est, point.
 
c'est comme si on déclarait une classe Cloneable, avec une méthode clone non surchargée...
 
enfin, je crois...

finalement c'est ce que je dis depuis le début

 
bon, je precise: l'objet qui m'est passé, c'est pas moi qui le code !!! Je ne developpe que le composant de communication, et j'aurais voulu verifier que l'objet qui m'arrive est bien conforme aux specs (ie: Serializable, y compris ses attributs). Oui, je sais, si ca plante, c'est que le developpeur est une buse. Mais j'aimerais plutot afficher un message d'erreur que foirer l'ObjectOutputStream...

 
Oui, en effet, c'est une solution. Je vais m'en inspirer (un p'tit peu de recursivité dans tout ca, et ca devrait le faire
Merci !

et les IOException renvoyées par les méthodes read/writeObject, elles servent à quoi

oui bon on va pas jouer sur les mots hein, t'as parfaitement compris ce que j'ai voulu dire
 
edit: les exceptions lancées

ben oui, mais vu que t'as vaguement tendance à t'en servir comme d'une valeur de retour et pas comme d'une exception, justement, il vaut mieux jouer sur les mots plutot que de raconter des niaiseries

 
Bon, j'ai deja expliqué que c'etait pas possible:  

 
en clair, quand une NotSerializableException arrive, ben je suis pas plus avancé: je suis au courant que l'objet n'est pas conforme, mais en // mon stream est aux fraises...

 
SURTOUT PAS  malheureux ! La récursivité, c'est comme croiser les flux : C'est mal !
(Cf. plus bas)
 

 
Ca m'arrive souvent de rajouter du code que je trouve inutile pour contrôler le manque de compétence des utilisateurs mais si c'est pour contrôler le manque de compétence d'un développeur qui suit pas les specs, c'est horrible .
 
PS : j'ai pas trop de temps pour faire la version complète mais voici les pistes pour ne pas faire de la récursivité
 - dans une boucle, faire un parcourt en profondeur d'abord
 - utiliser java.util.Stack
 - mettre les classes déjà traitée dans une java.util.HashMap pour éviter de faire 2 fois le même travail
 - EDIT :

 
Je ne vois pas pourquoi tu as deux serialisations:
 
Il te suffit d'envoyer les donnees en deux temps:
 
- Serialization en memoire
- Ecriture du tableau de byte deja serialized dans le flux du socket