--- jsr166/src/main/intro.html 2003/06/04 11:33:01 1.2 +++ jsr166/src/main/intro.html 2003/08/09 20:00:07 1.12 @@ -1,206 +1,101 @@-
-To join a mailing list discussing this JSR, go to: - http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest . - -
- - Disclaimer - This prototype is experimental code developed as part of - JSR166 and made available to the developer community for use - as-is. It is not a supported product. Use it at your own risk. The - specification, language and implementation are subject to change as a - result of your feedback. Because these features have not yet been - approved for addition to the Java language, there is no schedule for - their inclusion in a product. - - -
-Package java.util.concurrent contains utility classes that are -commonly useful in concurrent programming. Like package java.util, it -includes a few small standardized extensible frameworks, as well as -some classes that provide useful functionality and are otherwise -tedious or difficult to implement. In this JSR, we have been -conservative in selecting only those APIs and implementations that are -useful enough to encourage nearly all concurrent programmers to use -routinely. JSR 166 also includes a few changes and additions in -packages outside of java.util.concurrent: java.lang, to address -uncaught exceptions, and java.util to better integrate queues. -The API covers: - -
-Here are brief descriptions and rationales of the main components. -For details see the javadocs at http://gee.cs.oswego.edu/dl/concurrent/index.html - +This is an updated version of the specification submitted for JCP +Community Draft review. To check for further updates, access a +preliminary prototype release of main functionality, or join a mailing +list discussing this JSR, go to: +http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest +.
+ + Disclaimer. The prototype implementation is experimental +code developed as part of JCP JSR-166 is made available to the +developer community for use as-is. It is not a supported product. Use +it at your own risk. The specification, language and implementation +are subject to change as a result of your feedback. Because these +features have not yet been approved for addition to the Java language, +there is no schedule for their inclusion in a product. + +
Disclaimer. This draft specification was produced +using JDK1.4 tools plus some preprocessing. The resulting javadocs do +not yet correctly render other planned JDK1.5 constructs on which +JSR-166 relies, most notably the use of generic types. We are +releasing this version now (before the availability of JDK1.5-based +tools) because, even though they are misformatted and sometimes lack +proper cross-referencing, they otherwise convey the intended +specifications. + +
JSR-166 introduces package java.util.concurrent +containing utility classes commonly useful in concurrent +programming. Like package java.util, it includes a few small +standardized extensible frameworks, as well as some classes that +provide useful functionality and are otherwise tedious or difficult to +implement. + +
JSR-166 focusses on breadth, providing critical functionality +useful across a wide range of concurrent programming styles and +applications, ranging from low-level atomic operations, to +customizable locks and synchronization aids, to various concurrent +data structures, to high-level execution agents including thread +pools. This diversity reflects the range of contexts in which +developers of concurrent programs have been found to require or desire +support not previously available in J2SE, which also keeping the +resulting package small; providing only that minimial support for +which it makes sense to standardize. + +
Descriptions and brief motivations for the main components may be +found in the associated package documentation. JSR-166 also includes +a few changes and additions in packages outside of +java.util.concurrent. Here are brief descriptions.
Five implementations in java.util.concurrent support the extended -BlockingQueue interface, that defines blocking versions of put and -take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue, -PriorityBlockingQueue, and DelayQueue. Additionally, -java.util.concurrent.LinkedQueue supplies an efficient thread-safe -non-blocking queue. - -
Since the target release is JDK1.5, and generics are slated to be -in 1.5, Queues are parametrized on element type. (Also some others -below.) - - -
Executors provide a framework for executing Runnables. The -Executor manages queueing and scheduling of tasks, and creation and -teardown of threads. Depending on which concrete Executor class is -being used, tasks may execute in a newly created thread, an existing -task-execution thread, or the thread calling execute(), and may -execute sequentially or concurrently. - -
Several concrete implementations of Executor are included in -java.util.concurrent, including ThreadPoolExecutor, a flexible thread -pool and ScheduledExecutor, which adds support for delayed and -periodic task execution. Executor can be used in conjunction with -FutureTask (which implements Runnable) to asynchronously start a -potentially long-running computation and query the FutureTask to -determine if its execution has completed. - -
The Executors class provides factory methods for all -of the types of executors provided in -java.util.concurrent. - - -
-The Locks class additionally supports trylock-designs using builtin -locks without needing to use Lock classes. This requires adding new -capabilities to builtin locks inside JVMs. - -
-A ReadWriteLock interface similarly defines locks that may be shared -among readers but are exclusive to writers. For this release, only a -single implementation, ReentrantReadWriteLock, is planned, since it -covers all standard usage contexts. But programmers may create their -own implementations to cover nonstandard requirements. - -
-To avoid compatibility problems, the names of Condition methods need -to be different than Object versions. The downside of this is that -people can make the mistake of calling cond.notify instead of -cond.signal. However, they will get IllegalMonitorState exceptions if -they do, so they can detect the error if they ever run the code. - - -
Additionally, ThreadLocals will now support a means to remove a -ThreadLocal, which is needed in some thread-pool and worker-thread -designs.