Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Pinpoint Code Problems Using Java's Assertion Facility  : Page 3

Java developers have had the capability to include assertions in their code only since version 1.4. This article explains why, when, and how to use Java assertions to help you find and fix problems with your code—before you deploy it.




Application Security Testing: An Integral Part of DevOps

Toggling Assertions During Compilation and Execution
As exemplified in Figure 1, the assertions feature is disabled by default at run time. This was done to solve binary compatibility issues with previous versions of Java that do not support assertions. Consequently, to use assertions, you first need to compile programs with the —source flag set to a value of 1.4 as shown below:

javac --source 1.4 AssertExample.java

In addition to enabling assertions during compile time, you also need run the program with assertion checking enabled, which you do via the —enableassertions option (or —ea for short).

java --enableassertions AssertionExample

Fortunately, enabling assertions isn't an all-or-nothing proposition. You don't have to enable assertions for your entire application; you can specify the granularity of your assertions. For example, you can enable assertions for a single package by using the —ea option followed by a colon and name of the package. Following the package name by an ellipsis (…) enables assertion checking for the package and for its subpackages, for example:

java --ea:com.example... AssertionExample

You can exclude a class from assertion checking using the—disableassertions or—da option followed by a colon and the name of the class to exclude.

java --ea:com.example… -da:com.example.ClassToExclude AssertionExample

The preceding code disables assertions for the com.example.ClassToExclude class while enabling it for all the other classes in the com.example package.

Enabling Assertions Programmatically
While you will most likely want to enable assertions via the command line, the Java 1.4 assertion facility also allows you to enable and disable assertion checking programmatically. For example, the class AssertProgrammatically (shown below) uses the class Auxiliary (also shown below). Note that the AssertProgrammatically class enables assertions for the Auxiliary class when it loads the class.

public class AssertProgrammatically { public static void main(String args[]) { System.out.println( "Example of enabling assertions " + "programmatically."); ClassLoader classLoader = AssertProgrammatically .class .getClassLoader(); classLoader.setClassAssertionStatus( "Auxiliary", true); int i = 3; System.out.println("Sending: " + i); Auxiliary auxiliaryI = new Auxiliary(i); System.out.println( "i is: " + auxiliaryI.whatAmI()); i = -3; System.out.println("Sending: " + i); Auxiliary auxiliaryJ = new Auxiliary(i); System.out.println( "i is: " + auxiliaryJ.whatAmI()); } } public class Auxiliary { private int myInt; Auxiliary(int incoming) { myInt = incoming; } public int whatAmI() { assert myInt>0 : "i must be positive"; return myInt; } }

As the preceding code shows, to programmatically enable or disable assertions, you first obtain the ClassLoader of the class, and then enable or disable assertions using a line such as:


Figure 3. Executing the AssertProgrammatically Class: From the output shown in this figure, you can see that the assertion checking doesn't occur via the command line; instead, assertion checking was turned on via a method call.
You provide the name of the class for which you want to control assertions as the first method argument (the class was named "Auxiliary"). The second argument value of true controls the assertion state (true or false). The ClassLoader object also provides methods for enabling and disabling assertions at a package level, using the setPackageAssertionStatus() method. Figure 3 shows the output from executing the AssertProgrammatically class. Unlike Figure 1, note that the assertion checking did not occur via the command line (using the—enableassertions option); instead, the setClassAssertion method call in the AssertProgrammatically class turned assertion checking on.

Author's Note: Setting assertion checking for a package or class affects only classes loaded after the enablement change.

Don't Rely On Assertions to Ensure Program Flow
As you've seen, the person running your application can turn assertions off (again, they are turned off by default). Consequently, you don't want to place assertions in your code that must be evaluated for the application to function correctly.

To reiterate, don't place actions (methods, operations, etc.) in your assert statements that will affect subsequent program execution, because there's no guarantee that the assertions will be evaluated. You should typically use assertions only in debugging modes, not in production deployment.

Kulvir Singh Bhogal works as an IBM consultant, devising and implementing J2EE-centric solutions at customer sites across the nation.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date