Re: AWT event dispatch thread question

[graydon hoare]

Jeroen Frijters wrote:

> I noticed the recent ClasspathToolkit changes to handle native events
> (nativeQueueEmpty, iterateNativeQueue and wakeNativeQueue) and I was
> wondering if it wouldn't be a better idea to put this stuff in
> EventDispatchThread (and defer construction of the EventDispatchThread
> to the Toolkit implementation).
>
> Any thoughts?

well, you're right that this is possible, but I prefer not to do it. I 
can explain that over the past year or so I have had a particular 
experience with java's API design. you may of course disagree with my 
current conclusion, but I shall outline it here for reference sake, so 
you know where I'm coming from.

there are some places in the java API where is requires a particular 
peer class. in these cases we of course produce the peer class. there 
are other places (fonts, imageio, graphics rendering, event dispatch) in 
which there is the *opportunity* for some peer-ish support machinery, 
but no specified structure.

initially I tried to make a specific peer class for each piece of 
support machinery required. I produced a number of native-backed peer 
classes, for glyph vectors or font metrics or whatnot. and I found these 
were all quite complex to manage the lifecycles of, and require a lot of 
work to debug.

so my preference as time has passed has increasingly been to centralize 
both policy choices *and* mechanism inside the Toolkit; to only produce 
extra peers when it's really necessary. this is merely a matter of 
taste, but I've found that it's easier to reduce the number of classes, 
and make the peer facade more monolithic, than to manage an increasing 
collection of native peers.

-graydon