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 > Java Development Tools >

Tools of the trade, Part 2

Jtest statically and dynamically analyzes your Java code

By Jeff Friesen, JavaWorld.com, 12/06/02

  • Print
  • Feedback

Page 4 of 7

  1. Ensure Lines.java and Lines.class exist in the same directory.

    Caution
    Jtest does not perform static analysis on a classfile if its source file is missing and the Class Testing UI is the current testing UI.
  2. Click the toolbar's New icon, or select the New menu item from the File menu, to start a new test session. New clears existing setup values or settings.
  3. Use the Browse button on the Class Testing UI's Class Name panel to locate and highlight Lines.class.
  4. Right-click the Start icon and select the Static Analysis menu item to start a new static analysis. Jtest prompts you to save class test parameters when either the class test parameters' filename on the status bar is new.ctp or when a class test parameter has changed and you request a new test session. You typically save those parameters to an appropriately named .ctp file to repeat an analysis with the same test parameters at a later time.

    Tip
    You can further refine static analysis testing to a built-in or user-defined category by choosing the appropriate menu item from Static Analysis's associated pop-up menu. (The same applies to the Dynamic Analysis menu item, but you choose between automatic and user-defined dynamic analysis.)


After the current static analysis finishes, the Test Progress panel (when maximized) reveals the number of rules checked in Lines.java. Also, the Errors Found panel's Static Analysis Violations section reveals the number of static analysis violations in Lines.java.

Figure 3 reveals Errors Found panel's contents. That panel's tree structure identifies a variety of violated rules as errors. The number in square brackets to the rule's left identifies the number of times the source file's source code broke that rule. The information in round brackets to the rule's right classifies that rule and identifies its severity level. Number 1 is the highest severity level and indicates that the rule will most likely be violated. A rule with Number 5 as its severity level is least likely to be violated. Jtest defaults to reporting rule violations only where the violated rules have severity levels of 1 or 2.

Figure 3. Jtest's Errors Found panel reveals 18 static analysis violations in Lines.java. Click on thumbnail for full-size image.

Lines.java violates many guidelines—how embarrassing! Fixing that source file requires several changes, ranging from supplying Javadoc comments to placing code in the empty catch clauses. This article's study guide challenges you to clean up Lines.java.

Figure 3's Errors Found panel highlights a violation that involves a literal constant. Literal constants peppered throughout a program's source files result in source code that's difficult to maintain. For example, suppose literal constant 100 refers to an array's size that appears in 49 places throughout 27 source files. Now suppose you want to decrease the array's size to 80. You must replace each occurrence of the array-specific 100 with 80. Failure to replace each occurrence will most likely introduce a defect, especially if your code includes something like for (int i = 0; i < 100; i++). The highlighted line in Figure 3 identifies literal constant 50. To see that literal constant in source code, double-click that line. In Figure 4, Jtest's editor highlights the source code's offending line that contains 50.

  • Print
  • Feedback

Resources