Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4300198

Framework to handle synchronous long operations with busy feedback



    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 1.2.2
    • Fix Version/s: None
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
    • CPU:
    • OS:


      Name: mc57594 Date: 12/16/99

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


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


      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

      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

      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


          Issue Links



              dav Andrei Dmitriev (Inactive)
              mchamnessunw Mark Chamness (Inactive)
              0 Vote for this issue
              0 Start watching this issue