--- intro.html 2003/07/14 16:35:59 1.8 +++ intro.html 2003/08/05 14:36:04 1.9 @@ -1,73 +1,102 @@ - JSR 166 Snapshot Introduction. + JSR 166 Community Review Draft Introduction. -

JSR 166 Snapshot Introduction.

+

JJSR 166 Community Review Draft Introduction.

by Doug Lea

-To join a mailing list discussing this JSR, go to: - http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest . - +To chack for updates to this draft, 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 - This prototype is experimental code developed as part of - JCP 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. - - -

JSR166 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, prviding 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 thread pools. -Descriptions of the main components may be found in the associated -package documentation. -

JSR166 also includes a few changes and additions in packages -outside of java.util.concurrent. Here are brief descriptions. + 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.

Queues

A basic (nonblocking) {@link java.util.Queue} interface extending -java.util.Collection is introduced into java.util. Existing class -java.util.LinkedList is adapted to support Queue, and a new -non-thread-safe {@link java.util.PriorityQueue} is added. - -

Uncaught Exception Handlers

- -The java.lang.Thread class is modified to allow per-thread -installation of handlers for uncaught exceptions. Ths optionally -disassociates these handlers from ThreadGroups, which has proven to be -too inflexible in many multithreaded programs. (Note that the -combination of features in JSR166 make ThreadGroups even less likely -to be used in most programs. Perhaps they will eventually be -deprecated.) - -

High precision timing

- -Method nanoTime is added to java.lang.System. It -provides a high-precision timing facility that is distinct from -and uncoordinated with System.currentTimeMillis. +{@link java.util.Collection} is introduced into +java.util. Existing class {@link java.util.LinkedList} is +adapted to support Queue, and a new non-thread-safe {@link +java.util.PriorityQueue} is added. + +

Threads

+ +Two minor changes are introduced to the {@link java.lang.Thread} +class: It now allows per-thread installation of handlers for uncaught +exceptions. Ths optionally disassociates handlers from ThreadGroups, +which has proven to be too inflexible. (Note that the combination of +features in JSR-166 make ThreadGroups even less likely to be used in +most programs. Perhaps they will eventually be deprecated.) Secondly, +access checks are no longer required when a Thread interrupts +itself. The interrupt method is the only way to +re-assert a thread's interruption status (and in the case of +self-interruption has no other effect than this). The check here +previously caused unjustifiable and uncontrollable failures when +restricted code invoked library code that must reassert interruption +to correctly propagate status when encountering some +InterruptedExceptions. + +

Timing

+ +Method nanoTime is added to {@link java.lang.System}. It +provides a high-precision timing facility that is distinct from and +uncoordinated with System.currentTimeMillis.

Removing ThreadLocals

-The java.lang.ThreadLocal class now supports a means to remove a -ThreadLocal, which is needed in some thread-pool and worker-thread +The {@link java.lang.ThreadLocal} class now supports a means to remove +a ThreadLocal, which is needed in some thread-pool and worker-thread designs. + +
Doug Lea