Bonjour à tous,
 
voilà j'ai un fichier texte que je met à jour régulièrement, dedans je mets combien de fois on trouve des mots dans certains fichier, et justement je dois mettre ce nombre à jour à chaque fois que je trouve le mot.
 
Pour illustrer voilà une ligne de mon fichier texte :
 
mot fichier 3 fichier2 5
 
donc ici on trouverais le mot "mot" 3 fois dans "fichier" et ainsi de suite.
 
Quand je retombe sur le mot je dois donc incrémenter ce nombre, mais comment sélectionner l'entier et ensuite le remplacer ?
 
Avec seek() je dois pouvoir bien me positionner mais je sais pas comment éditer le fichier
De plus avec writeChars() ça écris mais avec un espace entre chaque lettre, j'ai oublié quelque chose ?
 
Merci beaucoup pour vos idées, mais ne me proposez pas de réécrire le fichier svp

on est dimanche sebou!
Relache le garde a vous et ne fais rien    
Sinon t'es oblige de faire avec un fichier texte ? pourquoi tu garderais pas tout en memoire avec un tableau ou un tableau de structures?
(Je sais pas trop comment tu as entrepris de realiser ce que tu dois faire donc je propose hein   )

Sinon, tu le fais dans un fichier XML...

ah oui tiens pas bete ca...en plus des parseurs xml pour java ca doit se trouver sans trop de problemes

xstream ?

ah ben ca c'est a sebou de voir
'fin faudrait qu'il se montre quoi

xstream

explanations ?

très peu de contrôle sur le format XML, sauf bidouilles pénibles
très dépendant de la structure des objets (objets d'implémentation et pas interfaces) => évolutions
mécanisme de sérialisation => accès "non-standard" aux attributs (ex : les constructeurs par défaut ne sont pas appelés => pas d'initialization de l'objet)
 
c'est la seule api de mapping XML que j'ai utilisé => j'ai pas d'éléments de comparaison, mais je suis pas plus embalé que ça ... au contraire

* bof, faux, d'autre part on s'en fout bien souvent
  (et de fait, va comparer avec d'autres, tu paieras tes bidouilles)
* gni?
* faux aussi
 
pouet.
et c'est justement ni une *API* ni une librairie de *mapping* xml, c'est une *librairie* de *serialization* xml..

* ben si. et non on s'en fout pas ... c'est un peu le pricnipe d'XML d'être échangeable => la forme du XML a souvent de l'importance
* ex : si tu as un objet qui contient un Set (déclaré comme tel). Si son type est TreeSet et que plus tard tu veux le modifier en HashSet, le xml ne sera pas compatible : ca sauvegarde le type réel et pas le type déclaré, et c'est pas configurable (ou bien j'ai pas trouvé comment).
* ben nan c'est vrai.
 
exemple :

tu sauves en XML.
 
Tu modifies la classe

tu charges le XML et là la collection est null, ce qui n'est pas sensé pouvoir arrivé d'après la déclaration de la classe (col initialisé dans le constructeur et pas de modifieur dispo)
 
y a aussi quelques incompatibilités (inner classes avec attributs final), les charsets qu ne sont pas gérés (sauf dans le DomDriver suite à mon patche), les collections qui sont moyennements supportés (je me souviens plus du type mais y en a une que tu peux pas désérialiser. HashSet peut être).
 

ouep mais même ...
En gros, ca fait gagner du temps en début parce que c'est facile à utiliser, et ca en fait perdre à la longue parce que c'est pas souple et qu'il y a des limitations (en partie dûes au principe de sérialization). Donc en gros à n'utiliser que pour des besoins très limités, et même dans ce cas, j'hésiterais.

euh j'ai pas tout lu mais ton histoire de set, faut bien que xstream sache comment instancier ton bordel non ?
(ça sort qqchose comme <set impl="hashset">...</set> )

(pour moi c'est nickel si tu sais d'avance que tes documents ne sont pas échangés avec des systemes tiers sur lesquels tu n'as pas le controle)

pas forcément ... il pourrait utiliser (ou permettre d'utiliser) une structure de sauvegarde neutre avec juste une indication du type oiginal, mais la possibilité d'utiliser un autre type compatible.
 

et que tu es sûr que ta structure d'objet n'évolueras pas DU TOUT
et que tu n'as pas à gérer l'i18n ou du multi-plateforme (les prb d'encoding ont été oubliés à la conception)
et que tu te limites à des objets à la structure simple
 
 
Perso, même si j'ai des besoins qui rentre là dedans (ce qui est rare, notamment mon 1er point), je chercherai quand même si y a pas un autre outil plus souple ...

ouais nan mais moi ce que je voulais dire c'etait juste que dans le cas du monsieurs, il maintenait son modele en memore et avec xstream il le sauve dans un fichier, et dans le cadre de son projet, ca suffit, je doute qu'il ait mille milliards de contraintes comme celle dont parle benou pour un vrai systeme, je me poserais des questions mais la
 
(et soit dit en passant, xstream fournit un hook pour utiliser les serializers qu'on veut, tout est overridable )

ouais mais tsé, benou, il est du genre à implementer son propre conteneur ejb hein
 
 
 

c'est ce que je voulais dire par "sauf bidouilles pénibles"
 
et je n'ai pas creusé la question plus que ça, mais ca me paraissait pas si overridable que ça : si je me trompe pas, c'est par classe que tu peux configurer la sérialization, et c'est pas forcément suffisant pour te sortir de toutes les situations.
 
 
-- > le conteneur EJB, c'est pas moi, c'est un département de ma boite

tu réponds plus -- ?

euh non  ...
?

tant pis ...
!