Oui c'est cela, tu ne dois avoir qu'un seul thread (l'EDT) qui manipule les composants graphiques. Si tu as des opérations longues tu les lances par un thread et la mise à jour des composants se met en file d'attente avec la classe SwingUtilities.

C'est pas mal mais il y a 2-3 choses qui me choquent :
- pas de gestion des exceptions sur les flux : les méthodes close() ne sont pas dans des blocs finally
- la mise à jour des logs dans l'IHM ne se fait pas dans l'EDT et il n'y a pas d'utilisation de listener
- la classe serveur qui lance une IHM et la boucle d'attente des connexions en même temps. De mon point de vue, ça devrait séparé et ca te permettrait d'avoir un ActionListener sur la frame pour mettre à jour le TextArea
- côté client, pour l'IHM, il y a le même pb, mise à jour des données sans être dans l'EDT et traitement long dans le même thread

Tu n'es pas dans le cadre d'une application Swing (voir http://gfx.developpez.com/tutoriel/java/swing/swing-threading/ par ex) et tu risques d'avoir des freeze d'IHM

C'est dommage que tu n'as pas développé en objet. Une seule classe Main avec toutes les méthodes static, c'est pas vraiment objet.
Les erreurs ne sont pas gérées par le mécanisme d'exception : une seule variable globale 'erreur'
Et pour les habitués de java, la lecture est difficile car tu n'as pas respecté les conventions de nommage habituelles.

Ecrire un compilo n'est pas super simple (j'ai galéré lorsque j'ai dû en faire 1 en c++), tu aurais pu te faciliter le parsing lexical (construction de l'AST) en utilisant des librairies du style antlr (nécessite de définir les règle du langage par contre)

Une petite ré-écriture en objet serait nickel :)

En voilà une de bonne idée !!! Ca fait longtemps que j'ai pas joué avec Corba. Je vais regarder ça !