[concurrency-interest] Changes since initial public review spec
Sun, 21 Dec 2003 10:57:30 -0500
We just posted a summary of changes since the initial
public review version of spec (in September), linked from the usual place:
Also pasted in below.
As we head toward final spec, we just made a few sanity-check passes
through APIs, making sure that things we've added or changed have
consistent names and specs. This led to a few minor changes, only one
worth mentioning: We replaced class PriviligedFutureTask (added in
October) with factory method Executors.priviligedCallable. There was
no reason to combine access control mechanics with Future mechanics.
Now you can use a priviligedCallable as the basis for any Future
implementation, not just the particular FutureTask implementation we
If you notice any other issues along these lines, please let us know.
Some of the listed changes will NOT appear in the first early-access
and beta1 Tiger releases. See the directions on the above web page for
how to use current versions anyway using -Xbootclasspath.
JSR166 changes since public review
The JSR166 expert group made the following changes since the initial
JCP public review version of the specification. Most of these were
responses to requests and comments from members of the concurrency
interest list. Additionally, several APIs were refactored to better
accommodate further possible extensions and adaptations brought to our
attention, in particular, those expected for J2EE. Besides numerous
minor specification and implementation improvements, and some
renamings to improve API consistency, the changes include:
1. Execution methods producing Futures that were previously in the
Executors "toolkit" class were renamed as submit and moved to
the ExecutorService interface, with default implementations in a
new AbstractExecutorService class. This enables extended
implementations of ExecutorService to override these methods.
2. Declarations of scheduling methods were abstracted into the new
ScheduledExecutorService interface, and the implementation class
was renamed to ScheduledThreadPoolExecutor. This enables other
implementations to share the same interface.
3. Methods from the Cancellable interface were merged into the
Future interface, and CancellableTask implementation merged into
FutureTask. This eliminates the unhelpful distinction between
cancellability and the ability to wait for termination, that
complicated both usage and extensibility. (Previous uses of
Cancellable can be rephrased as Future<?>.)
4. Support was added for coordinating execution of multiple tasks:
ExecutorService now contains methods invokeAll and invokeAny,
which handle some very common cases. Interface CompletionService
and concrete class ExecutorCompletionService provide a way to
control processing of a set of submitted tasks. Together, these
provide standardized APIs for dealing with common asynchronous
programming problems that were previously lacking.
5. The ExecutorService shutdown methods are more carefully
specified (and implemented) to cleanly fail when invoked by
callers that do not have permission to modify threads.
6. The Executors class now exports its methods producing "wrappers"
that hide configuration settings of concrete ExecutorServices,
so the methods can be used with any other ExecutorService
7. The Executors class now provides methods to convert various
other common "closure" types to Callables so they can be more
readily used in contexts producing Futures.
8. The Executors class now provides a defaultThreadFactory that
places new threads in known states with respect to priority,
daemon status, etc.
9. There is now better support for execution of tasks requiring
special security settings. Method
Executors.privilegedThreadFactory creates threads with the
prevailing access control settings, and
Executors.privilegedCallable and related methods create actions
that run, if allowed, within the settings prevailing when the
actions are created.
10. New replace() methods were added to interface ConcurrentMap and
implementation ConcurrentHashMap. These address some common use
cases previously overlooked.
11. Instrumentation methods were added to the reentrant lock
classes, to enable monitoring for contention etc. The reentrant
lock classes also underwent some internal refactoring visible
only in that they now inherit from new AbstractReentrantLock
class. (This class is exported for the sake of providing
javadocs but is not currently designed for extension outside of
12. Instrumentation methods and "protected" utility methods were
added to Semaphore, and the "fair" variant is now selectable
using a constructor argument rather than being a subclass. These
broaden the range of usefulness of this class.
13. BlockingQueue now supports method drainTo, a bulk-poll operation
that extracts some or all queued elements.