voilà depuis que j'ai installé le jdk16 update 16 je me retrouve avec des
warning
quelqu'un aurait il une idée du porbleme, je suis sous linux.
WARNING in terminal.java (at line 123)
class TerminalException extends RuntimeException{
^^^^^^^^^^^^^^^^^
The serializable class TerminalException does not declare a static final
serialVersionUID field of type long
----------
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Adrien Grand
On Fri, 10 Oct 2008 22:07:59 +0200, wrote :
Bonjour,
Bonjour,
voilà depuis que j'ai installé le jdk16 update 16 je me retrouve avec des warning
quelqu'un aurait il une idée du porbleme, je suis sous linux.
WARNING in terminal.java (at line 123) class TerminalException extends RuntimeException{ ^^^^^^^^^^^^^^^^^ The serializable class TerminalException does not declare a static final serialVersionUID field of type long
Ce warning vous prévient que vous n'avez pas déclaré de champ static final long serialVersionUID = <ce que vous voulez>; dans votre classe.
La présence de ce champ est conseillée mais non obligatoire pour tous les objets implémentant l'interface Serializable (ce qui est le cas de votre classe puisque RuntimeException étend Serializable). Son intérêt est décrit dans la Javadoc de l'interface Serializable : http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html (Les paragraphes qui expliquent l'intérêt de ce champ sont les deux derniers.)
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de la première écriture de la classe puis à l'incrémenter de 1 à chaque modification. Cela permet de vérifier que le processus qui a sérialisé l'objet a bien la même version de la classe que celui qui le lit.
-- jpountz
On Fri, 10 Oct 2008 22:07:59 +0200, yoyo@invalid wrote :
Bonjour,
Bonjour,
voilà depuis que j'ai installé le jdk16 update 16 je me retrouve avec des
warning
quelqu'un aurait il une idée du porbleme, je suis sous linux.
WARNING in terminal.java (at line 123)
class TerminalException extends RuntimeException{
^^^^^^^^^^^^^^^^^
The serializable class TerminalException does not declare a static final
serialVersionUID field of type long
Ce warning vous prévient que vous n'avez pas déclaré de champ
static final long serialVersionUID = <ce que vous voulez>;
dans votre classe.
La présence de ce champ est conseillée mais non obligatoire pour tous
les objets implémentant l'interface Serializable (ce qui est le cas de
votre classe puisque RuntimeException étend Serializable). Son intérêt
est décrit dans la Javadoc de l'interface Serializable :
http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html
(Les paragraphes qui expliquent l'intérêt de ce champ sont les deux
derniers.)
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de
la première écriture de la classe puis à l'incrémenter de 1 à chaque
modification. Cela permet de vérifier que le processus qui a sérialisé
l'objet a bien la même version de la classe que celui qui le lit.
voilà depuis que j'ai installé le jdk16 update 16 je me retrouve avec des warning
quelqu'un aurait il une idée du porbleme, je suis sous linux.
WARNING in terminal.java (at line 123) class TerminalException extends RuntimeException{ ^^^^^^^^^^^^^^^^^ The serializable class TerminalException does not declare a static final serialVersionUID field of type long
Ce warning vous prévient que vous n'avez pas déclaré de champ static final long serialVersionUID = <ce que vous voulez>; dans votre classe.
La présence de ce champ est conseillée mais non obligatoire pour tous les objets implémentant l'interface Serializable (ce qui est le cas de votre classe puisque RuntimeException étend Serializable). Son intérêt est décrit dans la Javadoc de l'interface Serializable : http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html (Les paragraphes qui expliquent l'intérêt de ce champ sont les deux derniers.)
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de la première écriture de la classe puis à l'incrémenter de 1 à chaque modification. Cela permet de vérifier que le processus qui a sérialisé l'objet a bien la même version de la classe que celui qui le lit.
-- jpountz
yoyo
Adrien Grand wrote:
On Fri, 10 Oct 2008 22:07:59 +0200, wrote :
Bonjour,
Bonjour,
voilà depuis que j'ai installé le jdk16 update 16 je me retrouve avec des warning
quelqu'un aurait il une idée du porbleme, je suis sous linux.
WARNING in terminal.java (at line 123) class TerminalException extends RuntimeException{ ^^^^^^^^^^^^^^^^^ The serializable class TerminalException does not declare a static final serialVersionUID field of type long
Ce warning vous prévient que vous n'avez pas déclaré de champ static final long serialVersionUID = <ce que vous voulez>; dans votre classe.
La présence de ce champ est conseillée mais non obligatoire pour tous les objets implémentant l'interface Serializable (ce qui est le cas de votre classe puisque RuntimeException étend Serializable). Son intérêt est décrit dans la Javadoc de l'interface Serializable : http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html (Les paragraphes qui expliquent l'intérêt de ce champ sont les deux derniers.)
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de la première écriture de la classe puis à l'incrémenter de 1 à chaque modification. Cela permet de vérifier que le processus qui a sérialisé l'objet a bien la même version de la classe que celui qui le lit.
merci, mais cela me fais uniquement des warnings dés que j'installe eclipse qui lui par défaut installe une version jdk 1.4
Adrien Grand wrote:
On Fri, 10 Oct 2008 22:07:59 +0200, yoyo@invalid wrote :
Bonjour,
Bonjour,
voilà depuis que j'ai installé le jdk16 update 16 je me retrouve avec des
warning
quelqu'un aurait il une idée du porbleme, je suis sous linux.
WARNING in terminal.java (at line 123)
class TerminalException extends RuntimeException{
^^^^^^^^^^^^^^^^^
The serializable class TerminalException does not declare a static final
serialVersionUID field of type long
Ce warning vous prévient que vous n'avez pas déclaré de champ
static final long serialVersionUID = <ce que vous voulez>;
dans votre classe.
La présence de ce champ est conseillée mais non obligatoire pour tous
les objets implémentant l'interface Serializable (ce qui est le cas de
votre classe puisque RuntimeException étend Serializable). Son intérêt
est décrit dans la Javadoc de l'interface Serializable :
http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html
(Les paragraphes qui expliquent l'intérêt de ce champ sont les deux
derniers.)
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de
la première écriture de la classe puis à l'incrémenter de 1 à chaque
modification. Cela permet de vérifier que le processus qui a sérialisé
l'objet a bien la même version de la classe que celui qui le lit.
merci, mais cela me fais uniquement des warnings dés que j'installe eclipse
qui lui par défaut installe une version jdk 1.4
voilà depuis que j'ai installé le jdk16 update 16 je me retrouve avec des warning
quelqu'un aurait il une idée du porbleme, je suis sous linux.
WARNING in terminal.java (at line 123) class TerminalException extends RuntimeException{ ^^^^^^^^^^^^^^^^^ The serializable class TerminalException does not declare a static final serialVersionUID field of type long
Ce warning vous prévient que vous n'avez pas déclaré de champ static final long serialVersionUID = <ce que vous voulez>; dans votre classe.
La présence de ce champ est conseillée mais non obligatoire pour tous les objets implémentant l'interface Serializable (ce qui est le cas de votre classe puisque RuntimeException étend Serializable). Son intérêt est décrit dans la Javadoc de l'interface Serializable : http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html (Les paragraphes qui expliquent l'intérêt de ce champ sont les deux derniers.)
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de la première écriture de la classe puis à l'incrémenter de 1 à chaque modification. Cela permet de vérifier que le processus qui a sérialisé l'objet a bien la même version de la classe que celui qui le lit.
merci, mais cela me fais uniquement des warnings dés que j'installe eclipse qui lui par défaut installe une version jdk 1.4
Fos Pat
wrote:
merci, mais cela me fais uniquement des warnings dés que j'installe eclipse qui lui par défaut installe une version jdk 1.4
L'affichage des warning est paramétrable sous eclipse. options -> java -> compiler -> errors/warnings
yoyo@invalid wrote:
merci, mais cela me fais uniquement des warnings dés que j'installe
eclipse qui lui par défaut installe une version jdk 1.4
L'affichage des warning est paramétrable sous eclipse.
options -> java -> compiler -> errors/warnings
merci, mais cela me fais uniquement des warnings dés que j'installe eclipse qui lui par défaut installe une version jdk 1.4
L'affichage des warning est paramétrable sous eclipse. options -> java -> compiler -> errors/warnings
nospam
Adrien Grand wrote:
[...]
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de la première écriture de la classe puis à l'incrémenter de 1 à chaque modification. Cela permet de vérifier que le processus qui a sérialisé l'objet a bien la même version de la classe que celui qui le lit.
Il y a longtemps que je ne me suis plus préoccupé de ce bidule mais il me semblait qu'il y avait un outil (serialver ?) qui permet de calculer la valeur de ce champ .. D'autant que d'après mes très vagues souvenirs, certains ajouts (comme l'ajout d'une méthode par exemple) ne nécessite pas la modification du numéro de sérialisation. En fait il me semblait que seuls les changements des éléments sérialisés, càd les attributs d'une classe qui ne sont pas déclarés "transient" nécessitent la modification de ce nombre pour bien marquer l'incompatibilité entre les anciens objets et les nouveaux. Mais comme je vous ai averti, mes souvenirs sont très vagues sur le sujet ;)
Bonne journée
-- new
Adrien Grand wrote:
[...]
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de
la première écriture de la classe puis à l'incrémenter de 1 à chaque
modification. Cela permet de vérifier que le processus qui a sérialisé
l'objet a bien la même version de la classe que celui qui le lit.
Il y a longtemps que je ne me suis plus préoccupé de ce bidule mais il me
semblait qu'il y avait un outil (serialver ?) qui permet de calculer la
valeur de ce champ .. D'autant que d'après mes très vagues souvenirs,
certains ajouts (comme l'ajout d'une méthode par exemple) ne nécessite pas
la modification du numéro de sérialisation. En fait il me semblait que
seuls les changements des éléments sérialisés, càd les attributs d'une
classe qui ne sont pas déclarés "transient" nécessitent la modification de
ce nombre pour bien marquer l'incompatibilité entre les anciens objets et
les nouveaux. Mais comme je vous ai averti, mes souvenirs sont très vagues
sur le sujet ;)
Une bonne pratique consiste à donner la valeur 0L à ce champ lors de la première écriture de la classe puis à l'incrémenter de 1 à chaque modification. Cela permet de vérifier que le processus qui a sérialisé l'objet a bien la même version de la classe que celui qui le lit.
Il y a longtemps que je ne me suis plus préoccupé de ce bidule mais il me semblait qu'il y avait un outil (serialver ?) qui permet de calculer la valeur de ce champ .. D'autant que d'après mes très vagues souvenirs, certains ajouts (comme l'ajout d'une méthode par exemple) ne nécessite pas la modification du numéro de sérialisation. En fait il me semblait que seuls les changements des éléments sérialisés, càd les attributs d'une classe qui ne sont pas déclarés "transient" nécessitent la modification de ce nombre pour bien marquer l'incompatibilité entre les anciens objets et les nouveaux. Mais comme je vous ai averti, mes souvenirs sont très vagues sur le sujet ;)
Bonne journée
-- new
Adrien Grand
Bonsoir,
a écrit :
D'autant que d'après mes très vagues souvenirs, certains ajouts (comme l'ajout d'une méthode par exemple) ne nécessite pas la modification du numéro de sérialisation.
En effet, seuls les changements « incompatibles » nécessitent la modification de ce nombre. Si l'on ajoute un champ ou une méthode, aucun problème. Attention par contre à ne pas changer l'implémentation des méthodes sans changer ce nombre, car alors la sérialisation/désérialisation se passerait sans aucun problème, mais des bugs difficilement traçables risqueraient de voir le jour (imaginez par exemple une méthode dont l'implémentation passerait de { return ';'; } à { return '|'; }, ledit caractère servant de séparateur pour la lecture d'un flux de données).
-- jpountz
Bonsoir,
nospam@toto.ch.invalid a écrit :
D'autant que d'après mes très vagues souvenirs,
certains ajouts (comme l'ajout d'une méthode par exemple) ne nécessite pas
la modification du numéro de sérialisation.
En effet, seuls les changements « incompatibles » nécessitent la
modification de ce nombre. Si l'on ajoute un champ ou une méthode, aucun
problème. Attention par contre à ne pas changer l'implémentation des
méthodes sans changer ce nombre, car alors la
sérialisation/désérialisation se passerait sans aucun problème, mais des
bugs difficilement traçables risqueraient de voir le jour (imaginez par
exemple une méthode dont l'implémentation passerait de { return ';'; } à
{ return '|'; }, ledit caractère servant de séparateur pour la lecture
d'un flux de données).
D'autant que d'après mes très vagues souvenirs, certains ajouts (comme l'ajout d'une méthode par exemple) ne nécessite pas la modification du numéro de sérialisation.
En effet, seuls les changements « incompatibles » nécessitent la modification de ce nombre. Si l'on ajoute un champ ou une méthode, aucun problème. Attention par contre à ne pas changer l'implémentation des méthodes sans changer ce nombre, car alors la sérialisation/désérialisation se passerait sans aucun problème, mais des bugs difficilement traçables risqueraient de voir le jour (imaginez par exemple une méthode dont l'implémentation passerait de { return ';'; } à { return '|'; }, ledit caractère servant de séparateur pour la lecture d'un flux de données).
