Go to JSR:
On this page:
 
Print Format
JSRs: Java Specification Requests
JSR 166: Concurrency Utilities

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

  Status: Final              
  Stage       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  
   
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0
Please direct comments on this JSR to: jsr-166-comments@jcp.org
 
 
Specification Lead
Doug Lea   Lea, Doug 
 
Expert Group
Bowbeer, Joseph   Goetz, Brian   Google Inc.
Holmes, David   Lea, Doug   Peierls, Tim
SAP AG   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 http://gee.cs.oswego.edu/dl/concurrency-interest/


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: dl@cs.oswego.edu

Telephone Number: +1 315 312 2688

Fax Number: +1 315 312 5424


Specification Lead: Doug Lea

E-Mail Address: dl@cs.oswego.edu

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:

Sun



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.)

J2SE

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.)

java.util.concurrent

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?

No

2.9 Are there any internationalization or localization issues?

No

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

No

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
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

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: http://sourceforge.net/projects/jhpc
JThreadKit: http://www.jthreadkit.com/

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.

None



 
Sun Microsystems
What's New
JSRs
JCP Procedures
Community Resources
Participation
Press & Success
What is the JCP