SonarJ Community Edition offers architecture analysis and management for small to medium size Java applications. hello2morrow, the company behind SonarJ software, recently launched the free version of the architecture analysis tool. The community edition can be used to analyze Java applications with upto 500 internal classes (approximately 50 to 60 KLOC).
Architecture management can help with clear and cycle free dependency structures as well as improve testability and reusability of code. Software architects can use SonarJ to define architecture and quality rules, which will then be monitored in the IDE (Eclipse) on the developer's workspace. Tools like SonarJ help the architects to integrate architecture management earlier in the development process.
InfoQ spoke with Alexander von Zitzewitz, CEO of hello2morrow, about the motivation behind releasing the community edition and the future road-map of SonarJ project.
What was the motivation behind the release of community edition of SonarJ?
Our old pricing model was based on the number of users using SonarJ, but independent from the project size. But the benefit of SonarJ is closely related to the size of the project. Although SonarJ was already free for open source and non-commercial use, we have been approached by many developers to offer a low cost personal license. We also saw, that many projects are still using very basic dependency checking tools like JDepend or Macker. With SonarJ we had a solution that was far superior, but only available to larger projects with a tool budget. So we were thinking about a way to make our solution available to a much larger user base without seriously eroding our revenue base.
We decided to add the project size as a second parameter to the pricing model. We also decided to make SonarJ free for projects with up to 500 classes. This limit already supports the majority of projects and equals about 50 to 60 KLOC. We wanted to make sure that the Community Edition of SonarJ could be used on serious projects. So users can reap the benefits and save time and money by avoiding all the bad consequences of structural erosion.
To make the equation complete, projects with up to 3000 classes pay less for a commercial license than before, bigger projects have to pay more. We think that this approach is much more balanced and fits well with the value provided by integrating SonarJ into the development process.
How does SonarJ compare with other tools like Structure 101?
Structure101 is a powerful tool with a good intuitive user interface. Like SonarJ it supports the definition of an architecture model. On the other hand I think that our architecture meta model and the way we visualize the architecture fits better with larger projects. SonarJ supports the concept of a larger project split into subprojects and not only supports horizontal, but also vertical slicing of projects. Although you can achieve a similar thing in Structure101 by creating two or more separate architecture models, this requires more effort and is not really intuitive. For larger projects the vertical cutting (creation of vertical slices) is a very important technique to keep the size of architectural artifacts manageable.
How does SonarJ tool help with design and architecture enforcement compared to other techniques such as using Aspects, Code Inspections or Model Driven Architecture (MDA)?
First of all using SonarJ is completely non-intrusive and can be used on any Java project, new or old. Using aspects is quite intrusive (you have to integrate AspectJ into your build process) and is not really backed by an architecture meta model. Although you can define powerful restrictions there is never a guarantee for completeness. Every architect will probably use a different style of restrictions. Moreover I think that the complexity of defining a serious set of restrictions tends to get out of control quickly. The architecture meta model behind SonarJ makes it easy to make sure, that you have a complete coverage of all the dependencies in your code.Neither the code nor the build process needs to be touched to use SonarJ.
Code Inspections are not a serious alternative to automatic checking of architectural and quality rules. It takes way too much time and there is a great risk of overlooking serious structural problems.
MDA is another strategy to create applications. If most of the code is generated the benefit of analyzing the generated code for architectural flaws is probably quite small. A good code generator will hopefully make sure, that the structure of the generated code is clean. So if you are using MDA successfully and most of your code base is generated you will probably not need SonarJ.
What is the future road map of SonarJ project?
Currently we are working on release 4.1 which is scheduled for March of 2009. The focus of this release is improved usability and some fine tuning of our architecture meta model. Later this year we think about adding plugins for other IDE's like IntelliJ or NetBeans. We also might launch a C# version of SonarJ called SonarShark.