So I just learned that Java's GUI-framework "Swing" is not thread-safe (and neither is Microsoft's "Windows Forms"). What that means is that GUI components may only be manipulated by a single thread. If you ignore this fact (or simply assume that the framework has to be thread-safe when in reality it is not), you better be prepared for some really weird errors (aka race conditions) or in the case of WinForms, exceptions.

There are several justifications for that, one of which is performance (locking is expensive, whether you're using multiple threads or not) and the other is pragmatism (most GUI applications are single-threaded). This is all good, but we're in a multi-core world now and unless you want your applications to become slower in the future, you'll eventually have to go multi-threaded as well.

The problem is that once you go multi-threaded, you'll have to make sure yourself, that you synchronize access to the GUI-components. This is something to get wrong very easily and since most programmers aren't concurrency experts, I'm sure that the number of concurrency-related bugs in GUI-applications will go up dramatically in the future. That's why I'm inclined to think that it would have been better to make these frameworks thread-safe from the start, because unlike most GUI-programmers, the library writers at Sun and Microsoft tend to know what they're doing (no offense).