Know about java code coverage plugins : sonar

The default Java code coverage engine for unit tests to be used must be defined in
Settings > Configuration > General Settings > Java > Code coverage plugin property.
By default the Java code coverage engine with come up with sonar is JaCoCo but Cobertura, Emma or Clover can also be used.

JaCoCo

JaCoCo is an open source and robust Java code coverage tool.
For more information, see: Comparison of Emma, Clover, Cobertura and JaCoCo.
Known limitations:

• Some libraries complain on classes, which were instrumented by JaCoCo, so exclusions must be set:
  
  • Javassist (e.g. when Hibernate used) - "*_javassist_*"
  • Drools - "org.drools.*"
• Exact number of line hits not available, because JaCoCo reports only status of line (no code, not covered, partly covered, fully covered) - see JaCoCo Coverage Counters.

Cobertura

The Sonar Cobertura plugin is based on the cobertura-maven-plugin and so can only be used to compute code coverage information on Maven projects.
This plugin has only one parameter to define the maximum amount of memory used by the java process in charge to extract all code coverage information from the Cobertura report:

No relationship between generic parameter and method argument

Hi All,

If you are usinf findbugs to check code quality,
you may see violations like "No relationship between generic parameter and method argument".

Since Map.get() is not fully generic, we often find cases where a developer passed a different type of object (and hence bugs). Frequency of such cases went up when we started using artifacts/services from other teams. What are the reasons why Map.get(Object key) is not (fully) generic explains why get() is not fully generic.

Here's a helper method that provides checked access: public static <K, V> V safeGet(Map<? super K, ? extends V> map, K key) { return map.get(key); }   Sample Usage: Map<List<String>, Date> map = new HashMap<List<String>, Date>(); // this compiles: Date date = safeGet(map, Arrays.asList("")); // this doesn't Date date2 = safeGet(map, "foo");

jacoco code coverage with Ant - Sonar

Here is the detail for how to setup code coverage using jacoco plugin which is OOB come out with SONAR :

1. Write sample java project called ant-jacoco-codecoverage
2.  Project folder structure would be given as below snapshot:
1. 
3. Under the target folder you may have to create classes & reports folders where reports folder will have one more folder called junit
4. Write sample Java class One.java in src folder you can copy paste below code  :
1. public class One {
     String message = "foo";
     public String foo() {
       return message;
     }
     public void uncoveredMethod() {
       System.out.println(foo());
     }
   }

What is LCOM4 ?

Hi Everybody,

If you want to know about the LCOM4(Lack of Cohesion of Methods) which sonar having , please see below example:

Cohesion is the degree to which the methods of a single class are tight together. When two methods in a class do not use a common attribute or a common method, it means that they share nothing and should probably not belong to the same class to respect the Single Responsibility Principle. In other words you can split your class into several new classes to gain modularity at class level.

• LCOM4=1 indicates a cohesive class, which is the "good" class.
• LCOM4>=2 indicates a problem. The class should be split into so many smaller classes.
• LCOM4=0 happens when there are no methods in a class. This is also a "bad" class.

There is not any magic here, only common sense. Let’s take a simple example with class Driver. This class has two fields : Car and Brain, and five methods : drive(), goTo(), stop(), getAngry() and drinkCoffee(). Here is the dependency graph between those components. There are three blocks of related components, so LCOM4 = 3, so the class seems to have three different responsibilities and breaks the Single Responsibility Principle.

Hope this will helpful to you to understand the LCOM4 concept which can be used for any programming language.

Malicious code vulnerability - May expose internal representation by returning reference to mutable object

Hi Everyone,

Normally this kind of violations comes when you are using mutable object in getter settter.

Ideally you should not direct return mutable object, instead you can return clone of that mutable object.

If you see this violation in your code , you can use below code for your mutable object :

If you are using Date :

public class DateTest {
    private Date date;

    public DateTest() {

    }

    public Date getDate() {
        return (Date) date.clone();
    }

    public void setDate(Date date) {
        this.date = (Date) date.clone();
    }      
}


If you are using Array:

public String[] getChkBox() {

return (String[])chkBox.clone();

}