Copy of Jesse's arguments:

Peter Zavadsky wrote:

> I changed the firing events from RegistryImpl
(and also other components like WindowManagerImp
etc.) to asynchronous and always scheduled into
AWT thread. Originaly it was changed due to older
implementation of TC.requestFocus, which caused
neverending looping when doing activating (which
caused the even firing etc.)... to break
>  that loop. The older impl was changed,


How? Probably you can just set a flag that you are
inside the body of one method and to ignore your
own change events you plan on firing. This breaks
the loop. Or you may be able to somehow mark the
event object as your own, etc. Or detach the
self-listener before making the mutation, and
reattach after (in a finally block).

> but I left the firing of events that way so we
can claim there are
> always fired in AWT thread and that their
handlers don't affect the
> state of winsys if there are more changes
performed during that task
> inside winsys.


Event handlers must not mutate the state of the
event source. Feel free to enforce this with
assertions. Set a flag before firing events (clear
in a finally block) and assert !firing before
processing any mutation-type events.

> Example of the difference: before: 1) call
TC.setActivatedNodes(nodes) in some thread, 2) you
get property change from TC.Registry synch in that
thread.


Well probably wrong just because such calls should
be in EQ.

> now: 1) call TC.setActivatedNodes(nodes) in some
thread, 2) you get property change from
TC.Registry always asynch in AWT thread (event the
above is AWT thread too -> it is still asynch).


Not so good, I think.

(1) You should not be permitted to call
TC.setActivatedNodes out of EQ. I would strongly
recommend the method start with

assert EventQueue.isDispatchThread();

There is no compatibility issue here as it was
always documented that winsys methods are EQ-only.
Just enforce it.

(2) If you call TC.sAN in EQ, IMHO the event
should be fired synchronously.

> I've read some time ago you recomended somewhere
event firing to be synchronous.


Generally yes.

> If I understand right... that is if an object
which is changed also fires the events (typically
from its setter) it should follow that rule....


Right.

> But I guess this is not case of winsys (the
changed object TC is not the event source
TC.Registry) which I see kind of swing system,
where you get the event firing also asynch manner.


What asynch manner in Swing system? AFAIK
AWT/Swing components normally fire changes synch.
I'm sure there are exceptions somewhere, but the
rule is synch firing (and access only in EQ,
except for text document models).

-J.

-- 
Jesse Glick <mailto:jesse.glick@sun.com> x22801
NetBeans, Open APIs  <http://www.netbeans.org/>