PDA

View Full Version : [Java] Due SwingWorker contemporanei nello stesso metodo? Non vanno


s12a
05-05-2010, 21:33
Salve,

Oggi mentre provavo a giocherellare con SwingWorker e sperimentare il multithreading con Swing, ho steso queste righe di codice nel costruttore di un JPanel:

SwingWorker sw1 = new SwingWorker<Void, Void>()
{
@Override
public Void doInBackground()
{
while(true)
{
clock.setText(Long.toString(System.currentTimeMillis()));

try
{
Thread.sleep(25);
}
catch (InterruptedException e)
{
Thread.currentThread().interrupt();
}
}
}
};

SwingWorker sw2 = new SwingWorker<Void, Void>()
{
@Override
public Void doInBackground()
{
while(true)
{
clocc.setText(Long.toString(System.currentTimeMillis()));

try
{
Thread.sleep(250);
}
catch (InterruptedException e)
{
Thread.currentThread().interrupt();
}
}
}
};

sw1.execute();
sw2.execute();

Gli SwingWorker sw1 e sw2 si occupano di modificare in background nell'applicazione due JLabel (clock e clocc) con il tempo in millisecondi di sistema, ad intervalli diversi (non considerate che cio` possa essere possibile con altre implementazioni, e` solo un proof of concept). Quando pero` vado ad eseguirli (ultime due righe di codice), solo la JLabel clock viene modificata, clocc no.

Se commento la penultima riga sw1.execute() invece, la JLabel clocc viene modificata come previsto.

Che cosa succede? E` possibile far partire in background due SwingWorker contemporaneamente dallo stesso metodo? (In questo caso un costruttore, il codice e` stato omesso qui)

Mi aspettavo di si`, ma invece...
O c'e` qualcosa che sbaglio?
Mi aspettavo che gli SwingWorker fossero un'alternativa comoda built-in al creare un EventQueue.invokeLater in un oggetto Runnable incapsulato in un un Thread.

banryu79
05-05-2010, 21:59
Veramente a me così funziona:

import java.awt.GridLayout;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.SwingWorker;

/**
*
* @author francesco
*/
public class DoubleSwingworker extends JPanel
{
public static void main(String[] args) {
JFrame frame = new JFrame("Double SwingWorker");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
DoubleSwingworker dsw = new DoubleSwingworker();
frame.add(dsw);
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}

private JLabel clock, clocc;

public DoubleSwingworker() {
super(new GridLayout(1, 2, 20, 0));

clock = new JLabel("clock");
clocc = new JLabel("clocc");

add(clock);
add(clocc);

SwingWorker sw1 = new SwingWorker<Void, Void>() {
@Override public Void doInBackground() {
while(true) {
clock.setText(Long.toString(System.currentTimeMillis()));
try { Thread.sleep(25);
} catch (InterruptedException e) { Thread.currentThread().interrupt(); }
}
}
};

SwingWorker sw2 = new SwingWorker<Void, Void>() {
@Override public Void doInBackground() {
while(true) {
clocc.setText(Long.toString(System.currentTimeMillis()));
try { Thread.sleep(250);
} catch (InterruptedException e) { Thread.currentThread().interrupt(); }
}
}
};

sw1.execute();
sw2.execute();
}
}

s12a
05-05-2010, 22:04
Mi da' lo stesso problema che ho con il mio codice:

http://img249.imageshack.us/img249/728/clocc.png

In teoria le due JLabel dovrebbero ad intervalli diversi riportare l'orario del sistema in millisecondi.

banryu79
05-05-2010, 22:13
Ah, beh, non saprei :D

Vediamo un po', prova a darci questi dati:
Versione del JDK? della JVM? Su che SO?

s12a
05-05-2010, 22:22
Ah, beh, non saprei :D
Credevo di starmi rincretinendo, invece c'e` davvero qualcosa di strano allora!

Vediamo un po', prova a darci questi dati:
Versione del JDK? della JVM? Su che SO?

Java 6 Update 20 (build 1.6.0_20-b02)
Ho installate sia la versione a 32 che a 64 bit.
(Come IDE uso Eclipse per Windows, il quale e` solo a 32 bit e funziona solo abbinandogli da riga di comando la JVM a 32 bit)
OS: Windows 7 64 bit con tutti gli ultimi aggiornamenti installati.

banryu79
05-05-2010, 22:41
Non noto niente di strano. Più che altro volevo controllare la versione del JDK, francamente.

Comunque io sono su SO WindowsXP, e come ide NetBeans.
La JDK è la 1.6.0_05.

Prova questo codice (i due SwingWorker vengono mandati in esecuzione solo quando viene aperta la finestra, non più nel costruttore):

import java.awt.GridLayout;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.awt.event.WindowListener;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.SwingWorker;

/**
*
* @author francesco
*/
public class DoubleSwingworker extends JPanel
{
public static void main(String[] args) {
JFrame frame = new JFrame("Double SwingWorker");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
DoubleSwingworker dsw = new DoubleSwingworker();
frame.add(dsw);
frame.addWindowListener(dsw.getListener());
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}

private JLabel clock, clocc;
private WindowListener listener;

public DoubleSwingworker() {
super(new GridLayout(1, 2, 20, 0));

clock = new JLabel("clock clock clock");
clocc = new JLabel("clocc clocc clocc");
add(clock);
add(clocc);

final SwingWorker sw1 = new ClockCounter(clock, 25);
final SwingWorker sw2 = new ClockCounter(clocc, 250);

listener = new WindowAdapter() {
@Override public void windowOpened(WindowEvent e) {
sw1.execute();
sw2.execute();
}
};
}

public WindowListener getListener() {
return listener;
}


class ClockCounter extends SwingWorker<Void, Void>
{
final JLabel CLOCK;
final long MILLIS;

public ClockCounter(JLabel lab, long millis) {
CLOCK = lab;
MILLIS = millis;
}

@Override
public Void doInBackground() {
while (true) {
CLOCK.setText(Long.toString(System.currentTimeMillis()));
try {
Thread.sleep(MILLIS);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
}
}

s12a
05-05-2010, 22:44
Idem:

http://img341.imageshack.us/img341/6393/cloccloccclocc.png

Mi chiedo se magari gli ultimi update abbiano introdotto qualche bug o regressione... ma ad occhio mi sembra qualcosa di troppo grosso per passare inosservato.

banryu79
05-05-2010, 22:49
Sembra quasi che da te l'implementazione di SwingWorker usi un thread unico come worker thread...

Aggiungi queste due righe al metodo doInBackground, subito prima del while:

System.out.println("Worker Thread launched:");
System.out.println(Thread.currentThread().getName());


A me a runtime stampa:

run:
Worker Thread launched:
SwingWorker-pool-1-thread-2
Worker Thread launched:
SwingWorker-pool-1-thread-1

s12a
05-05-2010, 22:50
Si`, hai ragione. Questo e` quello che stampa a me.
Il secondo thread non parte:

Worker Thread launched:
SwingWorker-pool-1-thread-1

banryu79
05-05-2010, 22:53
Estratto dai sorgenti del mio JDK (metodo execute di SwingWorker):

/**
* Schedules this {@code SwingWorker} for execution on a <i>worker</i>
* thread. There are a number of <i>worker</i> threads available. In the
* event all <i>worker</i> threads are busy handling other
* {@code SwingWorkers} this {@code SwingWorker} is placed in a waiting
* queue.
*
* <p>
* Note:
* {@code SwingWorker} is only designed to be executed once. Executing a
* {@code SwingWorker} more than once will not result in invoking the
* {@code doInBackground} method twice.
*/
public final void execute() {
getWorkersExecutorService().execute(this);
}

Parrebbe che da te, l'implementazione ha a disposizione solo 1 thread libero come "worker thread"... Il perchè francamente lo ignoro :D

Se vuoi avere confrema al 100% prova a eseguire un ciclo che termina dopo un po' nel doInBackground: finita l'esecuzione del primo SwingWorker dovresti notare la partenza del secondo...

PGI-Bis
05-05-2010, 22:59
Sorpresa! :D

E' un bug di SwingWorker.

http://bugs.sun.com/view_bug.do?bug_id=6880336

in pratica dalla 1.6._17 fino alla 20 "execute" è bloccante. Puoi aggirare il problema con:

ExecutorService pool = Executors.newFixedThreadPool(2);
pool.submit(sw1);
pool.submit(sw2);
pool.shutdown();

Ps.: il "setText" va messo nel metodo process di SwingWorker, non nel doInBackground.

s12a
05-05-2010, 23:03
Estratto dai sorgenti del mio JDK (metodo execute di SwingWorker):

Parrebe che da te, l'implementazione ha a disposizione solo 1 thread come "worker thread"... Il perchè francamente lo ignoro :D
Anche io :stordita:

Se vuoi avere confrema al 100% prova a eseguire un ciclo che termina dopo un po' nel doInBackground: finita l'esecuzione del primo SwingWorker dovresti notare la partenza del secondo...

Avevo gia` effettuato qualche prova precedentemente: se faccio partire il primo SwingWorker, non poi non posso far partire il secondo, neanche se interrompo il primo.

Sorpresa! :D

E' un bug di SwingWorker.

http://bugs.sun.com/view_bug.do?bug_id=6880336

in pratica dalla 1.6._17 fino alla 20 "execute" è bloccante. Puoi aggirare il problema con:

ExecutorService pool = Executors.newFixedThreadPool(2);
pool.submit(sw1);
pool.submit(sw2);
pool.shutdown();

Ah, pero`. Ed e` anche diverso tempo che sta li`!
Vedro` di tenere conto della soluzione.

Ps.: il "setText" va messo nel metodo process di SwingWorker, non nel doInBackground.
Grazie per il suggerimento!

banryu79
05-05-2010, 23:13
Sorpresa! :D
E' un bug di SwingWorker.

PGI, se non ci fossi, bisognerebbe inventarti! :Prrr:

s12a
06-05-2010, 12:13
Ps.: il "setText" va messo nel metodo process di SwingWorker, non nel doInBackground.

Scusate l'up, ma ho provato a documentarmi in merito e non mi e` assolutamente chiaro come implementare il tutto in process piuttosto che in doInBackground.

Lo SwingWorker qui da' problemi nel metodo process. @Override non da' nemmeno come corretto l'overloading del metodo:

SwingWorker<Void, Void> sw1 = new SwingWorker<Void, Void>() {
@Override public Void doInBackground() { return null; }
@Override protected void process(Void x) {
while(true) {
try {
clock.setText(Long.toString(System.currentTimeMillis()));
Thread.sleep(25);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
};

Thread t2 = new Thread(new Runnable() {
@Override public void run() {
while(true) {
try {
SwingUtilities.invokeLater(updater);
Thread.sleep(200);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
});

sw1.execute();
t2.start();

Per il momento trovo molto piu` pratico ed intuitivo creare un nuovo thread come da esempio qui sopra (updater e` un Runnable che aggiorna la seconda JLabel una sola volta).

PGI-Bis
06-05-2010, 13:58
Per il tipo di compito che esegue il tuo esempio è più comodo javax.swing.Timer.

Timer timer = new Timer(periodo, new ActionListener() {
public void actionPerformed(ActionEvent e) {
aggiorna etichetta
}
});
timer.start();

Bug a parte, funziona anche con SwingWorker.

new SwingWorker<Void, Void>() {
protected Void doInBackground() throws Exception {
while(true) {
Thread.sleep(25);
publish();
}
}

protected void process(List<Void> chunks) {
etichetta.setText(System.currentTimeMillis());
}
}.execute();

Il contenuto di doInBackground è eseguito dal thread di SwingWorker, il contenuto di process è eseguito dall'EDT.

s12a
06-05-2010, 14:18
Per il tipo di compito che esegue il tuo esempio è più comodo javax.swing.Timer.
Si`, come scritto nel primo post questo e` solo del codice semplice per testare il concetto.

Bug a parte, funziona anche con SwingWorker.

[...]

Il contenuto di doInBackground è eseguito dal thread di SwingWorker, il contenuto di process è eseguito dall'EDT.

Ok, grazie per l'aiuto, funziona perfettamente in questo modo!

Ecco i tre modi che ho avuto modo di provare per fare la stessa identica cosa:

SwingWorker<Void, Void> sw1 = new SwingWorker<Void, Void>() {
@Override public Void doInBackground() {
while(true) {
try {
Thread.sleep(25);
publish();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
@Override protected void process(List<Void> chunks) {
clock.setText(Long.toString(System.currentTimeMillis()));
}
};

Thread th2 = new Thread(new Runnable() {
private Runnable updater = new Runnable() {
@Override public void run() {
clocc.setText(Long.toString(System.currentTimeMillis()));
}
};

@Override public void run() {
while(true) {
try {
SwingUtilities.invokeLater(updater);
Thread.sleep(200);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
});

Timer tm3 = new Timer(350, new ActionListener() {
@Override public void actionPerformed(ActionEvent arg0) {
clokk.setText(Long.toString(System.currentTimeMillis()));
}
});

sw1.execute();
th2.start();
tm3.start();

Effettivamente il timer e` la scelta che comporta meno codice e piu` semplicita` per questa specifica operazione.

banryu79
06-05-2010, 15:15
Il contenuto di doInBackground è eseguito dal thread di SwingWorker, il contenuto di process è eseguito dall'EDT.

Curiosità mia: nel caso si usi SwingWorker, ma è proprio neccessario far eseguire una setText (che è uno dei pochi metodi di Swing ad essere thread-safe) nel metodo process, invece che in doInBackground?

PGI-Bis
06-05-2010, 15:41
Direi che il setText a cui fai riferimento sia quello di JTextComponent.

banryu79
06-05-2010, 15:49
Direi che il setText a cui fai riferimento sia quello di JTextComponent.
Proprio quello... d'ho! :doh:

s12a
06-05-2010, 17:25
Non c'entra piu` molto con lo scopo iniziale del thread, ma visto che ci siamo mi chiedevo solo se in merito a questa applicazione un po' piu` pratica di uno SwingWorker (sempre comunque di prova/a scopi didattici) fosse possibile eliminare il return null evidenziato. Per qualche motivo qui mi viene richiesto. Nella prova precedente di qualche post fa l'ho omesso e non ho avuto problemi:

import java.awt.EventQueue;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.List;
import java.util.Random;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JProgressBar;
import javax.swing.SwingWorker;
import javax.swing.UIManager;
import javax.swing.WindowConstants;

import net.miginfocom.swing.MigLayout;

public class ProgressPanel extends JPanel {
ProgressPanel() {
setLayout(new MigLayout("wrap 1"));

progress.setMinimum(0);
progress.setMaximum(100);

add(statusLabel, "align center");
add(progress, "grow");
add(startButton, "grow");

startButton.addActionListener(new ActionListener() {
@Override public void actionPerformed(ActionEvent e) {
startButton.setEnabled(false);

new SwingWorker<Void, Void>() {
@Override public Void doInBackground() {
statusLabel.setText("Status: working");

while(progress.getValue() < 100) {
try {
Thread.sleep(rand.nextInt(30));
publish();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
System.out.println("Worker thread " + Thread.currentThread().getName() + " abnormally interrupted");
}
}

statusLabel.setText("Status: done!");

startButton.setEnabled(true);
startButton.setText("Quit");
startButton.addActionListener(new ActionListener() {
@Override public void actionPerformed(ActionEvent e) {
System.exit(0); // Temporary implementation
}
});

return null; // ???
}
@Override protected void process(List<Void> chunks) {
progress.setValue(progress.getValue() + 1);
}
}.execute();
}
});
}

private JProgressBar progress = new JProgressBar();
private JButton startButton = new JButton("Start processing");
private JLabel statusLabel = new JLabel("Status: idling");
private Random rand = new Random();

public static void main(String[] args) {
if (args.length > 0) {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {
System.out.println ("Unable to set the platform Look&Feel");
}
}

EventQueue.invokeLater(new Runnable() {
@Override public void run() {
JFrame frame = new JFrame("Saving file");
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
frame.setVisible(true);
frame.add(new ProgressPanel());
frame.pack();
}
});
}
}

Nota: per qualche motivo copiaincollando il codice da Eclipse alcuni tab vengono riprodotti in maniera un po' strana, non e` colpa mia.

PGI-Bis
06-05-2010, 17:37
nel post precedente il compilatore rileva il while(true) e capisce che quel metodo non restituirà mai il controllo, rendendo superfluo un return che non sarà mai eseguito. E' una volpe :D.

Nel secondo caso non c'è una condizione assimilabile quindi il compilatore pretende giustamente un valore restituito.

Il return null è imposto dal tipo restituito dal metodo doInBackground: Void, con la V maiuscola, che è il contraltare riflessivo del void con la v minuscola. Esiste un unico valore compatibile con Void è ed null, da cui il return null.

s12a
06-05-2010, 17:39
Capisco, non immaginavo tenesse conto di queste piccolezze.
Grazie ancora! :)

s12a
06-05-2010, 18:32
Questa volta non ho niente da chiedere, volevo semplicemente aggiungere una implementazione piu` completa e funzionale dello SwingWorker di prima (magari puo` essere utile a qualcuno, chissa`!). Il JButton ora non viene piu` disabilitato, ma una volta premuto, cambia funzionalita` e permette di annullare l'operazione in corso mediante cancel().

Il metodo doInBackground() dopo essere stato terminato da cancel() passa il controllo per le operazioni finali a done(). Devo ammettere che tutto sommato SwingWorker usato cosi` e` piuttosto pratico ed elegante. Peccato per il bug irrisolto.

startButton.addActionListener(new ActionListener() {
@Override public void actionPerformed(ActionEvent e) {
new SwingWorker<Void, Void>() {
@Override public Void doInBackground() {
statusLabel.setText("Status: working");
startButton.setText("Cancel");
startButton.addActionListener(new ActionListener() {
@Override public void actionPerformed(ActionEvent e) {
cancel(true);
}
});

while((progress.getValue() < 100) || (!isCancelled())) {
try {
Thread.sleep(rand.nextInt(100));
publish();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}

return null;
}

@Override protected void process(List<Void> chunks) {
progress.setValue(progress.getValue() + 1);
}

@Override protected void done() {
if(!isCancelled())
statusLabel.setText("Status: done!");
else
statusLabel.setText("Status: canceled");

startButton.setText("Quit");
startButton.addActionListener(new ActionListener() {
@Override public void actionPerformed(ActionEvent e) {
System.exit(0); // Temporary implementation
}
});
}
}.execute();
}
});

EDIT: Unico dubbio che mi e` venuto adesso e` se i vari setText() vanno formalmente bene li` dove sono.

EDIT2: Un'altra nota. L'ordine di verifica delle condizioni qui evidenziate pare essere piuttosto importante:
while((progress.getValue() < 100) || (!isCancelled())) {
try {
Thread.sleep(rand.nextInt(100));
publish();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
Se inverto le due condizioni (metto !isCancelled() prima di progress.getValue() < 100), si verificano strani malfunzionamenti.
Cosi` come l'ho scritto in ogni caso funziona correttamente, ma ho l'impressione che ci sia qualcosa che non vada.
Ad esempio se uso && (come comunque il caso dovrebbe suggerire) al posto di || l'avanzatore continua a proseguire, al pulsante non viene cambiato il testo come dovrebbe, ma premendolo due volte (?) l'applicazione termina come dovrebbe.

EDIT3: Risolto :)
L'origine dei problemi era che mi ero scordato di rimuovere dal JButton gli EventListener pre-assegnati prima di assegnarne di nuovi.
Non immaginavo che se ne potesse assegnare piu` di uno contemporaneamente.