Bug 36679 - Make firing events from winsys synchronous
Make firing events from winsys synchronous
Product: platform
Classification: Unclassified
Component: Window System
All All
: P1 (vote)
: 3.x
Assigned To: Peter Zavadsky
Depends on:
  Show dependency treegraph
Reported: 2003-10-20 08:43 UTC by Peter Zavadsky
Modified: 2008-12-22 21:50 UTC (History)
2 users (show)

See Also:
Issue Type: TASK


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2003-10-20 08:43:35 UTC
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

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....


> 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).


Jesse Glick <mailto:jesse.glick@sun.com> x22801
NetBeans, Open APIs  <http://www.netbeans.org/>
Comment 1 Peter Zavadsky 2004-01-09 12:01:46 UTC
Fixed in [trunk]

Checking in core/windows/src/org/netbeans/core/windows/ModeImpl.java;
/cvs/core/windows/src/org/netbeans/core/windows/ModeImpl.java,v  <-- 
new revision: 1.16; previous revision: 1.15
Checking in core/windows/src/org/netbeans/core/windows/RegistryImpl.java;
<--  RegistryImpl.java
new revision: 1.4; previous revision: 1.3
Checking in
 <--  WindowManagerImpl.java
new revision: 1.17; previous revision: 1.16
Processing log script arguments...
Mailing the commit message to cvs@core.netbeans.org (from

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo