Only Software matters

Experiences in software development

Posts Tagged ‘quality’

Fixing common Java security code violations in Sonar

Posted by Patroklos Papapetrou on September 21, 2012

This article aims to show you how to quickly fix the most common java security code violations. It assumes that you are familiar with the concept of code rules and violations and how Sonar reports on them. However, if you haven’t heard these terms before then you might take a look at Sonar Conceptsor the forthcoming book about Sonarfor a more detailed explanation.

To get an idea, during Sonar analysis, your project is scanned by many tools to ensure that the source code conforms with the rules you’ve created in your quality profile. Whenever a rule is violated… well a violation is raised. With Sonar you can track these violations with violations drilldown view or in the source code editor. There are hundreds of rules, categorized based on their importance. Ill try, in future posts, to cover as many as I can but for now let’s take a look at some common security rules / violations. There are two pairs of rules (all of them are ranked as critical in Sonar ) we are going to examine right now.

1. Array is Stored Directly ( PMD ) and Method returns internal array (PMD)

These violations appear in the cases when an internal Array is stored or returned directly from a method. The following example illustrates a simple class that violates these rules.

public class CalendarYear {
 private String[] months;
 public String[] getMonths() {
    return months;    
 public void setMonths(String[] months) {
    this.months = months;

To eliminate them you have to clone the Array before storing / returning it as shown in the following class implementation, so noone can modify or get the original data of your class but only a copy of them.

public class CalendarYear {
 private String[] months;
 public String[] getMonths() {
    return months.clone();    
 public void setMonths(String[] months) {
    this.months = months.clone();

2.Nonconstant string passed to execute method on an SQL statement (findbugs) andA prepared statement is generated from a nonconstant String (findbugs)

Both rules are related to database access when using JDBC libraries. Generally there are two ways to execute an SQL Commants via JDBC connection : Statement and PreparedStatement. There is a lot of discussion about pros and cons but it’s out of the scope of this post. Let’s see how the first violation is raised based on the following source code snippet.

Statement stmt = conn.createStatement();
String sqlCommand = "Select * FROM customers WHERE name = '" + custName + "'";

You’ve already noticed that thesqlcommand parameter passed to execute method is dynamically created during run-time which is not acceptable by this rule. Similar situations causes the second violation.

String sqlCommand = "insert into customers (id, name) values (?, ?)";
Statement stmt = conn.prepareStatement(sqlCommand);

You can overcome this problems with three different ways. You can either useStringBuilder or String.formatmethod to create the values of the string variables. If applicable you can define the SQL Commands as Constant in class declaration, but it’s only for the case where the SQL command is not required to be changed in runtime. Let’s re-write the first code snippet using StringBuilder

Statement stmt = conn.createStatement();
stmt.execute(new StringBuilder("Select FROM customers WHERE name = '").

and using String.format

Statement stmt = conn.createStatement();
String sqlCommand = String.format("Select * from customers where name = '%s'", custName);

For the second example you can just declare the sqlCommand as following

private static final SQLCOMMAND =insert into customers (id, name) values (?, ?)";

There are more security rules such as the blockerHardcoded constant database password but I assume that nobody is still hardcodes passwords in source code files…

In following articles I’m going to show you how to adhere to performance and bad practice rules. Until then I’m waiting for your comments or suggestions.

Posted in java, quality, software, sonar | Tagged: , , , | 10 Comments »

Sonar’s Quality Alphabet

Posted by Patroklos Papapetrou on August 31, 2012

Sonar (by is getting more and more popular among developer teams. It’s an open source platform measuring software quality in the following 7 axes

  1. Architecture and Design
  3. Coding Rules
  4. Complexity
  5. Code Duplication
  6. Potential Bugs
  7. Unit Tests

If you’re a Sonar newbie then you might find this blog post very useful. On the other hand if you’re an experienced user then you can refresh your memory and what you’ve learned so far. Sonar’s Alphabet is not a user manual. It’s a reference to help you learn (and teach others) some basic terms and words used in the world of Sonar.

  • A for Analysis: Sonar’s basic feature is the ability to analyse source with various ways (Maven, Ant, Sonar runner, trigger by CI system ) . You can have static and/or dynamic analysis if supported by the analyzed language.
  • B for Blockers :These are violations of the highest severity. They are considered real (not potential bugs ) so fix them as soon as possible
  • C for Continuous Inspection :Continuous Inspection requires a tool to automate data collection, to report on measures and to highlight hot spots and defects and yes,Sonaris currently the leading all-in-one Continuous Inspection engine.
  • D for Differential Views : Sonar’s star feature let you compare a snapshot analysis with a previous analysis. Fully customizable and dynamic makes continuous inspection a piece of cake.
  • E for Eclipse. If you’re an Eclipse fan then did you know that you can have most of Sonar’s features in your IDE without leaving it. If not then you should give a try the Sonar’s Eclipse plugin.
  • F for Filters :Filters are used to specify conditions and criteria on which projects are displayed. They can be used in dashboards or in widgets that require a filter.
  • G for Global Dashboards :Global dashboards are available at instance level and can be accessed through the menu on the left. One of those global dashboards is set as your home page.Any widget can be added to a global dashboard. Thus, any kinds of information from a project or from the Sonar instance can be displayed at will.
  • H for Historical Information :Knowing the quality level of your source code in a specific time instance is not enough. You need to be able to compare it with previous analysis. Sonar keeps historical information that can be viewed with many ways such as Timeline widget, Historical table widget or metric tendencies.
  • I for Internationalization : Sonar (and some of the open source plugins) supports internationalization. It’s available in 7 languages.
  • J for Jenkins :Although jenkins is not a term of Sonar, you’ll read it in many posts and articles. A best practice to run Sonar analysis and to achieve Continuous Inspection is to automate it by using a CI server. Sonar folks have created a very simple, still useful plugin, that integrates Sonar with Jenkins
  • K for Key :If you want to dive in Sonar’s technical details or write your own plugin then don’t forget that most of core concepts are identified by a key ( project key, metric key, coding rule key etc. )
  • L for Languages : Sonar was initially designed to analyze Java source code. Today, more than 20 languages are supported by free or commercial plugins.
  • M for Manual Measures : You can even define your own measures and set their values when automated calculation is not feasible ( such as team size, project budget etc. )
  • N for Notifications :Let Sonar sends you an email when
    • Changes in review assigned to you or created by you
    • New violations on your favorite projects introduced during the first differential view period.
  • O for Opensource : Sonar core as well as most of the plugins are available in CodeHaus or GitHub.
  • P for plugins. More than 50 Sonar plugins are available for a variety of topics. New languages, reporting, integration with other systems and many more. The best way to Install / update them through the Update Center.
  • Q for Quality Profiles. Sonar comes with default Quality profiles. For each language you can create your own profiles or edit the existing ones to adjust sonar analysis according to your demands. For each quality profile you activate/deactivate rules from the most popular tools such as PMD, FindBugs, Checkstyle and of course rules directly created by Sonar guys.
  • R for Reviews : CodeReviews made easy with Sonar. You can assign reviews directly to Sonar users and associate them with a violation. Create action plans to group them and track their progress from analysis to analysis.
  • S for Sonar in Action book. The only Sonar book that covers all aspects of Sonar. For beginners to advanced users even for developers that want to write their own plugins.
  • T for Testing :Sonar provides many test metrics such as line coverage, branch coverage and code coverage. It’s integrated with most popular coverage tools (jacoco, emma, cobertura, clover). It can show also metrics on integration tests and by installing opensource plugins you can integrate it with other test frameworks ( JMeter, Thucycides, GreenPepper etc.)
  • U for User mailing list. Being an active member of this list I can assure you that you can get answers for all your issues and problems.
  • V for Violations : A very popular term in Sonar. When a source code file (tests files apply also) doesn’t comply with a coding rule then Sonar creates a violation about it.
  • W for Widgets : Everything you see in a dashboard is a widget. Some of them are only available only for global dashboards. You can add as many as you want in a dashboard and customize them to fit your needs. There are many Sonar core widgets and usually plugins may offer some additional widgets.
  • X for X-ray : You can consider Sonar as your x-rays glasses to actually see IN your code. Nothing is hidden anymore and everything is measured.
  • Y for Yesterday’s comparison : One of the most common differential views usages is to compare the current analysis snapshot with the analysis triggered yesterday. Very useful if you don’t want to add up your technical debt and handle it only at the end of each development cycle.
  • Z for Zero values :For many Sonar metrics such as code duplications, critical/blocker violations, package cycles your purpose should be to minimize or nullify them that means seeing a lot of Zero values in your dashboard.

When I was trying to create this alphabet in some cases/letters I was really in big dilemma which word/term to cover. For instance the Sonar runner, which is not mentioned above, is the proposed and standard way to analyze any project with Sonar regardless the programming language.

If you think that an important Sonar term is missing feel free to comment and I’ll adjust the text.

Posted in software | Tagged: , , | 4 Comments »

5+1 Sonar Plugins you must not miss

Posted by Patroklos Papapetrou on July 10, 2011

Sonar, to my humble opinion, is the leading system to help developer teams track,manage and eventually enhance the overall quality of their code and obviously their software products/projects. To be honest, this is not a post to describe either Sonar features or the necessity of a tool for every developer that respect his time and efforts. If you want to read such analysis you can see my related post To Sonar or Not to Sonar. In this article I briefly present 5+1 plugins that every Sonar Installation should have them. I would like to clarify though some exceptions I have made prior to my final choice. I have excluded all plugins that have to do with additional languages and IDE to keep this post as much as objective I can. I have also excluded all commercial plugins for obvious reasons. After that assumptions I have limited my selections to the following categories :
  • Additional Metrics
  • Governance
  • Integration
  • Visualization / Reporting
Sonar itself comes with a variety of features that cover most of the needs of a software development team. However I consider that the following plugins are essential, especially for those that have adapted or trying to adapt agile practices. To be honest it was very difficult to select only 6 plugins!!
1.Hudson / Jenkins plugin
Although Sonar analysis can be easily triggered from several build tools (maven, ant etc.) I strongly believe that its native integration with the most famous open source CI server makes itself an important part of the continuous integration / deployment practice. The configuration is extremely easy and as proposed the best practice is to trigger Sonar at night builds. Team members can track day by day software quality, automatically, without bothering when a new analysis should run.
2.Jacoco Plugin
Unit Test results, with drill down analysis, line and branch coverage, running and failed tests are features implemented in Sonar core and cover in depth all aspects of unit testing practice. But, as there is always a ‘but’, what about Integration tests? What if we want to have separated measures about unit and integration tests? Here comes JaCoCo plugin to save our time and money. Although JaCoCo is an alternative to Cobertura (default Sonar coverage tool ), it may be properly configured to display metrics only for Integration Tests. There is a great article that explains in details how we can use it and get the same analysis ( as for Unit Tests ) for Integration Tests.
3.Useless Code Plugin
It may looks similar to the Sonar Core feature named Duplicate Code, but it adds some more metrics, which I think are very useful especially for large or legacy systems. In general it measures how many lines can be removed from your code. It reports what is the number of unused private methods that can be safely removed and the number of unused protected methods exist in the code that can be removed after some more careful code examination. Finally it provides some more details about code duplication informing how duplicate lines are formed (i.e. x blocks of y lines )
4.SIG Maintainability Model Plugin

This plugin, as its name implies is an implementation of the Software Improvement Group(SIG) Maintainability Model. It reports ranking – from — :(very bad) to ++ (very good) on the following base indicators:Analysability, Changeability, Stability and Testability. The core idea for this ranking is to measure a series of base metrics such as Lines of Code(LOC), Duplications,Unit Tests,Complexity and Unit Size. Each of these metrics is then accounted into some of the mentioned indicators and the final result is representing the overall maintainability of the project. We can see the results of this analysis in a graphical (spider) presentation with all four axes of the model. With a glance a this graph you have a global and detailed at the same time view of how easy is to change and maintain your codebase. For me it is the first index I check every morning and if something is not + or ++ then we definitely have done something wrong

5.Quality Index Plugin
Have you ever wanted to check a single number (indicator) and understand how healthy is your project? I am sure you have!! Well, the quality Index plugin is exactly what you are looking for. The plugin combines four weighted axes (complexity, coding violations, style violations, test coverage) of quality and produces a ranking between 0 (lowest) and 10(highest). Moreover it calculates a method complexity factor based on the complexity factor mentioned above. Have you ever tried to get a ranking of 10 with this plugin? I think it worths the effort!

6.Technical Debt Plugin
Last, but not least, the plugin that reports about the interest you have to pay as a developer, as a team, as a company. Technical debt is a term invented by Ward Cunningham to remind us that if we don’t pay our interest from time to time, then it is for sure that eventually this will make our software unmaintainable and hard to add new features or even find the root cause of defect. The plugin, which has a very powerful configuration, represents technical debt in four dimensions.

  • Debt Ratio : The percentage of current technical debt to the maximum possible technical debt.
  • Cost to reimburse : Cost in your currency to pay all interest and clean up your code
  • Work to reimburse : Same as above measured in man days.
  • Breakdown : Distribution to the following axes: Duplication, Violations, Complexity, Coverage, Documentation and Design

Be sure that you check its measures to avoid find yourself in bad situation like spaghetti code

I am pretty sure that there are plenty of interesting Sonar plugins so please feel free to post your comments with your list of them.

Posted in open source, quality, software, sonar | Tagged: , , , | 4 Comments »

%d bloggers like this: