Qu’est-ce que cela signifie: la classe serializable ne déclare pas un champ serialVersionUID final statique?

J’ai le message d’avertissement donné dans le titre. Je voudrais comprendre et supprimer. J’ai déjà trouvé des réponses sur cette question mais je ne comprends pas ces réponses à cause d’une surcharge de termes techniques. Est-il possible d’expliquer ce problème avec des mots simples?

PS Je sais ce qu’est la POO. Je sais ce que sont object, classe, méthode, champ et instanciation.

PPS Si quelqu’un a besoin de mon code, c’est ici:

import java.awt.*; import javax.swing.*; public class HelloWorldSwing extends JFrame { JTextArea m_resultArea = new JTextArea(6, 30); //====================================================== constructor public HelloWorldSwing() { //... Set initial text, scrolling, and border. m_resultArea.setText("Enter more text to see scrollbars"); JScrollPane scrollingArea = new JScrollPane(m_resultArea); scrollingArea.setBorder(BorderFactory.createEmptyBorder(10,5,10,5)); // Get the content pane, set layout, add to center Container content = this.getContentPane(); content.setLayout(new BorderLayout()); content.add(scrollingArea, BorderLayout.CENTER); this.pack(); } public static void createAndViewJFrame() { JFrame win = new HelloWorldSwing(); win.setTitle("TextAreaDemo"); win.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); win.setVisible(true); } //============================================================= main public static void main(Ssortingng[] args) { SwingUtilities.invokeLater(new Runnable(){ public void run(){ createAndViewJFrame(); } }); } } 

Du javadoc :

Le runtime de sérialisation associe à chaque classe sérialisable un numéro de version, appelé serialVersionUID , utilisé lors de la désérialisation pour vérifier que l’expéditeur et le destinataire d’un object sérialisé ont des classes chargées pour cet object compatibles avec la sérialisation. Si le récepteur a chargé une classe pour l’object ayant un serialVersionUID différent de celui de la classe de l’expéditeur correspondant, la désérialisation entraînera une InvalidClassException . Une classe sérialisable peut déclarer explicitement son propre serialVersionUID en déclarant un champ nommé "serialVersionUID" qui doit être statique, final et de type long:

Vous pouvez configurer votre IDE pour:

  • ignorez ceci, au lieu de donner un avertissement.
  • générer automatiquement un identifiant

Selon votre question supplémentaire “Est-ce que le message d’avertissement présenté est une raison pour laquelle mon application graphique se bloque?”:

Non, ça ne peut pas être. Cela peut causer un problème uniquement si vous sérialisez des objects et les désérialisez à un endroit (ou à un moment) différent où (quand) la classe a changé, et cela ne provoquera pas de gel, mais dans InvalidClassException .

Les raisons de l’avertissement sont documentées ici , et les corrections simples consistent à désactiver l’avertissement ou à mettre la déclaration suivante dans votre code pour fournir la version UID. La valeur réelle n’est pas pertinente, commencez par 999 si vous le souhaitez, mais modifiez-la lorsque vous apportez des modifications incompatibles à la classe.

 public class HelloWorldSwing extends JFrame { JTextArea m_resultArea = new JTextArea(6, 30); private static final long serialVersionUID = 1L; 

Les autres réponses à ce jour contiennent beaucoup d’informations techniques. Je vais essayer de répondre, comme demandé, en termes simples.

La sérialisation est ce que vous faites à une instance d’un object si vous souhaitez la vider dans un tampon brut, l’enregistrer sur un disque, la transporter dans un stream binary (par exemple, envoyer un object via un socket réseau) ou créer un numéro de série. représentation binary d’un object. (Pour plus d’informations sur la sérialisation, voir Java Serialization sur Wikipedia ).

Si vous n’avez pas l’intention de sérialiser votre classe, vous pouvez append l’annotation juste au-dessus de votre classe @SuppressWarnings("serial") .

Si vous allez sérialiser, vous devez vous préoccuper de tout ce qui concerne l’utilisation correcte de l’UUID. Fondamentalement, l’UUID est un moyen de “version” d’un object que vous souhaitez sérialiser pour que tout processus désérialisant sache qu’il est correctement désérialisé. Je voudrais vérifier le contrôle de version correct pour les objects sérialisés pour plus d’informations.

il doit être changé chaque fois que quelque chose change qui affecte la sérialisation (champs supplémentaires, champs supprimés, changement de commande de champ, …)

Ce n’est pas correct, et vous ne pourrez pas citer une source autorisée pour cette revendication. Il doit être modifié chaque fois que vous apportez une modification incompatible avec les règles indiquées dans la section Gestion des objects sérialisables de la spécification de sérialisation d’objects , qui n’inclut pas de champs supplémentaires ou de changement de champ, et lorsque vous n’avez pas fourni readObject(), writeObject(), et / ou readResolve() ou /writeReplace() et / ou une déclaration serializableFields pouvant faire face au changement.

Toute classe pouvant être sérialisée (c’est-à-dire implémentant Serializable ) doit déclarer cet UID et il doit être modifié à chaque fois que quelque chose change qui affecte la sérialisation (champs supplémentaires, champs supprimés, changement de champ, …). La valeur du champ est vérifiée lors de la désérialisation et si la valeur de l’object sérialisé n’est pas égale à la valeur de la classe dans la machine virtuelle en cours, une exception est levée.

Notez que cette valeur est particulière car elle est sérialisée avec l’object même si elle est statique, pour les raisons décrites ci-dessus.