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