messieurs, je réalise le jeu du Taquin et je m'occupe maintenant de la gestion du classement et c'est la que mon problème survient...
J'ai crééer une Classe Classement(String nom et int Score) qui est sérializable
Lorsque que la partie est fini un dialog s'ouvre pour le nom du joueur et je construit mon instance de classement avec ce nom et je le sauvegarde à la suite de mon fichier

 
Ensuite dans une autre fonction je ve relire mon fichier pour kil m'affiche les instances sauvegarder ;

 
Mais le pb c'est que je ne recupère que le premier Objet ensuite j'ai une

 
Quelqu'un aurait une idée??
Merci d'avance

 
 
tu mets 1 objet dans le fichier, tu essayes ensuite d'en lire 15 ...
Et bizarrement, tu n'arrives à en lire qu'un ...
 
Qu'est ce qui pourrait expliquer ce comportement étrange

non mais ca c pas le pb t'inkiete je catch mon EOF comme ca ne me pose pas de pb
mais en fait la StreamCorruptedException qui pose pb, même en regardant la JAvadoc je comprend pas d'ouvien cette erreur...

 
edit : deplus lorsque j'ecrit pour la première fois dans le fichier g pas le pb par contre, c'est quand je met une instance à la  fin de mon fichier que ca merdouille

no idea?

tjs pas d'ame charitable pour m'aider ?

ben tu nous dis surement pas tout parce que ce genre d'exception est pas sensée ce produire ... en tout cas, pas avec un code aussi simple que le tiens ...
 
c'est 2 jvm séparées qui écrivent et qui lisent ? les fichier sont manipulés entre temps ? ils ont la même version des .class ?

ben c la même JVM car meme machine, je verifie de fermer mes fichiers avt de les ouvrir, enfin je me debrouille en JAVA g demandé à un pote à moi qui fait que du java depuis des années et lui même de ne voit pas d'ou çà vient...
le code ki y a autour de ce ke je vous ai donné n'influe pas sur les bout de code car il n'y a  aucune manip de fichier?

les mêmes fichiers .class qui sont utilisés par le code qui écrit et qui lit ?
 
c'est dans quel cas que tu as le prob ?
dès que tu écris 2 objets et qeu tu essaye de les lire tous les deux ?
 
tu as essayé d'isolé le problème en faisant un prog qui fait juste ca ?

montre voir le code complet de Classement

up ?    
 
J'ai exactement le meme problème  

pkoi tu ne peux sérialiser un vecteur d'objet, comme ça tu n'aurais qu'a un objet à lire et à écrire, et ensuite faire l'oppération en mémoire qui est nettement plus rapide. Enfin mio c'est tjs comme ça que je procède

Bonne idée, mais voiçi ce que j'aimerai faire :
 
Ecrire un objet dans le fichier, faire des traitement, donc fermer le programme, réecrire un objet, les lire opur en trouver un, ...
 
Pas commode à implémenter dans un vecteur
 
J'ai fait quelques recherches sur le net, et apparrement, il y a de gros problèmes quand on fait :
- ouvrir stream
- ecrire
- fermer
- ouvrir stream
- ecrire
- fermer
 

xstream ? ?

Explique ?

http://xstream.codehaus.org/
c'est une lib pour serialiser/deserialiser des objets, c'est tout simple et tres pratique

MErci, mais juste un truc, comment je m'en sert ? j'ai pas tout pigé apparement...
 
J'ai copié les 2 . jar dans le dossier des sources, mais quand je met : XStream ... il (eclipse) ne le reconnais pas

problème de classpath : rajoute les .jar dans les options de ton projet

Tant que j'y suis :
 
J'ai bien reussi a écrire/lire grace à xstream, mais pour la lecture, j'en suis arrivé à un truc assez moche, ou je lis ligne par ligne, jusqu'a tomber sur la balise de fin de ma classe, je met toutes les lignes dans un string, que je retransforme en Objet par apres.
 
La phase "je lis ligne par ligne ...", ne me plait pas vraiment, il n'y a pas un moyen + simple ?
 
merci

euh, t'as pas a faire tout ca hein, le mieux c'est de serialiser une liste de tes objets
 
et tu deserializes une liste aussi, tu laisses xstream tout faire pour toi
 
List trucListe;
//tu mets tes objets dedans
XStream xstream = new XStream(); (si je me souviens bien)
String listeSerializee = xstream.toXml(trucList);
 
 
et apres:
 
List truc = xstream.fromXml( soit une string, soit une inputStream )
 
et ta liste contient tes objets

Quel est l'intérêt de passer par un serializer spécial alors que ObjectInputStream et ObjectOutputStream gèrent aussi bien les ArrayList que les arrays classiques (Object[])

bah c'est plus simple a utiliser, ca impose moins de contraintes sur les objets a serialiser (aucune en fait ) et puis c'est vachement in/rebelz/fashion

Il y en a quand même pas lourd de contraintes sur les Object*Stream, et j'ai du mal à voir en quoi c'est dûr à utiliser
 
En plus la serialisation XML, voila quoi

 
1/ ton "flux" est lisible. i.e, si tu passes par exemple par un systeme de messagerie, tu peux voir tes messages, au lieu de voir un caca binaire qui ne veut rien dire.
2/ avant de pingouiner dans le vide, fais des tests, ou à defaut va lire les benchs.

Ici le monsieur veut stocker des classements, les chances qu'il ait besoin de les relire avec une autre application sont faibles, qu'il ait besoin de les relire dans une autre application non codée en java le sont encore plus, et l'intérêt qu'un humain puisse lire et modifier les infos directement est -- je trouve -- peu ou prou inexistant pour le programmeur...

Là on parlait de la difficulté à utiliser le mécanisme de sérialisation et des contraintes dues au mécanisme, que viennent y foutre des benchs

1/ ben tiens. j'utilise xstream pour stocker la config d'une petite appli que j'utilise tout seul. j'ai été bien content à plusieurs reprises de la grep-er ou de la corriger à coup de vi.
 
2/ c'était en réponse à "En plus la serialisation XML, voila quoi pingouino"

Super, sauf qu'il ne sérialise pas un fichier de configuration il sérialise un classement d'un jeu de taquin, c'est pas exactement la même situation hein...

Et alors?

bon, tu voulais dire quoi, avec ton pingouino, alors ?

boah, en l'occurence, t'utilises pas xml, tout est caché dans xstream, cfr le bout de code de souk. 1 ligne pour serializer. 1 ligne pour deserializer. (d'ailleurs tu peux serialiser dans un autre format qu'xml, le point etant que ça reste plus lisible ET plus simple à utiliser que la serialization java)

Pour repondre en gros à tout le monde :
 
Avec les Write/readObject, ca ne me semble pas super prévu pour la sauvegarde sur fichier, a part sauver totu dans une array, pour la lire ou l'ecrire, on ne peut pas faire grand chose, et cela me semblai peu optimal de devoir mettre tout mes objet à sauver dans une array...
 
Avec le Xml, je peut utiliser ma sauvegarde classiquement, en fait, je m'en fout un peu de pouvoir le relire en "texte" par apres...
 
 
Mais je ferai 2 version de ce ptit prog, une avec XML, une avec les ReadObject, je verrai bien laquelle me plait le plus

Heuuu ton classement machin là il n'est pas chargé en mémoire dans un array (ou un truc qui y ressemble, map par exemple) en début de partie
(et Object*Stream, comme xstream, permet de sérialiser peu ou prou n'importe quel objet (enfin avec O*S il faut qu'il soit sérialisable), je vois pas ce que le "a part sauver tout dans une array" vient foutre ici)

Et si je ferme mon prog ?

Tu sérialises ton classement à la fermerture et tu désérialise à l'ouverture
 
Tu peux même sérialiser à chaque modification du classement si ça t'amuse
 
Surtout qu'avoir une structure de classement complète te permet de faire des tris propres

C'est pour éviter que si mon vecteur comporte 300 elements, je ne doive les stocker en memoire alors que j'en aurais peut etre pas besoin ...

Comment dire...
 
Vu la place que prend une ArrayList (quel intérêt d'utiliser un vecteur ) de 300 petits objets en mémoire (ça doit être de l'ordre de 5ko au grand maximum pour l'estimation supérieure avec des objets de taille respectables...) par rapport à ce qui est bouffé par la VM, je m'inquiéterais pas trop.
 
Et si on compare ça avec les ressources et le temps nécessaires pour faire tes joujous dans des fichiers, c'est un ou deux ordres de grandeur plus efficaces et moins bordélique (donc moins source de bugs et comportements illogiques)  
 
Sans compter qu'un classement, il arrive souvent que ce soit trié, et trier un conteneur implémentant une List est trivial.
 
Enfin, tes données seront simplement stockées en continu au lieu d'être stockées temporairement (donc auront leur emplacement stable au lieu de créer des allocations et désallocations à chaque fois que tu auras besoin d'afficher les scores...)

MErci pour cette belle explication
 
Pour moi vecteur est un terme generique, donc ici, en java, je prend une ArrayList, ou une autre collection au cas ou.
 
J'etait persuadé que cele prenait beaucoup plus de place en mémoire, mais la, effectivement, je ne vais pas me faire chier avec ce que jepensait, je vais directement mettre tout dans une collection

Ah oui mais non, en Java un vecteur ça sera assimilé à l'objet Vector (java.util.Vector), donc une liste spécifique (c'est équivalent à ArrayList mais "thread safe", ça n'a aucun intérêt dans ton cas et ça a 30% à 50% de perfs en moins)

À part de très très gros objet, 300 objets dans un array c'est pas grand chose hein

Une List, un objet implémentant l'interface Collection n'est pas nécessairement ordonné, un objet implémentant l'interface List l'est (et List est dérivée de Collection)

ptain mais l'vieux fud sources, qu'on rigole un coup ?

J'essaie de les retrouver
 
Bon... premier lien, un test de perfs de Bruce Eckel n'indiquant aucune différence entre les deux (si je lis correctement les résultats)
 
Et un autre sur OnJava expliquant que la différence existait pour les anciennes VM mais n'existe plus

 
Encore un

genre http://www-128.ibm.com/developerwo [...] 04223.html ?