Salut,
 
Je dois faire une méthode qui charge un fichier texte (un .java d'ailleurs), et me le rende sous forme de String, en conservant les retours à la ligne et tt autre caractère de ce style qu'il peut contenir.
 
La méthode doit etre cross-plateform, et surtout, doit etre performante : les fichiers à charger (des sources) peuvent faire plusieurs milliers de ligne, et faut pas trop que ca prenne 3h.
 
J'ai pensé utiliser  
FileInputStream(String name) pour lire le fichier avec sa méthode read(byte[] b)  
 
et ensuite utiliser le constructeur de String(byte[] bytes)...
 
vous voyez mieux ?

ben tu balances ton FileInputStream dans un BufferInputStream

BufferedReader bande de cakes

ha oui

cela dit jubijub jsais pas ce que tu cherches à faire derriere, mais ça existe déjà

Oui, pour lire du texte un BufferedReader sera plus rapide.
Tu peux voir cet article : http://www.kegel.com/java/wp-javaio.html

ca change quoi ??? les 2 ont la méthode read(byte[] b), je vois pas la différence...
 
c pas une critique, je voudrais juste comprendre...

ben lis la doc

trop BufferedReader quoi...

ok, ma précédente réponse concernait la première réponse de --...
 
Je vois bien l'intéret de la classe...seulement :  
- ca me renvoit des lignes, et je m'interroge sur le marqueur de fin de ligne (la lecture cesse dès qu'il est rencontré, mais est-il inclus ?)
 
- c pas super lourd de reconstruire un string géant avec que des lignes que je concatène ?
 
sinon vérif : le marqueur de fin de ligne en java, c bien Character.LINE_SEPARATOR ?
 
-->chatel : ta ressource est sympa...mais y'a un truc que je comprends pas :  

 
--> le nlines y vient d'où ??? et surtout, comment on prend la ligne suivante avec la méthode readLine ?

'tain mais t'as jamais fait de Java ? Ba nlines à ton avis c'est quoi ? Ce s'rait pas une variable pour... compter le nombre de lignes, des fois ?
readLine() lit la ligne suivante tout seul. Une boucle while sur readLine et pis vala... 'fin ch'ais pas ça me semble assez parlant, tout ça

Ah et pis :

Bin si mais c'est pas c'que tu demandes ?

he taiche salut

-->le package io non je m'en suis jamais servi (mon exp java est très basique)...
 
-->son line, il est initialisé comment, avec quelle méthode ??? j'avais bien compris que ct un compteur, mais il est pas dans la javadoc, j'en déduis que c pas un truc renvoyé par le reader pour dire "tiens le fichier à x lignes"... et que donc il doit etre initialisé qq part...mais je vois ni où, ni comment
 
--> je le sais comment que readline change de ligne tout seul ? en général les méthodes en java sont simples, et font des trucs simples...si tu fais un system.out.println(test[1]), y va pas t'écrire test[2] etc... tout seul...

 
si, mais l'idée de ce topic c de faire un truc performant, parce que l'opération comporte un grand nombre d'itération : donc je me demande si c bien de lire un ligne super vite avec un truc buffurisé, et ensuite de mettre 3h à refaire un string géant avec...je m'interroge sur le gain par rapport à ma première méthode...

essaie déjà de faire ton truc proprement et qui marche, apres tu te branleras la nouille sur les perfs si vraiment y'en a besoin. je vois pas comment tu pourrais présumer de ça si tu sais meme pas faire une "bête" lecture de fichier.

Salut gros tas
Bon, le WE prochain t'es là ?

Ba en lisant caractère par caractère, sur un fichier de 10 Ko, spa la fête quand même

Bin c'est un compteur tout con
Rajoute juste int nlines = 0 en début de source et hop. Le bout de code que t'as mis là ne fait que compter le nombre de lignes d'un fichier en appelant readLine().

ben justement ché pas.
mais ché pas si jpeux vraiment te dire quoi ici, ct'un peu délicat

on fait un truc qui marche, apres on optimize.
l'inverse ça n'a pas vraiment de sens !?
(et en passant dans un Buffered* comme je le dis depuis le debut, rien à foutre que tu lises byte à byte ou ligne par ligne hein )

Bin en lisant un peu à droite à gauche, si un brin. 'fin j'veux dire, savoir que la taille de buffer optimale moyenne est de 8096 octets, j'pense que c'est pas transcendant ni un truc à savoir dès le début, mais la notion de buffering me semble importante quand même

Toutafé

certes.
mais ça change rien.
tu peux faire un truc qui marche puis foutre un bete new BufferedReader dans le pipe, apres.

lire le fichier je vois, c la convertion en string qui me fait soucis...
 
--> -- : le pb je v te le dire : g le chef de projet sur le cul qui veut impérativement un truc performant : donc quitte à implémenter un truc, je voudrais qqc de performant un minimum...en gros y'a une solution existente (un colorizer de merde), et moi je propose le package syntaxe de jedit, qui m'économiserait bcp de taf.
L'ide est ce qu'il est, je peux le modifier mais pour le moment je voudrais juste remplacer le colorizer sans me faire chier. L'ide appelle l'éditeur en lui passant une URI de fichier.
L'éditeur de Jedit lui ne prend comme paramètre que rien, ou un fichier defaults. On remplit le textarea avec une méthode setText qui prend un String.
Je dois donc faire un troisième constructeur qui crée le textarea, lis le fichier, le fout dans un String, et passe ce string à la méthode pour remplir mon textarea...
 
Là, avec la méthode bufferedreader, je vois pas comment créer un String de manière simple. Le readline me fait perdre les fins de ligne, et le read tt court fait des tableaux de int, et pas de cul, le constructeur de String ne prend pas de tableaux de int...donc je suis pas avancé
 
Maintenant je débute hein, c pas la peine d'etre à l'affut de la moindre de mes conneries pour me sauter sur le poil...

Bin en truc rapide et porcho, fous donc un BufferedReader, lis un paquet de 4096 chars via read(), concatène dans ta chaîne et roulez jeunesse jusqu'en fin de fichier.
Tu peux aussi faire du readLine() en rajoutant le LINE_SEPARATOR

\n , on parle d'objets String, pas de fichiers, donc \n
(non?)

Bin s'il lit un fichier texte Ouinedoze et qu'il veut tout garder dans sa Sting, faut garder aussi les \r

http://java.sun.com/j2se/1.4.2/doc [...] eader.html

et ? les méthodes de ce trucs sont redéfinie dans BufferedReader, donc ca avance pas à grand chose...par ailleurs taiche a raison : y me faut une méthode cross plateform, vu que l'ide est destiné à win comme à nux...donc je dois gérer les \n et \r\n...et LINE_SEPARATOR c le sépérateur de ligne déduit du locale charset...donc cross plateform...

BORDEL.
Reader.
tu dois rien gérer du tout.
grrrrr.

essaie au moins au lieu de parler dans le vide, ça m'énerve

je verrais demain, g la tete plein de java...
 
je testerai ta méthode avec un toString, on verra bien...

j'ai vu, et avec 2 méthodes de lecture : une par tableau d'int  représentant des char, et une char par char...rigoureusement les mêmes perfs
 
--> en tt cas le package syntax de jedit est sacrément plus à jour, y'a presque pas une classe où eclipse gueule pas que c du deprecated...je v devoir bosser pas mal...
 
en tt cas apprendre le java à l'arrache comme ca c roots : du jour au lendemain, je dois comprendre les threads, les IO, swing avec tt ce que ca comporte, ant, et la philo de 2 progs que j'ai pas développé, qui sont pas conçus pour marcher ensemble, et que je dois intégrer l'un dans l'autre...heureusement que je suis motivé ...

Bon, résumons : en java, on a les streams qui sont des files de bytes et les reader/writer qui sont des files de chars. La différence, c'est que les chars sont forcément en UTF-16, les bytes, ça peut être n'importe quoi comme encodage.
C'est InputStreamReader qui fait la conversion.  
On peut jouer avec le feu en castant les bytes en chars, mais ça pourrait me rendre violent.
 
Donc pas question de passer outre le InputStreamReader.
La feinte c'est que cette classe délègue le boulot à StreamDecoder dont ont a pas le source, mais on peut se douter qu'il n'utilise pas de buffer.
 
La vraie lecture du fichier se fait avec un FileInputStream, méthode read() qui est native (logique).
 
D'après le lien filé plus haut, il y a une classe BufferedFileReader qui traîne sur le net et qui est optimisée à fond.
 
donc en tirant dans un BufferedFileReader avec un gros buffer (de taille fixe) et en poussant dans un StringWriter initialisé à la taille du fichier on devrait avoir quasiment l'optimum (parce que StringWriter pousse dans un StringBuffer et le toString() est sans recopie, c'est marqué dans le dessous des strings).

d'ailleurs comme le dit la javadoc de FileReader:

trouvé :  
http://grail.cba.csuohio.edu/~jali [...] eader.java
 
puka générer la javadoc de ce truc...
 
intéressant également :  
http://java.sun.com/developer/tech [...] erfTuning/

franchement, laisse tomber ça et plug un InputStreamReader sur un FileInputStream avec un BufferedInputStream ou BufferedReader.
Si apres ça te suffit pas, sera temps de fignoler pour optimiser

(ce bufferedFileReader date de 96 et n'a pas été inclu dans la jdk, c'est sans doute pas pour rien... t'as a mon avis plutot interet à jouer aux lego avec ce que tu trouves dans la jdk)

je peux pas te poster mon code (le putain de norton de mon pc de travail m'a corrompu tt ma clé usb, g du la formatter)...
 
mais en gros g un bufferedtrucmuche et un filereader...et je lis des petits tableaux de char, que j'append au StringBuffer, et que je finis par convertir en string...
 
en gros parser 10.000 lignes ca prend 1031ms (on ne rit pas, je connais pas d'autres méthodes pour optimiser mes progs...g un time stamp au début, un à la fin, et je compare...)
 
ca reste honnete...de tt façon je v devoir attaquer le pb à bras le corp demain : faut que je me documente proprement le syntax de jedit, pour le comprendre, et aussi pour pouvoir l'améliorer un peu (surtout le rendre JDK 1.4 friendly, parce que g une putain de chiée de warning :  blablabla deprecated, et donc c pas hyper ouvert sur l'avenir...
 
normalement le nouveau jedit 4.2 a son syntax, mais en GPL, et donc pour un projet com c mort...en plus il a tt refait, je pense même pas que ce soit compatible...