Running packaged queries

Now, let's run a query to give us an overview of the packages that make up JHotDraw, and a bit of information about how the code has been split up into modules.

Libraries of SemmleCode queries can be stored in XML files. SemmleCode is shipped with a default.xml file, which contains a large set of pre-defined queries of various kinds: to compute metrics, to find-bugs or to enforce some J2EE style-checks. You can find this file under the following path:
Eclipse Setup Folder\plugins\com.semmle.resources_x\config\default.xml.

Click the Open bundle of queries button — an open folder icon in the Quick query window as shown below and select the default.xml file.

An HTML-like editor will appear with a tree of the existing categories of SemmleCode queries. Using this editor you can manipulate the existing queries and package them up into your custom bundles.

Metric Queries

Query Bundle tab should be the one selected by default. Expand the categories by clicking on the small icon next to them. Find the Metrics category, which is followed by the Packages then Averages, and select the Average Method/Constructor Fan-In query.

Click the Open Query button to copy the query to the Quick query window. Once the query is copied, it can be executed by clicking the Query as chart button (indicated by the icon () in the Quick query window). The following message will appear:

After a moment this message will disappear and a new tab will appear next to the Quick query window, entitled Average Method/Constructor Fan-In (jhotdraw). Double-click on the tab to make it fill the Eclipse window so that the chart is clearly visible.

The names of all the packages that make up JHotDraw are shown in the legend of the chart. Each bar on the chart shows the average fan-in for the methods and constructors in that package. The fan-in of a method is the number of distinct methods or constructors that call it. A high fan-in for all packages can sometimes indicate that the program was poorly split up into modules, because the internal methods of separate modules often call each other.

Queries to Find Bugs

This time we shall have a look at another possible way of running pre-packaged SemmleCode queries. To start, click on the Run menu and select Run....

The Eclipse window for creating, managing, and running configurations will then appear. Seasoned Eclipse users will notice that there is a new kind of configuration available in the list on the left, called SemmleCode Queries. Double-click on this now to open a new configuration and call it Find Bugs Queries.

The queries that we will be running are again in the default library, so click Add default file(s). The queries in the default library can then be browsed by selecting the Queries tab.

Queries to help find bugs are provided with SemmleCode. Go to the Queries tab and select the Semmle->Standard library->Cloning->Missing super Clone query.

The advantage of running the queries this way is that it is possbile to combine several queries based on some criterion into a launch configuration. Executing such group of queries is then only a matter of one click. A user can, for instance, develop a set of style-check queries and execute them every time before doing a commit to the repository.

The following message will appear in the bottom-right corner of the Eclipse window.

This time, rather than a chart opening, a warning appears in the problem view of Eclipse:

The warning says that a clone() method in JHotDraw may return an object of the wrong type. Double-click on the message to open the method that the warning is referring to.

In isolation the method seems correct. It is a common Java idiom to call super.clone() — the implementation of clone in java.lang.Object always returns an object that has the same dynamic type as the object on which clone() was called.

However, the warning from the SemmleCode query tells us to check the implementation of clone that is inherited by this class. To do so click on the clone part of the call to super.clone() and press F3.

Now we can see that, indeed, there is an incorrect implementation of clone in the super-class of the class first looked at, which calls a specific constructor instead of calling super.clone(). Note that this particular error was deliberately introduced so that it could be found by SemmleCode. However, the same mistake is made in production Java systems, and the problem is unlikely to be spotted by local inspection of individual classes.