Michael Emmel wrote:
> Hello I've been working for a while on and all java Windowing system.
> My current version is written on top of the Swing toolkit. Which is
> practically all Java.
> Well it turns out even Swing is flawed.
>
> The problem with Swing is the attempt to reuse Graphics context and not
> being thread safe. ...
Could we pause for a moment here, and have you explain
the problem in greater detail? In particular, what is
the problem with not being thread-safe?
It seems to me that the Swing architects came to
a conclusion about how to write thread-safe programs:
thread safety is difficult. The best way to achieve
it is to carefully segment programs such that the
interfaces between threads are particularly well understood.
For instance, rather than allowing lots of threads to call the
many methods of a Graphics or other complex object,
and attempt to have all these methods lock all
the resources they reference in a way that avoids deadlock,
only allow simple objects like queues to be used by
multiple threads. That's why Swing is not thread-safe:
they expect you to segment your program so that only
one thread manages the user interface, and communicates
with the rest of your program through a carefully
designed thread-safe interface (e.g. a queue or two).
I happen to have helped fix a bunch of deadlocks in
a complicated Java user interface by doing just that,
so I trust their judgement.
You go on to write:
> The NT thread model is flawed it allows race conditions.
I thought NT implemented threads fairly well-
and that's why Java code that runs on other Java ports
sometimes has race conditions on NT Java, because
those other platforms don't do preemptive multithreading,
and therefore hide race conditions.
This is an interesting discussion, but it probably
deserves to be split up into a few pieces- the
Swing discussion should probably move to comp.language.java.gui.
- Dan
