Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 166: Concurrency Utilities

Stage Access Start Finish
Final Release Download page 30 Sep, 2004  
Final Approval Ballot View results 31 Aug, 2004 13 Sep, 2004
Proposed Final Draft Download page 22 Mar, 2004  
Public Review Download page 07 Oct, 2003 06 Dec, 2003
Community Draft Ballot View results 09 Sep, 2003 15 Sep, 2003
Community Review Login page 15 Aug, 2003 15 Sep, 2003
Expert Group Formation   23 Jan, 2002  
JSR Review Ballot View results 08 Jan, 2002 22 Jan, 2002
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

The JSR proposes a set of medium-level utilities that provide functionality commonly needed in concurrent programs.

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Doug Lea Lea, Doug
Expert Group
  Bowbeer, Joseph Goetz, Brian Google Inc.
  Holmes, David Lea, Doug Peierls, Tim
  SAP SE Sun Microsystems, Inc.

Updates to the Original Java Specification Request (JSR)

For additional information, sample draft APIs, and access to an interest-group mailing list for JSR-166, go to

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Doug Lea

Name of Contact Person: Doug Lea

E-Mail Address:

Telephone Number: +1 315 312 2688

Fax Number: +1 315 312 5424

Specification Lead: Doug Lea

E-Mail Address:

Telephone Number: +1 315 312 2688

Fax Number: +1 315 312 5424

Initial Expert Group Membership:

Joshua Bloch, Sun
Sam Midkiff, IBM
David Holmes
Joseph Bowbeer
Tim Peierls

Supporting this JSR:


Section 2: Request

2.1 Please describe the proposed Specification:

This JSR has aims analogous to those of the JDK1.2 Collections package:

1. To standardize a simple, extensible framework that organizes commonly used utilities into a small enough package to be readily learnable by users and maintainable by developers.

2. To provide some high-quality implementations.

The package will consist of interfaces and classes that tend to be useful across diverse programming styles and applications. These classes include:
Atomic variables.
Special-purpose locks, barriers, semaphores and condition variables.
Queues and related collections designed for multithreaded use.
Thread pools and custom execution frameworks.

We will also examine related support in the core language and libraries.

Note that these are entirely distinct from transactional concurrency control frameworks used in J2EE. (However, they will be useful to those creating such frameworks.)

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)


2.3 What need of the Java community will be addressed by the proposed specification?

Low level threading primitives, such as synchronized blocks, Object.wait and Object.notify, are insufficient for many programming tasks. As a result, application programmers are often forced to implement their own higher level concurrency facilities. This results in enormous duplication of effort. Further, such facilities are notoriously hard to get right and even more difficult to optimize. The concurrency facilities written by application programmers are often incorrect or inefficient. Offering a standard set of concurrency utilities will ease the task of writing a wide variety of multithreaded applications and generally improve the quality of the applications that use them.

2.4 Why isn't this need met by existing specifications?

Currently, developers can use only the concurrency control constructs provided in the Java language itself. These are too low level for some applications, and are incomplete for others.

2.5 Please give a short description of the underlying technology or technologies:

The vast majority of the package will be implemented on top of lower-level Java constructs. However, there are a few critical JVM/language enhancements surrounding atomicity and monitors necessary to obtain efficient and correct semantics.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)


2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

Only indirectly, in that JVMs running on different platforms may be able to differently optimize some constructions.

2.8 Are there any security issues that cannot be addressed by the current security model?


2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.11 Please describe the anticipated schedule for the development of this specification.

The goal is to include this specification in the J2SE 1.5 (Tiger) umbrella JSR.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

E-mail, teleconferences, and infrequent meetings. We will also use or create an open mailing list for discussions by other interested people outside the expert group.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Doug Lea's package, available at

This package has been available for over three years, which has resulted in usage experience that will be exploited in defining this standardized package.

Others similar packages include:
The JHPC package:

3.2 Explanation of how these items might be used as a starting point for the work.

It is likely that some of the classes and interfaces will be similar to those in Lea's package. The initial members have already begun creating draft specifications.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.