Main overview screen
Overview of one project
Drilldown into a severity area
Drilldown into source code
From an overview page a developer can drill down to the class to the actual source code where an issue is identified. As Sonar is a central server with permission control, a hierarchy and roles can be established like project owner, senior developer, developer, clients. Everybody can access the project and see or give feedback of the status and identified issues. Sonar can be used to established code guidelines in a project / company, help the developers to produce better and standardized code and used to show to the customer the quality of the code.
The analysis of the code can be done by looking at the plain source code and use rules to identify violations of pre-defined best practices or by a more advanced analysis of the binary code. For the later findbugs is used. This gives more control over possible bugs that normally only will be discovered during runtime. As runtime means that the project has to be deployed, started and executed, any bug found by findbugs helps saving time. To make findbugs work, Sonar has to know where to find all the classes referenced in the byte code. If the class files are not available, the analysis won’t be executed.
Run the analysis by using the source code on a PAR file for SAP Portal.
Looks good, as no blocker or critical error is found. That code shouldn`t crash when executed with an exception.
Analyzing the same code with a different profile: findbugs.
Compared to the source code analysis, findbugs now shows 2 blockers and 2 critical bugs. Unlikely that the program won`t crash when executed.
To show what findbugs do I prepared a rather simple example. The code simply will do a cast that cannot work:
Findbugs is able to find this out and correctly report an impossible cast. It even shows what I try to do: cast from Integer to String. Depending where this kind of cast is hidden in the source code, maybe only a really profound testing would have shown the error, maybe only in production. To see how findbugs works with Web Dynpro Java I wrote a really simple WDJ application. Web Dynpro Java program analyzed, only the source code:
The issues found are more or less caused by the code generator of WDJ.
Most of these issues can be resolved my naming variables, methods, etc differently and by SAP looking at the code generator. Now with findbugs
The dead store issue may or not be an error of the developer (or javac). Because I prepared the code, I know that the error stems from a coding error. In the view a value node with cardinality 0..n was created. Without initialization of the node this throws a NullPointerException during runtime. Changing the cardinality to 1..n and running Sonar again:
In that case, Sonar helped to identify an error that only can be discovered after deploying the WDJ application. As that kind of error immediately occurs when the user is accessing the view and thus ending the test case, Sonar helps to resolve these kinds of errors faster.
Sonar is for Java, but SAP interpreted Java sometimes in an interesting way; think of Web Dynpro Java. As shown, Sonar can be used to analyze all kinds of SAP Java projects. WDJ produces in the end . java and .class files, portal applications are Java projects and so is the rest of Java projects (like PI). Currently SAP is endorsing NWDI for Java development and while ABAP comes with a code inspector (you are using, right?), there is no such solution from SAP for Java. If you want to get started with code quality management in Java for SAP, there are several solutions for Java available. To get started you can try Sonar.
What is needed are accelerators, guidelines and plugins from SAP for their specific Java project types. That would really make a difference for developers.