Checkstyle is a tool for assessing compliance of Java code with a specific coding standard. Checkstyle originally focused on code layout issues, but has been expanded with checks to assess design standards, duplicate code, and bug patterns.
To install Checkstyle for use in StackyHack, download the .zip file containing the latest release from the Checkstyle home page into a directory such as "java-lib", and unzip it. Then, define an environment variable called CHECKSTYLE_HOME to point to the distribution directory. For example, "c:\java-lib\checkstyle-4.2". (Note that the file path should have no embedded spaces in it.)
![]() | Note |
|---|---|
The Checkstyle release used in the following examples is 4.2. If you have downloaded a later release, such as 4.3, you will need to add "-Dcheckstyle.version=4.3" to the command line invocation of Ant to override the default version value in the checkstyle.build.xml file. | |
Example 4.22, “checkstyle.build.xml” shows the checkstyle.build.xml file, which defines the Ant targets used to invoke the Checkstyle tool and the Checkstyle sensor.
Example 4.22. checkstyle.build.xml
<project name="stackyhack.checkstyle" default="checkstyle">
<description>
Provides the Checkstyle tool and the Hackystat Checkstyle sensor.
Note: If you download a different version (say, 4.3), then you can override the default version (4.2) as follows:
ant -Dcheckstyle.version=4.3 -f checkstyle.build.xml checkstyle.tool
Note: The error message "Unable to create a Checker" indicates you have an old version of Checkstyle in ant/lib.
</description>
<import file="build.xml"/>
<property environment="env"/>
<property name="checkstyle.dir" location="${build.dir}/checkstyle" />
<property name="checkstyle.version" value="4.2"/>
<property name="checkstyle.jar" value="checkstyle-all-${checkstyle.version}.jar"/>
<target name="checkstyle" depends="checkstyle.tool, checkstyle.sensor" description="Runs Checkstyle, followed by the Checkstyle sensor."/>
<target name="checkstyle.tool" description="Checks the style of the sources and reports issues.">
<!-- Check for the CHECKSTYLE_HOME environment variable, failing the build if it can't be found. -->
<available file="${env.CHECKSTYLE_HOME}/${checkstyle.jar}" property="checkstyle.available"/>
<fail unless="checkstyle.available" message="Error: CHECKSTYLE_HOME not set or ${env.CHECKSTYLE_HOME}/${checkstyle.jar} not found."/>
<taskdef resource="checkstyletask.properties" classpath="${env.CHECKSTYLE_HOME}/${checkstyle.jar}" />
<mkdir dir="${checkstyle.dir}"/>
<checkstyle config="${env.CHECKSTYLE_HOME}/sun_checks.xml"
failOnViolation="false">
<fileset dir="${src.dir}" includes="**/*.java" />
<formatter type="plain"/>
<formatter type="xml" tofile="${checkstyle.dir}/checkstyle.xml"/>
</checkstyle>
</target>
<target name="checkstyle.sensor" description="Sends CodeIssue data to Hackystat using the Checkstyle Sensor.">
<!-- Define the checkstyle sensor taskdef, failing the build if the sensor is not installed. -->
<available classname="org.hackystat.sensor.checkstyle.CheckstyleSensor" property="checkstyle.sensor.available"/>
<fail unless="checkstyle.sensor.available" message="Error: Checkstyle sensor not installed."/>
<taskdef name="hacky-checkstyle" classname="org.hackystat.sensor.checkstyle.CheckstyleSensor"/>
<hacky-checkstyle verbose="${hackystat.verbose.mode}" >
<fileset file="${checkstyle.dir}/checkstyle.xml/">
</hacky-checkstyle>
</target>
</project>
The checkstyle.build.xml defines the <checkstyle.tool> target to parse the source code and generate a report on the coding violations encountered. For this example, we use the Sun guidelines (sun_checks.xml) provided in the Checkstyle distribution, though most projects will want to define their own coding format. The <checkstyle.sensor> target uses the Hackystat Checkstyle sensor to read in the XML files generated by Checkstyle and send the output to Hackystat. The <checkstyle> target simply invokes both of these targets in sequence.
Example 4.23, “checkstyle.tool invocation” shows the output from invoking the <checkstyle.tool> target, with some repeated error messages removed to conserve space.
Example 4.23. checkstyle.tool invocation
C:\svn-csdl\StackyHack>ant -f checkstyle.build.xml checkstyle.tool
Buildfile: checkstyle.build.xml
checkstyle.tool:
[mkdir] Created dir: C:\svn-csdl\StackyHack\build\checkstyle
[checkstyle] Running Checkstyle 4.2 on 5 files
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\ClearStack.java:0: File does not end with a newline.
:
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\ClearStack.java:0: Got an exception - java.lang.RuntimeException: Unable to get class information for EmptyStackException.
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\ClearStack.java:9: Line is longer than 80 characters.
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\ClearStack.java:11: Line has trailing spaces.
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\ClearStack.java:23:3: Method 'getIterator' is not designed for extension - needs to be abstract, final or empty.
:
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\EmptyStackException.java:15:30: Parameter e should be final.
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\Stack.java:0: Got an exception - java.lang.RuntimeException: Unable to get class information for EmptyStackException.
:
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\Stack.java:22:23: Variable 'elements' must be private and have accessor methods.
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\Stack.java:30:3: Method 'push' is not designed for extension - needs to be abstract, final or empty.
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\Stack.java:30:20: Parameter obj should be final.
:
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\TestClearStack.java:18:3: Missing a Javadoc comment.
:
[checkstyle] C:\svn-csdl\StackyHack\src\edu\hawaii\stack\TestClearStack.java:20:39: '3' is a magic number.
BUILD FAILED
C:\svn-csdl\StackyHack\checkstyle.build.xml:25: Got 43 errors and 0 warnings.
Total time: 3 seconds
C:\svn-csdl\StackyHack>
![]() | Note |
|---|---|
If your invocation of Checkstyle fails with the message "Unable to create Checker", it is most likely because you have an old version of the Checkstyle .jar file in your ant/lib directory. The best solution is to remove that file from ant/lib. | |
After Checkstyle has been invoked to generate data regarding source code violations, the Checkstyle sensor can be invoked to read in the resulting XML files produced by Checkstyle and send the resulting data to Hackystat as Code Issue sensor data.
To accomplish this, you must first install the Checkstyle sensor, which can process the XML files output by Checkstyle. General instructions on installing sensors are provided in Chapter 2, Client-side configuration: Tool sensor installation; instructions for specific sensors are provided in Chapter 26, Sensors. After installation, your hackyInstaller Checkstyle configuration window should look something like the screen image in Figure 4.14, “ HackyInstaller configuration screen for Checkstyle sensor ”.
Example 4.24, “checkstyle.sensor invocation” illustrates the invocation of the Checkstyle sensor.
Example 4.24. checkstyle.sensor invocation
C:\svn-csdl\StackyHack>ant -f checkstyle.build.xml checkstyle.sensor Buildfile: checkstyle.build.xml checkstyle.sensor: [hacky-checkstyle] Sensor enabled?: true [hacky-checkstyle] Processing file: C:\svn-csdl\StackyHack\build\checkstyle\checkstyle.xml [hacky-checkstyle] Hackystat data on 43 Code Issues sent to http://hackystat.ics.hawaii.edu/ (1 secs.) BUILD SUCCESSFUL Total time: 2 seconds
Once you've invoked the sensor, you can verify that this data was received at the server by using the List Sensor Data command. Figure 4.15, “ List Sensor Data with StackyHack Checkstyle data ” illustrates what this page might look like after receiving the StackyHack data.
A separate CodeIssue sensor data entry is sent for each of the violations detected by Checkstyle, along with supplemental information about the file it was found in and so forth.