Enterprise grade Java.
You'll read about Conferences, Java User Groups, Java, Integration, Reactive, Microservices and other technologies.

Wednesday, December 16, 2009

Software Quality: JSF Component Libraries - Checkstyle Results

07:40 Wednesday, December 16, 2009 Posted by Markus Eisele
, , ,
This is part V of the software quality analysis series about common jsf component libraries. After a more detailed look at possible bugs (discovered by findbugs) we will take a deeper look at how the projects comply with coding conventions.
The analysis was done with Checkstyle 5.0. Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task.

A note as preface: Checkstyle is highly configurable and can be made to support almost any coding standard. I did NOT look at any project settings. Checkstyle was configured to use the Standard Checks which do cover the Sun coding conventions.


PrimeFaces
With the small codebase, PrimeFaces has the smallest ammount of findings in general. 18762 places in 334 files. Only 61 of them are considered as an error. This makes 0,18 problems per file.
The 61 errors occure within two categories (EmptyBlockCheck, IllegalCatchCheck). Looking randomly at the details for does not reveal any real issue.

The classes with the highest number of findings can be found among the generated files (jsf-plugin). The handcrafted ones are:
- org.primefaces.component.datatable.DataTableRenderer.java (265)
- org.primefaces.component.calendar.CalendarRenderer.java (217)
- org.primefaces.component.chart.UIChart.java (181)


RichFaces
The next biggest codebase is provided by the RichFaces. 713 files with 38.587 findings. 552 of them considered as an error. An average of 0,77 problems per file. This is the worst result of the three. The errors separate into three categories (EmptyBlockCheck, IllegalCatchCheck, IllegalThrowsCheck). Some spot tests on the results did not reveal any bigger problems, which is not surprising at all because findbugs would already have shown them.

The classes with the highest number of findings are located in the ajax4jsf package.
- org.ajax4jsf.org.w3c.tidy.TidyUtils.java (632)
- org.ajax4jsf.renderkit.RendererUtils.java (593)
- org.ajax4jsf.xml.serializer.ToStream.java (574)

The hotspots from the RichFaces package:
- java.org.richfaces.model.StackingTreeModel.java (207)
- org.richfaces.json.JSONObject.java (189)
- org.richfaces.json.JSContentHandler.java (159)


ICEFaces
The biggest codebase is provided by ICEFaces. 877 files with a surprising low number of findings. "only" 22.959 with a total of 287 errors. That makes an average of 0,3 problems per file.
The errors separate into the already known three categories (EmptyBlockCheck, IllegalCatchCheck, IllegalThrowsCheck).

The hotspots from the ICEFaces package:
- com\icesoft\faces\component\inputfile\InputFile.java (387)
- com\icesoft\faces\component\selectinputdate\SelectInputDateRenderer.java (378)
- com\icesoft\faces\component\paneltabset\PanelTabSet.java (357)

Conclusion:
With an average of 0,18 problems per file, this round goes to PrimeFaces. Even if the total number of warnings is quite high. Followed by ICEFaces and RichFaces. Even if the last one is the only project having codechecks in place. Somehow surprising results. The hot spots can be found within the components. This is true for every library except for RichFaces. What is also true is, that the most complex components are more likely the ones with the biggest problems.