È sicuro build widget Swing / AWT NON sul thread di invio eventi?

Ho integrato l’aspetto Sostanza nella mia applicazione e ho incontrato diversi problemi relativi alle routine di controllo interno EDT (Event Dispatch Thread). La sostanza si rifiuta categoricamente di build classi di UI al di fuori dell’EDT. Ho fatto un sacco di Swing / AWT e conosco la maggior parte delle regole riguardanti l’EDT. Io uso SwingWorker, SwingUtilties.invokeLater per modificare i componenti. Ho sempre pensato che i componenti potessero essere COSTRUITI al di fuori dell’EDT, ma devono essere realizzati e manipolati sull’EDT. In altre parole, è ansible build e impostare i valori predefiniti in background, ma la chiamata al pacchetto / setVisible deve essere EDT e tutte le chiamate successive per manipolare il componente.

La ragione per cui chiedo è che ho una finestra particolarmente “robusta” da build, che coinvolge molti widget, stato e risorse (molte icone). Precedentemente, ho costruito la finestra sul metodo di sfondo di uno SwingWorker e ho reso la finestra visibile nel metodo done. Non ho mai avuto un singolo problema. Passando a Sostanza, il controllo EDT interno mi morde.

Sono stato in grado di refactoring codice per aggirare questo. Posso build sull’EDT che non è una buona soluzione poiché l’intera applicazione bloccherà. Posso anche rifattorizzare di più e fare del mio meglio per caricare tutte le risorse extra al di fuori dell’EDT.

Avvolgendolo … È sicuro build i widget Swing / AWT NON sul thread di invio eventi?

Sun ha cambiato le regole nel 2004 – prima, era permesso creare i componenti al di fuori dell’EDT e dovevano solo entrare nell’EDT una volta realizzato il componente.

La nuova regola ora dice:

Per evitare la possibilità di deadlock, è necessario fare molta attenzione che i componenti ei modelli di Swing vengano creati , modificati e interrogati solo dal thread di invio eventi.

questo post sul mio blog fornisce maggiori dettagli, inclusi collegamenti ad altri articoli correlati. nota che tutti gli esempi ufficiali di Sun sono stati riscritti e sono molto severi al riguardo.

storicamente, probabilmente è stata la crescente disponibilità di computer multi-core come macchine desktop a motivare la riformulazione della regola – i problemi di threading sono diventati sempre più evidenti nello stack del client, e essendo molto severi nelle linee guida EDT, molto di loro può essere prevenuto fin dall’inizio.

No.

La semplice ragione è che anche l’EDT ad esempio si blocca in casi rari e in generale è facile bloccare l’interfaccia utente quando si usa Swing ( o almeno così mi è stato detto ). Ti suggerisco di leggere questi tre articoli dal blog di Kirill (the Substance dev):

  • Nuovo articolo sulle violazioni di Swing EDT
  • Regola non scritta di lavorare con EDT di Swing
  • Controlli più severi sulle violazioni EDT nella sostanza