[concurrency-interest] Executor framework adjustments

Doug Lea dl@cs.oswego.edu
Wed, 10 Dec 2003 08:36:59 -0500


It took us a few days to realize that we had missed one (and we really
hope, last) impediment that might hinder J2EE extensions and
adaptations. The "Executors" class was the only vehicle for linking
together implementations of Executors and Futures (in the "invoke" and
"execute" methods), but it forced use of the default FutureTask
implementation. This would have required some extensions to create a
similar but different Executors-like class just for the sake of
breaking this link. The solution required a bit more refactoring:
These methods are now in the ExecutorService interface, with default
implementations (still using FutureTask) in new
AbstractExecutorService class. This also required renaming the
execute-and-return-Future methods to "submit" because they cannot be
legally overloaded vs the base "execute" method. The ScheduledExecutor
methods also work similarly.

With this change, we are becoming more confident that a viable J2EE
API could mainly consist of a way to create or access an
ExecutorService (and similarly ScheduledExecutor) implementation that
infused appropriate J2EE context in the tasks and/or executors.

People using the existing/beta1 versions may need to adjust their
code, although in easy ways-- mainly changes of the form:
  Future f = Executors.execute(exec, task) 
to 
  Future f = exec.submit(task)

Sorry for this churn, but it is far better to address these issues now
than for everyone to suffer the consequences of eventual forced
J2SE/J2EE inconsistencies.

As always, comments would be very welcome.

-Doug