Je reçois une erreur (java.io.streamcorruptedexception: code de type invalide: 00) lors de la lecture d'un objet sérialisé. Voici la classe qui implémente sérialisable: et voici la trace de la pile: p> Est-ce que quelqu'un sait comment je peux obtenir plus d'informations sur l'erreur? Ou quel objet Java attend? P> p>
4 Réponses :
Vous avez mis en place une méthode reconsive L'objectif du champ SerialVersionUID est de vérifier que les objets sont compatibles. C'est fait de manière nativement par le mécanisme de sérialisation. Vous n'avez rien à faire, sauf modifier la valeur SerialVersionUID lorsque la classe change. P> wrecroveObject code>: lorsque vous écrivez une instance à un flux de sortie, il appelle la méthode WriteObject, qui écrit un int, puis écrit l'objet au flux de sortie, qui Écrivez un int, etc. p>
J'ai changé la méthode de lecture et d'écriture de sorte qu'elle n'écrit pas ni ne lisait pas le courant_serial_version et je reçois exactement la même erreur
Ce n'est pas ce champ qui cause un problème. C'est ceci code>. Ne mettez pas en place une méthode WriteObject ou ReadObject. Le mécanisme de sérialisation écrira votre objet sans aucun problème sans ces méthodes.
Je viens d'essayer de prendre ces méthodes et de lire et d'écrire l'objet directement à partir du flux de sortie d'objet, la même méthode se produit. Y a-t-il d'autres raisons pour lesquelles cela pourrait être causé?
Essayez de sérialiser l'objet intérieur et voyez s'il provoque le même problème. Répétez jusqu'à ce que vous trouviez le coupable. Et vérifiez si ce n'est pas un problème avec la façon dont vous écrivez et lisez. Essayez de sérialiser à une byearrayOUOutPutStream et de lire à partir d'une byearrayInputStream.
Vous n'avez pas à modifier SerialVersionUID lorsque la classe change. N'a pas personne i> lisez le chapitre Versioning de la spécification de sérialisation de l'objet?
@EJP: J'ai. Il est écrit: "Chaque classe Versioned doit identifier la version de la classe d'origine pour laquelle il est capable d'écrire des flux et d'où il peut lire b>." (mettre l'accent sur le mien). Donc, oui, si vous apportez des modifications à la classe qui rendent son format de sérialisation incompatible avec la version précédente de la classe, vous êtes censé changer SerialVersionUID. BTW, la valeur par défaut, calculée par la machine virtuelle, change dès que vous ajoutez, supprimez ou réorganisez des champs, précisément pour signaler qu'une classe précédente ou future qui n'aurait pas les mêmes champs dans le même ordre serait incompatible.
Courez pour obtenir la réponse:
package so.java9217010; import java.io.*; public class SerializeMe implements Serializable{ private String foo; private static final long serialVersionUID = 1; private static final int CURRENT_SERIAL_VERSION = 1; public SerializeMe(String foo) { this.foo = foo; } public SerializeMe(){ } public SerializeMe readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { int version = in.readInt(); if (version != CURRENT_SERIAL_VERSION) throw new ClassNotFoundException("Mismatched NaiveBayesTrainer versions: wanted " + CURRENT_SERIAL_VERSION + ", got " + version); //default selections for the kind of Estimator used return (SerializeMe) in.readObject(); // nb = test.returnNB(); } public void writeObject(ObjectOutputStream out) throws IOException { out.writeInt(CURRENT_SERIAL_VERSION); //default selections for the kind of Estimator used out.writeObject(this); } public String returnNB(){ return foo; } public void setNB(String foo){ this.foo = foo; } public static void main(String[] args) throws Exception { SerializeMe o = new SerializeMe("hello"); ByteArrayOutputStream bout = new ByteArrayOutputStream(); ObjectOutputStream oout = new ObjectOutputStream(bout); o.writeObject(oout); oout.flush(); byte[] buff = bout.toByteArray(); ByteArrayInputStream bin = new ByteArrayInputStream(buff); ObjectInputStream oin = new ObjectInputStream(bin); SerializeMe ro = o.readObject(oin); System.out.format( "got: %s -- the problem is most likely in the library you are using ...\n", ro.returnNB()); } }
Ce n'est pas une réponse. Considérez une personne qui lit à partir d'un smartphone qui ne peut pas exécuter le code; Ensuite, cette réponse ne les aidera pas.
Si le JVM ne trouve pas la classe lorsque vous essayez de lire un objet sérialisé, cette exception sera générée. Vérifiez que les fichiers JAR / classe mis à jour sont disponibles dans le chemin de la classe, etc. P>
Si vous exécutez un maillet à partir de la ligne de commande, il peut s'agir d'examiner les bocaux de maillet non cutanés et les fichiers de classe à partir d'une distribution téléchargée, et non dans vos nouveaux fichiers de classe créés dans votre référentiel source téléchargé. P >
Ne vous sentez pas trop mal - j'ai vu cela arriver à d'autres personnes et je l'ai fait moi-même (bien que j'ai eu une "parfaiteNotFoundException" plus informative "pour m'aider à comprendre :) p>
est venu ici pour trouver une solution pour la désérialisation du classificateur de maillet. Enfin, mon problème était que j'ai formé et sérialisé le modèle dans un projet Eclipse et essayé de désérialiser dans un autre projet Eclipse. L'une des classes (parmi celles que j'ai créées) dans l'objet Serialized était uniquement sur le chemin de la classe de l'ancien projet et non sur le chemin de la classe de ce dernier. P>
Cela ne fournit pas de réponse à la question. Une fois que vous avez suffisamment réputation , vous pourrez
Vous voulez donc dire que la question initiale était "Est-ce que quelqu'un sache comment puis-je obtenir plus d'informations sur l'erreur? Ou quel objet Java attend?" La réponse devrait donc être de savoir comment obtenir plus d'informations sur l'erreur? Ou le but réel i> de l'astituteur est de résoudre le problème? Ma réponse donne une solution au vrai problème. Désolé.
Dupliquer Stackoverflow.com / Questions / 2234406 / ...
Cela ne résout pas le problème. Pouvez-vous fournir une explication sur la raison pour laquelle cela devrait?