ANNOUNCE - graphics package

[Olivier Lefevre]

> Possibly, I've never used swing.

The reason I said it's like Swing is that in Swing, too, everything is done in Java (save for
the lowest-level operations, such as creating the window and allocating space for it on the
screen), so you don't have this chasm to cross whenever you want to modify a widget: you
just extend and override. This is in contrast to the Tk (or, in Java, the SWT) approach in 
which every widget maps to a native one and you must drop down to C if you want to 
change anything.

Re. concurrency, I am also very curious to see if it will work. As Luke pointed out, Swing
was indeed made single-threaded after disastrous experiences with concurrent updates.
I think the problem was that with programs whose execution is under your control you can
reason about race conditions, deadlocks etc but GUIs, which are driven by unpredictable
user input, are harder to reason about and to secure. Furthermore in practice I have found
the trick of "injecting" a task into the AWT event queue (using SwingUtilities.invokeLater)
is perfectly sufficient in practice. Full concurrency is certainly an interesting experiment 
but is it _needed_?

-- O.L.