Personal Blogs

Java Assertions

Assertions are one of the most useful debugging tools around but from what I have seen using them may not be common Java practice. There are several probable reasons for this:

• assertions came late on the scene only being added to the language in J2SE 1.4.

• control over assertions is a function of a JVM switch not a compiler option. This means that generated code for asserts is included in a deploy build whether or not it is required. (there are ways around this: [jGuru] [Java.net], but nothing particularly inviting unless you want to make your code look like something out of the C++ STL)

• Java provides a detailed but comprehensible stack trace when an exception is thrown making error root cause much easier to identify than in some other languages, at least until comparatively recently.

A Java assertion has the form

assert <boolean expression> : <problem>;

with the : <problem> part being optional. If the boolean evaluates to false and the JVM -ea switch is set a java.lang.AssertionError is thrown with <problem> as its message. <problem> is an expression that evaluates to anything other than void, generally a String.

To set assertions on in NetBeans, right click on the project node and select Properties. Choose Run from the tree and type -ea in the VM Options edit. Alternatively you can click [Customize] and check ea in the list. warning: running from NetBeans part of an AssertionError message may be missing in the output window.

Assertions allow preconditions, post-conditions and invariants to be checked by code that is optionally executed by the JVM bringing these aspects of formal methods (basically VDM) into as-coded reality. Java method specifications are referred to as contracts making contract verification seem quite appropriate. The Java article [here] provides a comprehensive review.

For example: if n < 0, the Math.squrt(n) function returns a Not a Number (NAN) without throwing an exception. NANs have some fairly strange and probably unwanted characteristics when used in computations so we could write our own square root that checks for this problem:

     public static double asqrt(double n) {

        // pre-condition
        assert (n >= 0) : n + ": no real sqrt";

        return Math.sqrt(n);
    }

NetBeans is not clever enough to include the -ea option in its suggested command-line invocation. It must be inserted by hand to run an app. with assertions from a terminal window e.g:

F:\>java -jar -ea "F:\PROGRAMMING PROJECTS\NetBeans\Tests\Assert Test\dist\Asser
t Test.jar
Exception in thread "main" java.lang.AssertionError: -1.0: no real sqrt
        at pkgassert.test.Asserts.asqrt(Asserts.java:14)
        at pkgassert.test.AssertTest.main(AssertTest.java:17)

F:\>

When turned off in the JVM assertions get no runtime overhead apart from a conjectured increase in the time taken to load bigger classes. Admittedly control over their execution is not all it might be but for a small fee and given maybe a day to make it look pretty, I could write a Delphi GUI app. providing navigation to a project directory or to any sub-directory or file that would walk the file tree and strip or remark out assert statements in any java files encountered. Wonder why the Java gurus haven't produced a Java app. to do just that?