Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

J2SE 1.4 premieres Java's assertion capabilities, Part 2

Understand the methodology impact of Java's new assertion facility

By Wm. Paul Rogers, JavaWorld.com, 12/14/01

  • Print
  • Feedback
.
Assertions are a fairly simple construct added to the soon-to-be released J2SE (Java 2 Platform, Standard Edition) 1.4. As a basic description, an assertion specifies a boolean-typed expression a developer explicitly demands must be true at a specific point of program execution. In Part 1 of this two-part series, I covered the mechanics of using the new J2SE assertion facility. This article discusses the methodology of using assertions and explores the assertion facility's ramifications on Java design and implementation.

Read the whole series on J2SE 1.4's assertion capabilities:



Though a simple construct, assertions have broad implications on the approach to writing solid Java programs. Developers might aspire to create right programs, but attaining such an elusive and subjective quality actually proves quite difficult. What exactly is right, and what measures or metrics determine rightness? Those questions, of course, have no definitive answer, but the software engineering community does recognize and discuss software quality attributes. One such attribute is software reliability, and many of software engineering's best practices take direct aim at improving software products' reliability. In this article, I show how assertions deal with the reliability aspect known as correctness, which complements another reliability aspect, robustness. I also show the Java assertion facility to be but a small step toward a more complete and formal approach to reliability in software development known as Design by Contract.

Robustness and correctness

Reliability ranks as a highly desirable trait in many products. I expect my car to provide reliable transportation. I expect my raincoat to keep me reliably dry in a pouring rain. And, yes, I expect the software I use to be reliable as well.

But what exactly is reliable software? Software engineering texts define reliability as the probability of a system operating without failure over a specified time under a specified set of conditions. That, unfortunately, comes across as pedantic. Users typically consider reliability to mean the software does what it's supposed to do without crashing. That, unfortunately, is quite subjective, just the type of characteristic engineers find an anathema, which explains why they fashioned the "over a specified time under a specified set of conditions" clause. That clause attempts to create a measurable event, and engineers find comfort in measurable events.

A middle ground accepts that users expectations are subjective, but still strives to produce reliable software. Although subjective, reliability can be dealt with objectively. Reliability can be categorized by two broad strokes: robustness and correctness. Robustness pertains to a system's ability to reasonably react to a wide variety of circumstances and possibly unexpected conditions. Correctness pertains to a system's adherence to an explicit or external specification.

  • Print
  • Feedback

Resources
  • Recent JavaWorld articles on exception handling:
  • Browse our Topical Index for more stories on the Java 2 Platform, Standard Edition: http://www.javaworld.com/channel_content/jw-j2se-index.shtml
  • Read more JavaWorld articles by Wm. Paul Rogers