[concurrency-interest] Changes since initial public review spec

Angelika Langer langer@camelot.de
Wed, 18 Feb 2004 20:28:56 +0100

Forgive me if this is an entirely silly question ...

In an early release of the concurrency utilities there was a class Locks 
which had a method newConditionFor(Object o).  In the current beta 
release of Tiger I cannot find it anymore and the list of changes does 
not mention it either.

What happened to it?  Has it been replaced by anything?

Angelika Langer
Angelika Langer
Email: langer@camelot.de

Doug Lea wrote:

> We just posted a summary of changes since the initial
> public review version of spec (in September), linked from the usual place:
>   http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
> 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
> provide.
> 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
>       implementation.
>    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
>       the package.)
>   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.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest