Arquivo Discussoes de Programacao e Tecnologia 
Peguei esse exemplo no site da sun:
public class MyApplication {
public static void main(String[] args) {
JFrame f = new JFrame("Labels");
// Add components to
// the frame here...
f.pack();
f.show();
// Don't do any more GUI work here...
}
}
Com a seguinte explicação:
Pelo que pude entender, o f.pack() vai executar, e o f.show() vai logo em seguida, mesmo que o f.pack() não tenha terminado… isso pode ser thread-safe??
Tradução google:
valeus
Não tente entender por essa tradução… vai piorar um pouco as coisas…rs
O texto em si eu entendo, mas não entendi bem o porquê de ser thread-safe… Alguém pode explicar com outras palavras?
Um pouco?
Tradução ao estilo Babelfish de ser…
Se entendi bem SÓ é seguro porque não tem nenhum código de GUI depois de f.show(), caso contrário não seria.
Quando a API do Swing foi feita, foi escolhido que ela não seria ThreadSafe para que eles fizessem o maior número de features/componentes num dado período de tempo(na época,há uns 10 anosatrás…).Fazer tudo “sobcontrole”, exigiria um esforço maior, e um número muito grande de testes de controle para isso, e eles argumentaram que muitas chamadas/controles não eram necessárias mais do que uma Thread.O probleam é que quando essa Single Thread da AWT(q é thread safe, mas com alguns c´digos dependente de sistema operacional) que processa os eventos Swing e todos os tratamentos de eventos do seu sistema, começa a processar códigos pesados/lentos , e todo o programa começa a congelar, dando aqueles lags e probelminhas chatos como uma tela meio cinzenta.Para isso foi criado mecanismos como o SwingUtilities que permite rodar esses códigos mais elaborados em Thread separada, notificando os demais componentes do código para se atualizarem.
Ou seja, enviar o código praa fila da AWT thread, por exemplo usando EventQueue.invokeLater para por nessa fila.
uma explicação aqui: http://www.jguru.com/faq/view.jsp?EID=131370