Name: mc57594			Date: 12/16/99


java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)

Problem:

We were looking for a way to execute long running operations synchronously while
having the UI be responsive to paint requests and blocking all input events.
After extensive search for a solution to this problem we noticed that the common
response to the related problem of running long operations was to use
SwingWorker.  However, SwingWorker performs the work asynchronously so it did
not meet our synchronous requirement.  Synchronous behaviour is necessary since
we wanted to wrap any method, at any level, as a long operation.
  
We then proceeded to implement a busy long operation UI framework to achieve
these objectives but ran into serious difficulties along the way due mainly to
the single UI event queue architecture of AWT.  We used the ability to push a
(temporary) new event queue but encountered some undesirable effects related to
old queued up UI input events.  The framework works well in almost 100% of
scenarios but there are still a few scenarios that we must avoid (which we have)
to prevent lockups.  Part of the difficulty is the fact that both input events
and paint events share the same UI queue.   Ideally, to easily support this
concept, two UI queues would be necessary, one for painting and one for
non-paint events.  This design would not have concurrency issues (which is the
main reason for the current single queue design) since both paint events and UI
input events would still be serialized but each in their own queue.

Hence, our enhancement request...


Request:

This is a request for a framework to support the synchronous execution of a long
operation with proper 'busy' feedback.   Here are requirements for such a
framework:

The framework must easily support alternative implementations of showing busy
feedback while executing long operations (e.g. show wait cursor, show animated
gif, do nothing, etc...), including non-UI specific implementations.  As such, a
separation should exist between the declaration of a long operation and its
actual busy feedback behaviour at runtime.  This allows, for example, a long
operation to be wrappered within a Runnable to behave differently in terms of
'busy' feedback depending on the busy feedback handler currently active at the
time the long operation is executed.  A specific example is a server call being
wrapped as a long operation which can be reused between two different
applications that actually show different 'busy' side-effects when that server
call is executed.  One application could be a UI front end which simply shows a
wait cursor over open views while the other application could be a server
application which could implement a neutral (i.e. do nothing) implementation for
the 'busy' feedback (since nobody is watching...).   We have already implemented
such a framework but we believe it should be part of the JDK (no issues were
encountered meeting this requirement).  Note that the implementation of this
framework has no dependencies on the next point (#2).

In particular a UI flavour implementation of a long operation handler should be
provided (the reason for this request) with the following characteristics:

a) Framework must support the execution of a long running operation while
showing busy UI side effects.

b) All open views must be blocked for user input while the long operation is
executing.

c) Active (normal) repainting behaviour must be maintained while the long
operation is in progress so that momentarily surfacing other views on top of a
?busy? view, for example, does not cause the busy view to appear hung for the
remainder of the long operation due to lack of repainting.

d) Calls using the framework must be executed synchronously (i.e. SwingWorker
won't do since it executes the long operation asynchronously).  In addition to
keeping the synchronous continuity of method calls, this makes it easier for
developers to remain ?unaware? of the fact that a method called may run as a
long operation resulting in a decoupled and maintainable solution.  Basically,
if you call a method that takes a long time to execute it will automatically
trigger the desired busy side effects while you wait.

e) Any wrappered long operation should be callable at any depth in the code
without affecting the order in which some events get executed, including
invokeLater calls imbedded within a long operation.  This was a difficult
objective to achieve and we imposed some restrictions on the use of
invokeLater's (which are not prevalent on our system).

f) The framework must support nested long operation calls and behave
appropriately, including the handling of modal dialogs launched within a long
operation.  For example if a method is called that invokes a long operation and
that long operation invokes a nested long operation, the nested long operation
should simply execute the call since it is within the scope of the active 'busy'
side effects.

g) The UI busy side-effect should be a pluggable piece of the framework such
that different styles of visible feedback over busy views can be supported.  We
did not implement this since we chose our preferred method of displaying busy
feedback to the user.
(Review ID: 98857) 
======================================================================
###@###.### 11/4/04 19:32 GMT