RE: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronous

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi Scott,

to me, Futures and Listeners don't need to be a contradiction.
What's more interesting to me, is how to deal with Progress.
When a Progress Monitor already exists for the client, then
using it makes a lot of sense even if the result is obtained
asynchronously:

final CBFuture<IFileStore[]> childrenF = myFileStore.list(myProgress);
childrenF.chain(new Callback() {
   public void onDone(IStatus result) {
      if (result.isOK()) {
         handleResult(childrenF.get());
      }
   };
});

I'm using class "CBFuture" as an "enhanced Future" that allows
registering Callbacks. Using a Callback style of handling things,
or CBFuture.waitFor() remains up to the client. Note that I'm 
using a "chain()" method to indicate that the Framework/Future could
allow chaining multiple callbacks such that one is exeucuted after 
the other. Also note how the callback retrieves the result of 
computation from the Future, and not from the callback itself.

The problems that I have seen with callbacks in our products
in the past are listed on 
http://wiki.eclipse.org/E4/Pervasive_Themes#Becoming_More_Asynchronous

* Much boilerplate code - Closures would be nice to avoid explosion
  of anonymous inner classes, which could cause bloat

* Need clarification on what thread and in what context the 
  callback will be called

* When debugging, it is very hard to trace back the flow of 
  operation across multiple callback invocations. It can even
  make debuging close to impossible unless some Tracing 
  functionality for the callbacks is built into the Framework
  (we ended up doing this in our commercial product).

* Exception handling needs to be clarified. Java6 Future only
  provides Future#isCanceled(), that's not enough since the 
  result of an operation might also be an exception. I'm 
  introducint "Istatus result" above but that's also not 
  optimal.

The synchronous variant needs more verbosity writing it than 
one would expect, because cancellation and errors (exceptions)
need to be handled, wrapped and potentially re-wrapped with 
Futures:

final CBFuture<IFileStore[]> childrenF = myFileStore.list(myProgress);
try {
   handleResult(childrenF.get());
} catch(CancellationException e) {
   throw new OperationCancelledException(e);
} catch(ExecutionExeption e) {
   throw new CoreException(new Status(/*.blabla*/));
}

although that could perhaps be simplified if we declared some 
Eclipse specific implementation of Future which throws the
kinds of Exceptions that we already know (like CoreException
embedding an Istatus) instead of the JRE's ExecutionException
that's really alien to our current code.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm