Discussion :

[rtg57]

Bonjour,

lorsque je consulte la documentation sur les classes JAVA sur le site de Sun, je rencontre souvent le message d'avertissement suivant:

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package.

Concrètement, cela signifie quoi ?
Je débute en JAVA et je suis en train de programme une petite application avec une JTable, et une classe qui étend AbstractTableModel. Y a-t-il des précautions particulières à prendre par rapport à ce message ?

Merci & @ bientôt

[Deaf]

Bonjour,

Cela signifie que si tu t'amuses à sérialiser tes composants Swing à une version de Java donnée, il est possible que tu rencontre des problèmes pour les désérialiser dans une version de Java supérieure.

Mais je doute que tu aies réellement besoin de sérialiser des composants

[rtg57]

OK, merci.

Effectivement, la sérialisation de composants ne présente aucun intérêt pour moi pour le moment.
J'y réfléchirai peut être plus tard lorsque j'aurai plus d'expérience JAVA.

[le y@m's]

Comme indiqué, pour sérialiser les composant swing sans avoir de problème dans les versions futures de Java il faut utiliser la sérialisation XML du package java.beans avec les classes XMLEncoder et XMLDecoder. Voir aussi La sérialisation XML en Java

[Deaf]

Mais quel intéret de sérialiser des composants Swing?
Cela m'intrigue...

[le y@m's]

Et bien pour pouvoir retrouver plus tard le composant dans l'état exact où il était au moment de sa sérialisation. Après il est vrai que ce besoin ne fait pas parti des plus courant ^^.

[Deaf]

Stocker une Interface, cela ressemble à une erreur de conception pour ma part
D'où ma question.

[sinok]

Stocker une Interface, cela ressemble à une erreur de conception pour ma part
D'où ma question.

Pas forcément ou peut très bien imaginer stocker des composants d'une interface pour les ressortir dans l'état même ou ils étaient lors de la dernière exécution de l'application (position des scrollpanes, filtres & cie).

[rtg57]

Ah ben je vois que le sujet n'est pas sans intérêt.

Mon idée de départ était de pouvoir démarrer une application et de permettre à l'utilisateur de retrouver les éléments comme il l'avait laissé à la dernière utilisation; par exemple:

* Une ComboBox sur le dernier index positionné,
* Un TexteField avec le dernier texte entré,
* Une JTable sur la ligne visionnée avant la fermeture

Donc, sans approfondir le sujet, j'avais pensé à cette possibilité de sérialisation des composants.
Evidemment, on peut toujours s'en sortir en utilisant des variables internes sauvegardées dans le fichier de données...

M'enfin voila l'idée. Or comme il y a ce message d'avertissement dans la documentation Java, je me contenterai de la seconde solution...

[le y@m's]

Ah ben je vois que le sujet n'est pas sans intérêt.

Mon idée de départ était de pouvoir démarrer une application et de permettre à l'utilisateur de retrouver les éléments comme il l'avait laissé à la dernière utilisation; par exemple:

* Une ComboBox sur le dernier index positionné,
* Un TexteField avec le dernier texte entré,
* Une JTable sur la ligne visionnée avant la fermeture

Donc, sans approfondir le sujet, j'avais pensé à cette possibilité de sérialisation des composants.
Evidemment, on peut toujours s'en sortir en utilisant des variables internes sauvegardées dans le fichier de données...

M'enfin voila l'idée. Or comme il y a ce message d'avertissement dans la documentation Java, je me contenterai de la seconde solution...

C'est bien là qu'est l'intérêt de cette sérialisation XML. Ce mécanisme a été introduit justement pour être utilisé avec les ihms (bien qu'on puisse l'utiliser sur d'autres beans) au lieu de la sérialisation "classique" qui pose les problèmes de version .
Ainsi tu peux sérialiser ton ihm sans avoir à t'occuper de tout écrire toi même (récupération des propriétés dans des variables, les écrires dans un fichier, etc.)

[Deaf]

Je suis désolé, mais je ne vois toujours pas l'intérêt de sérialiser des composants.

Si mon interface est dans un certain état, c'est à cause de l'état de mon modèle auquel il est relié. Si je veux conserver l'état, je sérialise mon modèle et je synchronise mon IHM quand je veux retrouver l'état précédent.

Dans mon esprit, un composant ne doit pas contenir d'état important (que des états temporaires du genre : bouton enfoncé, survolé), il doit juste refléter tout ou partie du model sous-jacent. Et donc, il ne possède rien qui mérite d'être sérialisé.

Enfin, c'est mon point de vue

[sinok]

C'est intéressant pour tout ce qui ne ressort pas des données de l'application, genre position d'un JScrollPäne, ordre des colonnes d'une JTable, sélection d'une partie du texte d'un JTextPane par exemple, Etat d'ouverture/fermeture des branches d'un JTree et ainsi de suite.

[uhrand]

C'est intéressant pour tout ce qui ne ressort pas des données de l'application, genre position d'un JScrollPäne, ordre des colonnes d'une JTable, sélection d'une partie du texte d'un JTextPane par exemple, Etat d'ouverture/fermeture des branches d'un JTree et ainsi de suite.

sinok,
j'ai des doutes que ça puisse réellement fonctionner comme tu le décrit.

Je suis d'ailleur du même avis que Deaf. Si on prend par exemple la taille et la position des colonnes d'une JTable: il sufffit de sérialiser le TableColumnModel.

Aussi, c'est facile de sérialiser un modèle avec XMLEncoder: il suffit de s'assurer que le modèle est une "public class" avec un constructeur par défaut (sans paramètre) et des "getter/setter" pour les attributs. Voici un exemple d'un TableColumnModel:

Code :

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

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
29
30
31
32
33
34
35
36
 
/*
 * MyColumnModel.java
 * is a bean that can be saved/loaded using XMLEncoder/XMLDecoder
 */
import java.util.*;
import javax.swing.table.*;
 
public class MyColumnModel extends DefaultTableColumnModel {
 
    private Object[] columnData = new Object[]{
        "Title 1", 100, //column 1: header value, width
        "Title 2", 50,  //column 2: header value, width
        "Title 3", 50,  //column 3: header value, width
        "Title 4", 50   //column 4: header value, width
    };
 
    public MyColumnModel() {
        super();
        for (int i = 0; i < columnData.length; i += 2) {
            String title = (String) columnData[i];
            Integer width = (Integer) columnData[i + 1];
            TableColumn tableColumn = new TableColumn(i / 2, width);
            tableColumn.setHeaderValue(title);
            addColumn(tableColumn);
        }
    }
 
    public Vector<TableColumn> getTableColumns() {
        return tableColumns;
    }
 
    public void setTableColumns(Vector<TableColumn> tableColumns) {
        this.tableColumns = tableColumns;
    }
}