Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 41: A Simple Assertion Facility

Stage Access Start Finish
Final Release Download page 09 May, 2002  
Final Approval Ballot View results 04 Dec, 2001 17 Dec, 2001
Proposed Final Draft Download page 07 Jun, 2001  
Public Review Download page 26 Apr, 2000 26 May, 2000
Participant Review Login page 28 Feb, 2000 30 Mar, 2000
CAFE   13 Nov, 1999 21 Dec, 1999
JSR Approval   06 Nov, 1999 12 Nov, 1999
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0


Description:
A new keyword allowing programmers to include assertions describing intended program behavior, which can be checked as programs execute to detect bugs.



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

Team

Specification Leads
  Joshua Bloch Sun Microsystems, Inc.
Expert Group
  Borland Software Corporation Gomes, Benedict Hart-Davis, Damon
  Lea, Doug Sun Microsystems, Inc.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Submitting Participant: Sun Microsystems, Inc.
Name of Contact Person: Joshua Bloch
E-Mail Address: jbloch@eng.sun.com
Telephone Number: +1 408 343 1833
Fax Number: +1 408 343 1797

Section 2: Request

2.1 Please describe the proposed Specification:
Assertions are boolean expressions that the programmer believes to be true concerning the state of a computer program. For example, after sorting a list, the programmer might assert that the list is in ascending order. Evaluating assertions at runtime to confirm their validity is one of the most powerful tools for improving code quality, as it quickly uncovers the programmer's misconceptions concerning a program's behavior. Because there is a cost associated with checking assertions, it is highly desirable that it be possible to selectively disable assertion checking.

Many popular programming languages, including C and C++, have widely used and appreciated preprocessor-based assertion checking facilities. Several more recent programming languages, including Sather and Eiffel, have assertion-checking constructs as part of the language. The Java programming language was originally slated to contain such a construct, but due to time constraints, the construct never made it into the language. We propose to add such a facility, with the following characteristics:

  • The facility should be simple and intuitive; it should not change the character of the language. The facility should be sufficiently pleasant to use that its use becomes widespread.
  • It should be possible to disable the facility at a reasonably fine granularity, and to enable assertion checking in the field.
  • The facility should impose negligible runtime cost when it is disabled.
  • The facility should require no change to the class file format, and little or (preferably) no change to the JVM.
2.2 What is the target Java platform?
The Java programming language. (All editions of the Java platform.)
2.3 What need of the Java community will be addressed by the proposed specification?
The need for a standard assertion facility to aid in writing high-quality software. Currently, only ad hoc facilities exist, and the use of assertions has not entered the mainstream in the Java community. This feature is one of the most frequently requested enhancements on the JDC (number 2 RFE on the bug parade).
2.4 Why isn't this need met by existing specifications?
There are currently no specifications in this area.
2.5 Please give a short description of the underlying technology or technologies:
The proposed facility is efficiently implementable atop current day JVMs, requiring only a very modest change to the compiler.
2.6 Is there a proposed package name for the API Specification?
(We anticipate no new packages would be added as a result of this specification.)
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
No.
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?
We may want to make some provision for localized assertion failure messages.
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.

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.
Sun has developed a proposal for simple assertion facility. It is hoped that this API will form the basis for the specification.
3.2 Explanation of how these items might be used as a starting point for the work.
In the usual way: the expert committee will study the proposal for shortcomings and do its best to rectify them.