Discussion :

[Lethal]

Bonjour.

Je développe une applic et je viens d'entamer la partie sauvegarde. J'ai donc commencé par un petit test: j'ai une classe abstraite Data et une classe Critere qui en dérive.

La classe Critere à différents attributs: int,float,String,autre objets,...
Je set donc les attributs dans mon object puis je veux le sérialiser. Erreur de compilation car il veut un constructeur par défaut dans la classe Data.

Ok, je lui met et maintenant ca marche mais il ne me copie pas l'objet mais un nouvel objet créé avec le constructeur par défaut qui ne fait aucune initialisation .

Je sais qu'il y a moyen de controler la sérialisation mais est-ce normal qu'il ne copie pas les attributs de mon objet par défaut ???

Merci d'avance

[Pill_S]

Ok, je lui met et maintenant ca marche mais il ne me copie pas l'objet mais un nouvel objet créé avec le constructeur par défaut qui ne fait aucune initialisation .

Les mécanismes de la sérialisation utilisent la réflexion de Java: une classe Serializable possède une sorte de "constructeur caché" si on veut. Mais il n'empêche que tous les attributs non-static et non-transient doivent être mémorisés automatiquement. Par exemple, avec ce code, les données sont sauvegardées puis chargées sans problème:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class A implements Serializable {int i;}
...
A a = new A();
a.i=50;
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("a.obj"));
oos.writeObject(o);
oos.close();
 
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("a.obj"));
a=(A)ois.readObject();
ois.close();
System.out.println("a.i="+a.i); // 50

[Lethal]

Voila en fait ma classe mère "Data" n'implémentais pas serializable et maintenant ca marche ... même si je ne comprend pas trop pourquoi ?!?

Si qqun à une explication logique, je suis preneur

[Pill_S]

Voila en fait ma classe mère "Data" n'implémentais pas serializable et maintenant ca marche ... même si je ne comprend pas trop pourquoi ?!?

Si qqun à une explication logique, je suis preneur

bin seules les classes qui implémentent Serializable (ou Externalizable) peuvent être écrites dans un flux... le fait d'implémenter Serializable agit comme un "marqueur" pour indiquer que les champs non static de la classes doivent être écrits dans le flux (lors du writeObject)...

Si tu veux agir finement sur les mécanismes de la sérialisation, tu peux redéfinir les méthodes "defaultReadObject" et "defaultWriteObject" de ta classe (attention, ce sont des méthodes privées probablement invoquées par réflexion lors de la sérialisation)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
  ois.defaultReadObject();
  //...
}
 
private void writeObject(ObjectOutputStream oos) throws IOException {
  oos.defaultWriteObject();
  //...
}

[Lethal]

bin seules les classes qui implémentent Serializable (ou Externalizable) peuvent être écrites dans un flux... le fait d'implémenter Serializable agit comme un "marqueur" pour indiquer que les champs non static de la classes doivent être écrits dans le flux (lors du writeObject)...

Oui je sais mais le fait de mettre un classe abstraite serializable n'a pas de sens pour moi vu qu'elle ne sera jamais instanciée telle quelle. Je pensais donc que le simple fait de déclarer les classes filles serializable suffisait et était plus logique.