[Sérialisation] Différence entre deux méthodes

Bonjour,

Voici deux méthodes que j'ai utilisé dans des projets sans chercher réellement à savoir ce qu'elles faisaient.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

/**      * @param T t Un objet à sérialiser      * @param String fichierSortie le fichier dans lequel devra être sérialiser l'objet      * @return <T> void      */ public <T> void serializer(T t, String fichierSortie){ try { // ouverture d'un flux de sortie vers le fichier nomObjet.serial FileOutputStream fos = new FileOutputStream(fichierSortie + ".serial");   // création d'un "flux objet" avec le flux fichier ObjectOutputStream oos= new ObjectOutputStream(fos); try { // sérialisation : écriture de l'objet dans le flux de sortie oos.writeObject(t); // on vide le tampon oos.flush(); System.out.println(t + " a ete serialise"); } finally { //fermeture des flux try { oos.close(); } finally { fos.close(); } } }

---

Code:

---

1 2 3 4 5 6 7 8 9 10

public <T> void writeFile(T t, String fichierSortie) throws IOException { ObjectOutput out = null; try { out = new ObjectOutputStream(new FileOutputStream(fichierSortie + ".serial")); out.writeObject(t); } finally { out.close(); } }

---

Quelle est la méthode à utiliser ?
Laquelle est la plus... fiable ou mieux écrite ?

Quelles sont les différences entre ces deux méthodes ?

Merci à vous,

la deuxième est la plus courte et est, techinquement, la même. Note qu'il n'est pas nécessaire de fermer les deux flux, car la fermeture de l'objectoutputstream ferme l'outputstream.

Note, je sais pas que quel type est T mais ce serait bien de le contraindre au "Serializable" :p

Le contraindre ?

Par un implements Serializable ?

oui, de toutes façons, objectoutputstream envoie des exception sur les non-serializables

Parlant d'exception, j'aimerai tester si je peux désérialiser un fichier.

Pour ce faire, j'avais pensé à :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

//Création d'un IOData IOData iodata = new IOData();   /* On s'occupe des Avions */ ArrayList<Avion> desAvions = null; try { iodata.deserializer(desAvions, "avion"); System.out.println("Not in the pocket but in the try"); } catch (NullPointerException e) { Avion a1 = new Avion("Airbus A340-300", 295, 129300, 55600, 10000, 13000, 140640,140640); desAvions.add(a1); System.out.println("In the pocket but not in the try T_T"); }

---

En fait, je pensais que si le fichier n'existait pas, il irait me lever une exception puis entrerait dans le catch...
Mais cela ne semble pas être le cas puisque

Citation:

---

java.io.FileNotFoundException: avion.serial (Le fichier spécifié est introuvable)
Not in the pocket but in the try
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at trafficaerien.IOData.deserializer(IOData.java:71)
at trafficaerien.Main.main(Main.java:32)
(...)

---

et lorsque le fichier existe :

Citation:

---

Airbus A340-300 a ete deserialise
Not in the pocket but in the try
(...)

---

Citation:

---

Envoyé par Deallyra

En fait, je pensais que si le fichier n'existait pas, il irait me lever une exception puis entrerait dans le catch...
Mais cela ne semble pas être le cas

Code:

---

java.io.FileNotFoundException: avion.serial (Le fichier spécifié est introuvable)

---

---

En ce qui me concerne, ca semble bien être une exception ça :)

S'en est une mais que je n'arrive pas à capturer.

J'ai lu ceci pour récupérer cette exception

Code:

---

1 2 3 4 5 6 7 8

public static FileInputStream f1(String fileName) throws FileNotFoundException { FileInputStream fis = new FileInputStream(fileName); System.out.println("f1: File input stream created"); return fis; }

---

Mais ça ne veux strictement rien dire pour moi...
D'autant plus qu'il s'agit d'un bloc en dehors du main, donc qui réagira pour chaque FileNotFoundException cependant, j'aurais plusieurs fichiers à désérialiser ><

a mon avis, dans ton cas, c'est trafficaerien.IOData.deserializer(IOData.java:71) qui fait le catch, et l'affiche, vu que le stacktrace est affiché mais que ton code continue quand même.

Salut,

Citation:

---

Envoyé par tchize_

la deuxième est la plus courte et est, techinquement, la même.

---

Les deux sont problèmatique

Dans le premier cas si tu as une exception lors de la création de l'ObjectOutputStream tu ne fermes aucun fichier car on n'est pas encore entré dans le try/finally, et tu conserves donc un fichier ouvert :(
:arrow: Il faut obligatoirement utiliser un try/finally par flux, avec uniquement un seul close() par finally.


Dans le second cas tu ouvres le fichier alors que tu es déjà dans le try/finally, et en cas d'erreurs d'ouverture du fichier tu auras un NullPointerException :(
:arrow: C'est problématique car ce NullPointerException va te cacher l'exception survenu lors de l'ouverture du fichier, et donc la réelle cause du problème.


Comme indiqué dans la FAQ, il faut utiliser un code comme celui-ci :

Code:

---

1 2 3 4 5 6 7

Flux res = new ... try { // traitements... } finally { res.close(); }

---

(note : ce code n'est pas encore parfait, puisque le close() peut générer une exception qui cacherait une autre exception survenir dans le try, mais c'est toutefois un cas assez rare et cela nécessite aussi des traitements plus important).


Toutefois si dans 99% des cas on peut empiler les appels, on ne peut pas le faire avec les Object*Stream car leurs constructeurs peuvent générer des exception. Concrètement si on fait ceci :

Code:

---

new ObjectOutputStream(new FileOutputStream("file"));

---

:arrow: Une exception dans le constructeur ObjectOutputStream nous empêcherait de fermer le fichier pourtant bien ouvert, puisqu'on aurait plus de référence vers ce dernier :(

La meilleure solution serait donc d'utiliser deux try/finally :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public void writeFile(Object t, String fichierSortie) throws IOException { OutputStream fos = new BufferedOutputStream(new FileOutputStream(fichierSortie + ".serial")); try { ObjectOutputStream out = new ObjectOutputStream(fos); try { out.writeObject(t); } finally { out.close(); } } finally { fos.close(); } }

---

A noter que Java 7 devrait intégrer une syntaxe plus clair pour gérer ces cas là...


a++

PS : J'ai viré la syntaxe generics qui ne sert à rien ici. Au pire tu pourrais utiliser le type Serializable à la place de Object...

Donc, pour la désérialisation, tu préconises un code allant en ce sens :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public void deserializer(Object t, String fichierEntree){ InputStream fis = new BufferedInputStream(new FileInputStream(fichierEntree + ".serial")); try { ObjectInputStream in= new ObjectInputStream(fis); try { t = in.readObject(); System.out.println(t + " a ete deserialise"); } finally { in.close(); } } finally { fis.close(); } }

---

Citation:

---

PS : J'ai viré la syntaxe generics qui ne sert à rien ici. Au pire tu pourrais utiliser le type Serializable à la place de Object...

---

Object acceptera n'importe quel objet même non implémentant sérializable c'est ça ?

sauf que ton code, après avoir désérialiser, il fait rien du tout de la valeur là. Il l'attribue à t qui est une variable locale. Ca disparaitra dans les méandre du garbage collector dès la sortie de la méthode :)

Hum... T est un objet que je lui envoies par référence, en paramètre...

Donc il devrait être modifié non? O.o

l'objet, tu ne le modifie pas justement, tu te contente de référencer un nouvel object (celui désiérialisé) dans la variable locale. Les object sont passé par référence en java, mais ces dites références sont passées par copie quand même ^^

pas cool...

Donc je dois modifier la signature de la fonction pour renvoyer un Object, et l'appel se fera de cette manière :

Code:

---

desAvions = iodata.deserialiser(desAvions,"avions");

---

Ou alors je n'ai rien comprit :aie:


edit : ou alors je peux empêcher le passage par copie ?

oui, en oubliant pas des close bien propre :D

effectivement c'est d'ailleurs ce qui est préconisé quand notre méthode retourne un seul résultat.

Le (dernier j'espère) problème étant que ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public Object deserializer(Object t, String fichierEntree) throws FileNotFoundException, IOException, ClassNotFoundException{ InputStream fis = new BufferedInputStream(new FileInputStream(fichierEntree + ".serial")); try { ObjectInputStream in= new ObjectInputStream(fis); try { t = in.readObject(); System.out.println(t + " a ete deserialise"); } finally { in.close(); } } finally { fis.close(); } }

---

N'est pas accepté car pour lui Object n'est pas un type de retour.

il manque le "return" dans ce code.

...

des fois je ferai mieux de rester au lit.

Bien, en faisant ceci comme appel :

Code:

---

1 2	desAvions = (ArrayList<Avion>) iodata.deserializer(desAvions, "avion");

---

Ca fonctionne.

Merci à vous.

Pas besoin du paramètre t puisque tu retourne l'objet après deserialization

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public Object deserializer(String fichierEntree) throws FileNotFoundException, IOException, ClassNotFoundException{ InputStream fis = new BufferedInputStream(new FileInputStream(fichierEntree + ".serial")); try { ObjectInputStream in= new ObjectInputStream(fis); try { Object t = in.readObject(); System.out.println(t + " a ete deserialise"); return t; } finally { in.close(); return null; } } finally { fis.close(); return null; } }

---

jiddou > Tu ne doit pas avoir de return dans les finally, mais seulement l'appel à la méthode close() !!!

Sinon tu retourneras null dans tous les cas puisque le finally est toujours exécuté...

a++

autant pour moi je le voyais en catch puisque je n'utilise presque jamais finally.