[java] semplice programma che non parte

[bouncey2k]

ho tentato di fare un semplice programma utilizzando Eclipse, però mi da diversi errori. Sono noob in questo campo quindi vorrei capire il perché degli errori. Di seguito il codice:


import javax.swing.*;

public class TwoWindows {
public static void main(String[] args) {
JFrame w1 = new JFrame("Grande");
JFrame w2 = new JFrame("Piccola");

w1.setSize(200, 125);
w2.setSize(150, 100);

w1.setVisible(true);
w2.setVisible(true);
}
}


Di seguito gli errori:

Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit
at java.awt.Toolkit.getDefaultToolkit(libgcj.so.70)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(libgcj.so.70)
at java.awt.Window.<init>(libgcj.so.70)
at java.awt.Frame.<init>(libgcj.so.70)
at javax.swing.JFrame.<init>(libgcj.so.70)
at TwoWindows.main(TwoWindows.java:5)
Caused by: java.lang.UnsatisfiedLinkError: libgtkpeer: libgtkpeer.so: cannot open shared object file: No such file or directory
at java.lang.Runtime._load(libgcj.so.70)
at java.lang.Runtime.loadLibrary(libgcj.so.70)
at java.lang.System.loadLibrary(libgcj.so.70)
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(libgcj.so.70)
at java.lang.Class.initializeClass(libgcj.so.70)
at java.lang.Class.forName(libgcj.so.70)
at java.awt.Toolkit.getDefaultToolkit(libgcj.so.70)
...5 more

[PGI-Bis]

Dalla traccia dell'errore parrebbe quasi che tu stia usando Classpath, che è un principio di piattaforma Java sviluppato da GNU.

Prova con il JDK di Sun Microsystem. Se l'hai già installato, controlla che Eclipse lo stia usando (prova a frugare tra le opzioni del progetto).

P.s.: il programma non è corretto ma si tratta di un errore che non si manifesta con quella traccia, per cui non risolverà il tuo problema correggerlo in:

import javax.swing.*;

public class TwoWindows {
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() { public void run() {
JFrame w1 = new JFrame("Grande");
JFrame w2 = new JFrame("Piccola");

w1.setSize(200, 125);
w2.setSize(150, 100);

w1.setVisible(true);
w2.setVisible(true);
}});
}
}

[Slayer86]

L'errore non è dovuto al tuo sorgente che è corretto, si compila e avvia senza problemi... probabilmente il problema è quello indicato da PGI-Bis prova a compilarlo e avviarlo senza usare eclipse ovvero utilizzando il prompt comandi quiundi con i comandi javac e java vedi se parte è un errore nella configurazione di eclipse

[PGI-Bis]

Il programma non è corretto perchè affida una transizione di stato di un componente Swing proiettabile ad un Thread diverso dall'AWT Event Dispatcher (o EDT). Questa non è la causa dell'eccezione riportata nel messaggio. Ma è comunque un errore.

[Slayer86]

Il programma non è corretto perchè affida una transizione di stato di un componente Swing proiettabile ad un Thread diverso dall'AWT Event Dispatcher (o EDT). Questa non è la causa dell'eccezione riportata nel messaggio. Ma è comunque un errore.

Mi puoi chiarire un po meglio questa cosa??:D

[bouncey2k]

Come faccio a controllare che Eclipse usi JDK? Da dove lo vedo?
Ma poi come fa il codice a essere errato? L'ho copiato pari pari da un libro. :mbe:

[PGI-Bis]

Il codice proposto in quel libro è errato.

bouncy2k si è dato alla programmazione concorrente. Che è un modo di programmare assolutamente affascinante. In Java è inevitabile quando si usino le librerie AWT/Swing.

La macchina virtuale esegue il codice contenuto nel metodo "main" in un Thread che, con grande fantasia, si chiama Main Thread.

Il framework AWT/Swing è costruito attorno al presupposto che un solo ed unico Thread modifichi gli stati di un componente AWT/Swing proiettabile. Un componente è proiettabile se è connesso, direttamente o tramite il suo contenitore, alla radice di un albero di proiezione. La radice di un albero di proiezione è la controparte nativa del pannello radice delle finestre e degli applet. Viene creato dal framework swing durante il processo di realizzazione di una finestra o di un'applet. E' quella fetta di schermo su cui concretamente viene disegnato il contenuto di una finestra AWT/Swing.

La meccanica del framework AWT/Swing presuppone che un solo Thread legga e scriva le proprietà di un componente proiettabile. Ma non lo impone, se non in casi isolati, per ragioni di performance.

Le conseguenze derivanti dal mancato rispetto di questa condizione sono tutte quelle che derivano dall'accesso concorrente a risorse condivise non protette. La più banale è la lettura di un valore errato o la scrittura di un valore in una regione di memoria diversa da quella realmente usata per la proiezione del componente.

Imposto il testo di un'etichetta a "ciccio" e l'etichetta non si aggiorna. Leggo il testo di un'etichetta che ha la scritta "miao" e mi ritrovo null. Invoco frame.setVisible(true) e la finestra non compare.

La conseguenza più grave è il blocco dell'applicazione per dead-lock. Alcune parti del framework (tabelle, split pane, alberi, i layout manager eccetera) acquisiscono temporaneamente un controllo esclusivo su alcune risorse. Il tentativo di acquisire il controllo esclusivo di una risorsa bloccata da un altro Thread causa l'attesa del Thread richiedente per la liberazione di quella risorsa da parte del Thread detentore. Se la liberazione della risorsa è condizionata al rilascio di una seconda risorsa, in proprietà attuale del Thread richiedente, l'applicazione entra in stallo.

Sun dimostrò, un milione di anni fa, come tale evenienza potesse verificarsi nel semplice caso:

public static void main(String[] args) {
JTable table = new JTable();
JFrame frame = new JFrame();
frame.getContentPane().add(table);
frame.show(); //oggi rimpiazzato da setVisible(true)
}

Il problema era in show() (e oggi in setVisible). L'istruzione comporta due cose. La realizzazione del componente, eseguita dall'AWT Event Dispatcher Thread (questo il nome completo dell'unico Thread pressuppost). E la richiesta di proiezione, eseguita dal Thread Main.

Onde evitare spiacevoli conseguenze, del genere:

-Ciao sono Giovannino. Ti ricordi l'applicazione che mi hai venduto?
-Ciao. Sì certo. Come va? Va bene?
-Molto bene. Ieri si è bloccata e ho perso una giornata di lavoro!
-Oh caspita. Aspetta che vengo lì e vediamo.
-No, sono venuto, io. Sono qui sotto col bastone.

si può approfittare a mani basse degli strumenti che Sun ha introdotto per facilitare il rispetto della precondizione del Thread unico.

L'AWT Event Dispatcher Thread, o EDT, ha accesso ad una coda di eventi. Periodicamente estrae un evento da questa coda e lo consuma. L'evento è rappresentato da un oggetto di tipo Runnable. Runnable è un'interfaccia con un solo metodo, run().

Per far sì che un Thread diverso dall'EDT affidi l'esecuzione di uno o più compiti all'EDT, quel Thread può creare e passare alla coda degli eventi un'istanza di Runnable il cui metodo run contenga le istruzioni da eseguire.

Se prendiamo il codice di bouncey2k (estratto dal metodo main):

JFrame w1 = new JFrame("Grande");
JFrame w2 = new JFrame("Piccola");
w1.setSize(200, 125);
w2.setSize(150, 100);
w1.setVisible(true);
w2.setVisible(true);

notiamo che le istruzioni che gestiscono lo stato di un componente Swing proiettabile sono due:

w1.setVisible(true);
w2.setVisible(true);

Prima di "setVisible" nè w1 nè w2 sono componenti "proiettabili". setVisibile, invece, deve essere considerata istruzione che agisce su un componente proiettabile perchè la documentazione ci dice che se la finestra non è già proiettabile (come sarebbe se, ad esempio, prima di setVisible fosse invocato pack()) allora essa viene resa proiettabile prima di essere visualizzata. Queste due istruzioni devono essere affidate all'AWT Event Dispatcher Thread. Per farlo occorre creare un Runnable che le incapsuli nel suo metodo run:

Runnable runner = new Runnable() {
public void run() {
w1.setVisible(true);
w2.setVisible(true);
}
};

Per (ulteriori) questioni di concorrenza, ciò richiede che w1 e w2 siano dichiarate final. Dopo aver incapsulato le istruzioni in parola, è possibile affidarne l'esecuzione (che si traduce nell'invocazione del metodo run di runner) all'EDT tramite:

EventQueue.invokeLater(runner);

oppure il più significativo ma equivalente:

SwingUtilities.invokeLater(runner);

Vale la pena di ricordare come non solo la scrittura ma anche la lettura di stati di componenti AWT/Swing proiettabili debba essere condotta dall'EDT.

Il framework semplifica molto la faccenda dichiarando che il l'esecuzione dei metodi di ascolto degli ascoltatori di eventi, semantici o di basso livello, è affidata all'EDT, qualora essi non siano direttamente invocati dal programmatore (caso in cui è responsabilità del programmatore produrre l'invocazione all'interno dell'EDT). Significa che se mi trovo nel corpo del metodo actionPerformed di un ActionListener allora so di essere già nell'EDT e non devo usare SwingUtilities o Runnable nè per leggere nè per scrivere valori da e per componenti proiettabili.

[PGI-Bis]

Per controllare la piattaforma Java usata da Eclipse:

menu Window -> Preferences -> espandi la voce "Java", seleziona la voce "installed JRE" e vedi cosa ti da sia nella voce che in execution environment. Se vedi GNU Classpath fulminalo.

[Slayer86]

Grazie della spiegazione dopo aver fatto un esame di Sistemi operativi e due di informatica non avevo ancora mai incontato il problema della concorrenza all'interno del metodo setVisible certo sapevo dei problemi di dead-lock dovuti all'utilizzo di un unico thread per la gestione dell'interfaccia grafica e degli altri aspetti dell'applicazione... però non si finisce mai di imparare :)

[bouncey2k]

grazie per avermi fatto passare la voglia di imparare il java :sofico:

ho modificato il codice e l'errore che mi da è il seguente:

Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit
at java.awt.Toolkit.getDefaultToolkit(libgcj.so.70)
at java.awt.EventQueue.invokeLater(libgcj.so.70)
at javax.swing.SwingUtilities.invokeLater(libgcj.so.70)
at TwoWindows.main(TwoWindows.java:5)
Caused by: java.lang.UnsatisfiedLinkError: libgtkpeer: libgtkpeer.so: cannot open shared object file: No such file or directory
at java.lang.Runtime._load(libgcj.so.70)
at java.lang.Runtime.loadLibrary(libgcj.so.70)
at java.lang.System.loadLibrary(libgcj.so.70)
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(libgcj.so.70)
at java.lang.Class.initializeClass(libgcj.so.70)
at java.lang.Class.forName(libgcj.so.70)
at java.awt.Toolkit.getDefaultToolkit(libgcj.so.70)
...3 more


mentre in window>preferences>ecc.. c'è scritto java-1.4.2-gcj-4.1-1.4.2.0

[PGI-Bis]

E' un dettaglio della libreria, Java è innocente. Comunque molti framework per la costruzione di GUI presuppongono l'uso di un solo thread.

>> java-1.4.2-gcj-4.1-1.4.2.0 <<

Se hai solo questa piattaforma Java installata, prova un apt-get sun-java. O scarica il JDK per linux dal sito di sun.

[bouncey2k]

quando cerco di istallare qualcosa mi da questo errore --> http://www.hwupgrade.it/forum/showthread.php?t=1475523

[PGI-Bis]

Prova a scaricare dal sito di Sun Microsystem il file di installazione local-manuale del JDK per Linux.

link al sito (https://sdlc5b.sun.com/ECom/EComActionServlet;jsessionid=8122B2FD4F967C1202D752BA1ADF2700)

Prendi il "Linux Self Extracting File (jdk-6u1-linux-i586.bin)".

Lo schiaffi nella cartella utente e poi da Eclipse vai a cercarlo e lo imposti come JRE/JDK corrente.

[bouncey2k]

a parte che il file non me lo inserisce (è grigino, non si seleziona), ma poi JDK dovrei averlo di già. Dal menu principale di ubuntu, vado su add/remove e vedo che Java Runtime, Console e Webstart sono già istallati! :eek: :eek: