ANNOUNCE - graphics package

[Joachim Durchholz]

Olivier Lefevre wrote:

> Full concurrency is certainly an interesting experiment 
> but is it _needed_?

I don't have a definitive answer to this one, but imagine a real-time 
data acquisition application: it will generate a separate stream of 
events that must be integrated into the GUI display.
I'm not entirely sure, but I think keeping things fully concurrent is a 
bonus for that kind of application.

I suspect that this independent event source thing is the key point.
If you have such event sources, it's likely that only a very limited set 
of widgets is interested in them (in the case of data acquisition, the 
events may go to a scrolling event log and/or a status display, there's 
usually no reason why window frames or text input fields should be 
bothered with them).
If you have full concurrency, you can feed these messages directly to 
the interested controls. It's actually easy to set up a process that can 
accept both GUI messages and data acquisition messages, and Do the Right 
Thing with each kind of message.
If you don't have full concurrency, you must feed the independent 
messages into the message dispatcher. This means defining a special kind 
of message, *and* making sure that the message ultimately is dispatched 
to exactly those controls that can make sense of it. That's a horrible 
hassle. (Been there, done that. It's really not a pretty sight, and - 
worst of all - it's something from the application domain, but to 
program it, you need intricate knowledge of the GUI library because you 
have to tamper with one of its central mechanisms, namely message dispatch.)

Here's the grain of salt: I don't know the ins and outs of the decision 
to drop concurrency in Swing.
One of the things that I suspect is that the Java model of concurrency 
is quite heavyweight, which means developers are constantly trying to 
invent mechanisms to circumvent it. Which, of course, means that they 
are going to introduce bugs in that mechanism, which can easily lead to 
the described behaviour.
My other guess is that redrawing wasn't very well-designed in AWT 
(witness the constant "things don't redraw properly" posts by newbies on 
the awt newsgroups), and it may be that Swing inherited these problems. 
(I find it quite strange that redrawing is a difficult task in AWT. 
Actually that's one of the few things that are easy in in Windows... 
it's been ages since I have been bitten by a bug in this area, and only 
if I was handcrafting my own custom controls.)

Regards,
Jo
--
Currently looking for a new job.