Thread in Java

[asdf]

Ho implementato un programmino che mi copia i file da una cartella ad un'altra, facendo comparire una finestra con la percentuale dello stato dello spostamento.
Il problema e' che eseguendo il tutto in un'unico processo, la copia ciuccia tutte le risorse e non fa aggiornare la finestra con la percentuale (quasi non si vede),
e comunque non posso schiacciare il tasto annulla, perche' in fase di copia non riesce a sentire l'input.

Quindi ho pensato di avviare la copia in un thread a parte, in modo tale da permettere l'input (e quiindi poter annulare l'operazione di copia) e poter far aggiornare la finestra.

Il problema e che non so come fare (dovrei sapere quando la copia e' terminata, per poter avviare la copia di un altro file, e nel contempo rendere la finestra con la percentuale sensibile all'input, quindi non posso farci sopra una sleep)

Grazie

[cn73]

Dai un'occhiata: http://www.pctuner.net/Software/Java/CercaFiles.zip

[asdf]

Grazie, appena avro' un po' di tempo ci daro' un'occhiata

[cn73]

Qualche dritta

private Timer timer;
public final static int ONE_SECOND = 1000;

...

//Create a timer.
timer = new Timer(ONE_SECOND, new TimerListener());

...
class TimerListener implements ActionListener {
        public void actionPerformed(ActionEvent evt) {
            ....            
        }
    }


timer.start();

nell'actionPerformed puoi mettere il codice che vuoi venga eseguito ogni secondo...

[PGI]

Non ho capito bene se hai bisogno di un algoritmo per trasferire i file uno alla volta o se un codice di esempio per far funzionare e controllare un thread; nel dubbio allego un file di testo che contiene un esempio di entrambi.
Riassumendo, una volta ottenute le directory di partenza e destinazione, "infili" i file da trasferire in un array e poi esegui un ciclo, tramite un thread, trasferendo i file uno alla volta; alla pressione del tasto stop sulla finestra di dialogo il booleano "goOn" viene impostato a false e questo provoca l'uscita dal ciclo eseguito all'interno del metodo "run()" del thread.

Ciao.

[cn73]

PGI...mi permetti un'osservazione simpatica??
Se tu risolvi sempre tutti i problemi di chi posta in questo modo, quando imparano (impariamo)?? Meglio dare delle dritte no??

[asdf]

Ri-Grazie.
Modifichero' l'esempio di PGI aggiungendoci il codice che mi serve

PS. Io la lettura del file la faccio tutta in una volta, diminuendo gli accessi al disco ed accelerando la velocita'.
Domani vi carichero' il codice (e' una riga, solo che ora non mi ricordo la sintassi precisa)

[PGI]

Originariamente inviato da cn73
[b]PGI...mi permetti un'osservazione simpatica??
Se tu risolvi sempre tutti i problemi di chi posta in questo modo, quando imparano (impariamo)?? Meglio dare delle dritte no??

Mannaggia ho appena risposto da un'altra parte!

Ti dirò che le mie intenzioni sono sempre del tipo "ti posto questo e poi discutiamo un po' su cosa e come" ma alla fine ci ritroviamo io e te a discutere nel thread di altri (cosa che a me fa piacere, ma sembriamo due virus che si infilano in ogni conversazione)

x asdf

Occhio che quel codice genera errori a tutto spiano appena incontra qualcosa che non sia un file leggbile.

[cn73]

Originally posted by "PGI"

Mannaggia ho appena risposto da un'altra parte!

Ti dirò che le mie intenzioni sono sempre del tipo "ti posto questo e poi discutiamo un po' su cosa e come" ma alla fine ci ritroviamo io e te a discutere nel thread di altri (cosa che a me fa piacere, ma sembriamo due virus che si infilano in ogni conversazione)

x asdf

Occhio che quel codice genera errori a tutto spiano appena incontra qualcosa che non sia un file leggbile.

eh eh...hai ragione...avessi + tempo!! Posso chiederti cosa fai nella vita, ti vedo molto, ma molto preparato sull'argomento Java...

[asdf]

Ieri finalmente ho trovato un po' di tempo da dedicare al mio programmino, e sono finalmente riuscito a fare il thread: ora la copia funziona che e' una meraviglia

Ps. ecco come copio io i file in una stringa

FileInputStream in = new FileInputStream(openList);
byte[] readFile=new byte[in.available()];
int totByteRead=in.read(readFile);
String tot=new String(readFile);

[cn73]

Meglio:

  try 
    { 
      File fileInst = new File(nomeFile); 
      FileReader file = new FileReader(nomeFile); 
      char[] c = new char[(int)fileInst.length()]; 
      file.read(c); 
      String buffer = String.copyValueOf(c); 
      file.close(); 
    
    } 
    catch(Exception ex) 
    { 
       System.err.println("Exception raised by <getBuffer>: "+ex); 
     }

[kingv]

Originally posted by "cn73"

Meglio:

char[] c = new char[(int)fileInst.length()];

e' saggio se mettere un "if" sul quella fileInst.length()

[cn73]

E perchè mai?

[DvL^Nemo]

Se usi Swing devi avere la classe SwingWorker, leggiti i tutorial della SUN
A me era capitata una cosa del genere sull'esecuzioni di query pesanti su DB.. Con un thread a parte e la classe Swing Worker ho risolto il problema che se non erro e' simile al tuo..
Ciao !

[cn73]

Originally posted by "DvL^Nemo"

Se usi Swing devi avere la classe SwingWorker, leggiti i tutorial della SUN
A me era capitata una cosa del genere sull'esecuzioni di query pesanti su DB.. Con un thread a parte e la classe Swing Worker ho risolto il problema che se non erro e' simile al tuo..
Ciao !

E infatti + presente nell'esempo che gli indicavo sopra...cmq se non lo avesse letto, lo riporto:

package cercafiles;

import javax.swing.SwingUtilities;

/**
 * This is the 3rd version of SwingWorker (also known as
 * SwingWorker 3), an abstract class that you subclass to
 * perform GUI-related work in a dedicated thread.  For
 * instructions on using this class, see:
 * 
 * http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
 *
 * Note that the API changed slightly in the 3rd version:
 * You must now invoke start() on the SwingWorker after
 * creating it.
 */
public abstract class SwingWorker {
    private Object value;  // see getValue(), setValue()
    private Thread thread;

    /** 
     * Class to maintain reference to current worker thread
     * under separate synchronization control.
     */
    private static class ThreadVar {
        private Thread thread;
        ThreadVar(Thread t) { thread = t; }
        synchronized Thread get() { return thread; }
        synchronized void clear() { thread = null; }
    }

    private ThreadVar threadVar;

    /** 
     * Get the value produced by the worker thread, or null if it 
     * hasn't been constructed yet.
     */
    protected synchronized Object getValue() { 
        return value; 
    }

    /** 
     * Set the value produced by worker thread 
     */
    private synchronized void setValue(Object x) { 
        value = x; 
    }

    /** 
     * Compute the value to be returned by the <code>get</code> method. 
     */
    public abstract Object construct();

    /**
     * Called on the event dispatching thread (not on the worker thread)
     * after the <code>construct</code> method has returned.
     */
    public void finished() {
    }

    /**
     * A new method that interrupts the worker thread.  Call this method
     * to force the worker to stop what it's doing.
     */
    public void interrupt() {
        Thread t = threadVar.get();
        if (t != null) {
            t.interrupt();
        }
        threadVar.clear();
    }

    /**
     * Return the value created by the <code>construct</code> method.  
     * Returns null if either the constructing thread or the current
     * thread was interrupted before a value was produced.
     * 
     * @return the value created by the <code>construct</code> method
     */
    public Object get() {
        while (true) {  
            Thread t = threadVar.get();
            if (t == null) {
                return getValue();
            }
            try {
                t.join();
            }
            catch (InterruptedException e) {
                Thread.currentThread().interrupt(); // propagate
                return null;
            }
        }
    }


    /**
     * Start a thread that will call the <code>construct</code> method
     * and then exit.
     */
    public SwingWorker() {
        final Runnable doFinished = new Runnable() {
           public void run() { finished(); }
        };

        Runnable doConstruct = new Runnable() { 
            public void run() {
                try {
                    setValue(construct());
                }
                finally {
                    threadVar.clear();
                }

                SwingUtilities.invokeLater(doFinished);
            }
        };

        Thread t = new Thread(doConstruct);
        threadVar = new ThreadVar(t);
    }

    /**
     * Start the worker thread.
     */
    public void start() {
        Thread t = threadVar.get();
        if (t != null) {
            t.start();
        }
    }
}

[kingv]

Originally posted by "cn73"

E perchè mai?

se e' un file di 500 mega pensi di copiarlo tutto in un aray e poi riscriverlo?

[cn73]

Originally posted by "kingv"

se e' un file di 500 mega pensi di copiarlo tutto in un aray e poi riscriverlo?

Non per nulla è messo in un try catch...Solitamente il programmatore non deve preoccuparsi della memoria: Ha a disposizione uno spazio di indirizzi, poi è il Sistema Operativo che so occupa di gestirlo e distribuirlo fra memoria reale e virtuale...
Un'altra cosa poi è ottimizzare...

[cionci]

Solitamente si utilizza comunque un buffer di dimensione fissa... Swappare la memoria fisica su disco è un lavoro molto dispendioso per il sistema opertivo...
Ti ritroveresti con il tuo programma che occupa 500 Mb e tutti glia ltri progammi dovrebbero essere swappati... Pensa poi se la memroia fisica fosse 128 Mb... In quel caso sai quanto swap !!!

[kingv]

Originally posted by "cn73"

Non per nulla è messo in un try catch...Solitamente il programmatore non deve preoccuparsi della memoria: Ha a disposizione uno spazio di indirizzi, poi è il Sistema Operativo che so occupa di gestirlo e distribuirlo fra memoria reale e virtuale...
Un'altra cosa poi è ottimizzare...

se non ti preoccupi della memoria e fai fare tutto a jvm e sistema operativo dopo due giorni fai parte della schiera di quelli che dicono che java e' lento (tipo cionci ).

il problema cui mi riferivo cmq non era questo, se bufferizzi il tutto porti a termine la copia anche se il file e' di 1 giga, se il tuo programma va in OutOfMemoryError o simili verosimilmente no. E in ogni caso usare il try e catch come gestione dei problemi applicativi (come ad esempio un file troppo grosso per stare in memoria) e' sintomo di programmazione scadente...

[cn73]

Non per niente ho specificato che l'ottimizzazione di un programma è un'altra cosa...parli con uno che deve preoccuparsi di implementare un metodi dispose per ogni classe grafica pena un decadimento prestazionale intollerabile... e che mette a null tutte le variabili prima di uscire da un metodo perchè come saprai avolterimangono dei riferimenti a un oggetto di una classe e questo impedisce al garbadge collector di liberare le risorse...

Le scelte implementative dipendono dal tipo di programma che uno deve realizzare... Allora lo stesso discorso vale sempre: qualunque struttura o tipo o classe tu usi, se devi trattare un file di 100 terabyte ti voglio vedere...