[JAVA]utilizzo classe BufferReader

[Frank1962]

devo leggere un file di testo che contiene tot righe di testo; per leggere ogni riga uso il metodo .readline della classe bufferreader: il problema sorge quando voglio leggere *tutte" le righe di testo contenute nel file .......che ciclo devo utilizzare e sopratutto qualche condizione?

nei metodi della classe BufferReader non ho trovato nulla che mi potesse indicare l'EOF!


File aFile = new File("C:\\file.bin"); <--- file da leggere


try { in = new FileInputStream (aFile); } catch(Exception e) { } <--- ottengo lo Stream (non quello della valve! lol)


BufferedReader d = new BufferedReader(new InputStreamReader(in)); <--- il buffer per leggere il testo


string = d.readLine(); <--- metodo per leggere una singola riga


ciao e grazie ;)



ps: secondo voi questo tipo di lettura di un file di testo è efficente o c'è qualcosa di meglio?

[recoil]

tu continua a leggere il file finché non arriva l'eccezione IOException
a quel punto sai che il file è finito

[RaNd0m]

string = d.readLine();
while (string!=null) {leggi il file }

.......io ho usavo questo ( mi sembra :D )

cmq dovresti mettere tutto in un array di string

[gabriele81]

Originariamente inviato da RaNd0m
string = d.readLine();
while (string!=null) {leggi il file }

.......io ho usavo questo ( mi sembra :D )

cmq dovresti mettere tutto in un array di string

Esatto, se il file è finito il metodo readLine() ritorna NULL.

[recoil]

Originariamente inviato da gabriele81
Esatto, se il file è finito il metodo readLine() ritorna NULL.

è vero, non so perché non mi è venuto in mente subito
del resto ho usato la bufferedreader praticamente solo per le socket quindi c'era l'abitudine a usare le eccezioni

[PGI]

Originariamente inviato da Frank1962
ps: secondo voi questo tipo di lettura di un file di testo è efficente o c'è qualcosa di meglio?

I FileChannel sono dichiarati "più meglio del meglio", però se il file è piccolo la differenza non penso si veda.


import java.io.*;
import java.nio.*;
import java.nio.channels.*;
import java.nio.charset.*;

public class NIOReader {
public static void main(String[] args) {
try {
StringBuffer text = new StringBuffer();
FileChannel inChannel = new FileInputStream("z:/prova.txt").getChannel();
ByteBuffer buffer = ByteBuffer.allocate(1024);
Charset charset = Charset.forName("ISO-8859-1");
CharsetDecoder charsetDecoder = charset.newDecoder();
while( inChannel.read(buffer) != -1 ) {
buffer.flip();
text.append(charsetDecoder.decode(buffer).toString());
buffer.clear();
}
inChannel.close();
System.out.println(text);
} catch(IOException e) {
e.printStackTrace(System.err);
System.out.println("End of stack trace");
}
System.exit(0);
}
}

[Frank1962]

grazie PGI!! ...in effetti quel codice riuslta essere moolto + efficente nella lettura di file! ....però quando tento di andare a caricare file abbastanza grossi (30-40mb) mi da un errore "java.lang.OutOfMemoryError" <--- come faccio quindi a impostare la jvm per fargli utilizzare + ram ? :)

ciao e grazie!

[cn73]

I parametri sono da impostare al momento del lancio della jvm:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html

In special modo


-Xmsn
Specify the initial size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 2MB. Examples:
-Xms6291456
-Xms6144k
-Xms6m



Devi comunque tenere conto dei limiti fisici della memoria, per cui è conveniente(anzi d'obbligo) implementare un algoritmo che divida in n blocchi il file da leggere.

[PGI]

da linea di comando puoi usare l'opzione -XmxN, dove N indica la quantità di memoria massima di allocazione che la jvm può usare (default 64megabyte). N può essere espresso in kilobyte o megabyte, di solito si usano i megabyte.

es.

java -Xmx256m Programma.java -> la jvm "arriva" fino a 256megabyte

Puoi anche stabilire la dimensione iniziale della memoria di allocazione (default 2megabyte)

java -Xms16m -Xmx256m Programma.java -> la jvm parte con 16megabyte e arriva fino a 256.

Questa seconda opzione si può usare nel caso in cui il programma richieda già all'avvio un quantitiativo di memoria più ampio del normale e dovrebbe garantire una partenza un po' più rapida.

Se stai impacchettando l'applicazione in un Jar eseguibile, puoi definire direttamente le opzioni che verranno usate dalla macchina virtuale quando eseguirà l'applicazione usando le opzioni -J-

es.

jar -J-Xmx256m -mcf blablabla...

crea un jar che sarà eseguito passando alla macchina virtuale l'opzione -Xmx256m.

Tutte le opzioni -X sono opzioni della macchina virtuale HotSpot di Sun.

Ciao.

[PGI]

cn73, m'hai fregato per un minuto! :D

[cn73]

Originariamente inviato da PGI
cn73, m'hai fregato per un minuto! :D


:O

[Frank1962]

grazie raga ;) .....adesso ho risolo anche questo problema! però ho notato che utilizzando il codice di PGI mi trovo a essere limitato dalla grandezza del buffer; mi spiego meglio, essendo le righe di testo nel file di lunghezza differente mi ritrovo con "oggetti" String di testo che all'ultima riga di solito viene spezzato per poi essere salvato nell'oggetto successivo ...........c'è la possibilità di aggirare questo problema e avere le righe complete!?

ciao e grazie ;)

[PGI]

Per leggere una linea per volta personalmente ti consiglio di restare sul buon vecchio BufferedReader, forse è meno efficiente però il codice che salta fuori è 1000 volte più "rapido da leggere" (e non è una cosa da buttar via).

Con un CharsetDecoder il carattere "new line" è trattato come un carattere qualsiasi, per risolvere dovresti aggiungere un ciclo di "parsing" del testo letto, o tutto quanto, e quindi dopo aver creato una stringa che può anche essere piuttosto grossa, oppure all'interno del ciclo di lettura: togli l' "append", riversi il contenuto del buffer in una stringa intermedia e la parzializzi cercando i caratteri "\n".

Così fancendo sarebbe ancora più efficiente di un bufferedreader? Non lo so, bisognerebbe provare. Sicuramente il codice è un po' più incasinato.

[Frank1962]

Originariamente inviato da PGI
....bisognerebbe provare. Sicuramente il codice è un po' più incasinato.
dici? .....guarda un pò questo codice che ho buttato giù, come ti sembra?


import java.io.*;
import java.nio.*;
import java.nio.channels.*;
import java.nio.charset.*;



public class ReadFile {


static String text = new String("");

static Charset charset = Charset.forName("ISO-8859-1");
static CharsetDecoder charsetDecoder = charset.newDecoder();

static File aFile = new File("C:\\file.bin");
static FileChannel inChannel;
static ByteBuffer buffer;

static {
try {
inChannel = new FileInputStream(aFile).getChannel();
} catch(Exception e) { }
}


public ReadFile() {

buffer = ByteBuffer.allocate((int)aFile.length());

try {

while( inChannel.read(buffer) != -1 ) {
buffer.flip();
text = (charsetDecoder.decode(buffer)).toString();
buffer.clear();
}
inChannel.close();

} catch(IOException e) {
e.printStackTrace(System.err);
System.out.println("End of stack trace"); }

splitting();
}


public void splitting() {
String[] array = text.split("\n");
System.out.println("^_^");
}


}


è valida come soluzione secondo te?

ciao ;)



edit ps: ho separato in un metodo a se stante le righe di codice per splittare così da poter eventualmente modificare lo String text completo in altri modi.

[PGI]

Per funzionare dovrebbe funzionare, bisogna vedere se funziona "meglio".

Prima carichi la stringa in un buffer, poi carichi il contenuto in un array, alla fine potresti ritrovarti con un po' di duplicati.

Ma la cosa è tutta da vedere, perchè il motore di gestione delle stringhe in Java potrebbe anche offrire la possibilità di rimuovere i duplicati usando il metodo "intern()" della classe String, che rimpiazza la stringa generata con un riferimento ad una delle stringhe nel pool in memoria. Forse si potrebbe parzializzare tutto il testo in tanti "token" quante sono le singole parole e richiamare "intern()" su ciascuno di essi. Ma è un'idea un po' così. E poi dipende dalla lunghezza del testo, per 100kb non andrei ad arrovellarmi troppo sulla questione, per 40megabyte però...

Ciao.