A few weeks ago Michael Marth, who runs dev.day.com (Day’s developer portal), asked us if we could put together our impressions on the code quality of Apache Sling using Sonar. We thought it would be valuable to share the result of this exercise with the community.

Apache Sling in a few words

“Apache Sling is an innovative web framework that is intended to bring back the fun to web development. It uses all those nice cool and new technologies that make up a state-of-the-art framework. This is Apache Sling in five bullets:

• REST based web framework

• Content-driven, using a JCR content repository

• Powered by OSGi

• Scripting inside, multiple languages

• Apache Open Source project

Some size indications of the project

• 40 Maven modules

• 70,707 lines of code

• 731 Java classes

• and 23,043 lines of Javadoc

The strengths in terms of quality

• A project that you get and compile with no difficulty by running two commands:
  1. svn checkout https://svn.apache.org/repos/asf/sling/trunk/
  2. mvn clean install
  This sounds like an evidence but is not always the case :-)

• Amongst 130,172 physical lines, only 0.9% are involved in a duplication

• 46.4% of public API are commented with a Javadoc block

The weaknesses

• Only 9% of the source code is covered by 338 unit tests

• Average cyclomatic complexity by method (excluding getters and setters) is greater than 3 (3.2).
  That is kind of a warning saying “your methods are taking too much responsibilities and should be re-factored”. This warning is confirmed by others metrics : 394 methods have a complexity greater than 7 and 86 methods have more than 50 statements. What is true at method level gets also partially confirmed at class level as 60 classes have a Fan Out Complexity greater than 20 (The number of other classes referenced by a class)

Bad programming practices that should be improved

• 198 times, method parameters are reassigned in the core of the method

• 68 times, local variables are defined and hide class fields

• 28 times, NullPointerException are thrown when an IllegalParameterException would be more suitable

Potential bugs that should be quickly analyzed

• Correctness - An apparent infinite recursive loop : there is an apparent infinite recursive loop in org.apache.sling.scripting.jsp.jasper.runtime. JspContextWrapper.include(String, boolean)

• Multithreaded correctness - Unsynchronized get method, synchronized set method : org.apache.sling.scripting.jsp.jasper.compiler. JspRuntimeContext.getJspReloadCount() is unsynchronized, org.apache.sling.scripting.jsp.jasper.compiler. JspRuntimeContext.setJspReloadCount(int) is synchronized

• Multithreaded correctness - Method calls Thread.sleep() with a lock held : org.apache.sling.event.impl. JobEventHandler.runJobQueue(String, JobBlockingQueue) calls Thread.sleep() with a lock held

• Malicious code vulnerability - Field is a mutable array : org.apache.sling.jcr.webdav.impl.servlets. SlingWebDavServlet.COLLECTION_TYPES_DEFAULT is a mutable array

This analysis was done with the intention of giving a synthetic overview of the current state of the project. Where should you start from if tomorrow you wake up with a single idea in mind : “Improving quality of the Apache Sling project !” ?

• With respectively a cyclomatic complexity of 428, 385 and 343, classes Generator, Parser and XMLEndoginDetector should be first refactored. With no surprise, the Generator.java file has the greatest number of duplicated lines (154) and rules violations (109)

• With its 43 cyclomatic complexity and no unit tests, the method ModifyAceServlet.handleOperation(..) is what we call “a crappy method” :-)

More information on the code quality of the project is available on Nemo.

Via Seth Gottlieb I have found this really good presentation on content modelling for content management systems by Deane Barker:

Cleve Gibbon's recent well-written series on content modelling is closely related to Deane's presentation. Make sure to have a look if you are interested in that area.

I really like Deane's presentation, at least when I look at it from the paradigm that proper content management needs a-priori content modelling. Lately, I have come to question this idea, but that shall be the topic of a different post.

The introduction of the simplified clustering in CRX 1.4.1 (back in January 2009) kick-started the efforts to make CRX and CQ5 easily deployable into the Amazon cloud computing infrastructure.

A lot happend since then - most importantly - we got in touch with customers that have exactly the challenges we were looking to solve with cloud-based deployments. One of them being the ability to scale infrastructure for peak usage, without the cost of running all servers all the time. Of course, to set a good example, we run our own sites - such as www.day.com - on EC2.

Next week, we would like to give you an update of what we did so far and share the plans for the future.

On July 7th (Tuesday) we have a half day seminar in London. Sarah Burnett from Butler Group and myself will discuss the advantages and use cases to make best use of cloud computing infrastructure. This is a great event to get yourself familiar with the cloud computing topic and learn how you can apply that to your content management initiatives. Join the free seminar in London. Sign-up here.

On July 9th (Thursday) I'm going to broadcast my speech and discussions from London via a Webinar using WebEx. Feel free to sign-up to get the details to join the Webinar.

Personally, I believe the most exciting part of the cloud computing era are the new ways to solve challenges accepting the fact that almost unlimited computing resources are at your disposal (at a fairly decent price).

In case you missed the Day talks at Jazoon conference please find the slides below:

Thomas Mueller: Testing Zen

Thomas Mueller: Java Persistence Frameworks

Michael Marth and Michael Dürig: Scalable Agile Web Development: REST meets JCR meets OSGI

Michael Dürig and Michael Marth: Building RESTful Web Applications with Scala for Sling

Starting today the conference OSGi DevCon Europe 2009 takes place in Zurich (in association with the Jazoon conference). Two talks will be given by Day's OSGi experts:

Felix Meschberger: Declarative Services: Dependency Injection OSGi style

2009-06-22, 11:20

Applications in general and OSGi applications in particular consist of a host of different modules and services which need to be bound together to form the actual application. In a traditional application services are generally bound by calling factories or instantiating the service classes or accessing a registry of services. In recent years a new buzz-word entered the arena: Dependency Injection. With dependency injection services are provided to the service clients as they become available. Likewise configuration is injected into the services, that is services do manage their configuration themselves. The OSGi specification for dependency injection is the Declarative Services specification: The components are declared and indicate what services they use and require and may in addition be provided with configuration. This talk shows the benefit of using Declarative Services and how the Apache Felix Maven SCR Plugin simplifies the service declaration even more.

Update: find Felix' slides below

Betrand Delacretaz: Tales from the OSGi trenches

2009-06-22, 14:60

In this talk we share our experience of using OSGi for a major rewrite of Day's family of content management products. After more than two years working with OSGi, the impact on our products, developers, customers and service people is very high, in a positive way. OSGi is no silver bullet either. The extreme modularization and dynamic service deployment features of OSGi make our products much more robust and maintainable, but the costs associated with changing people's way of thinking about code and modules, and with testing and debugging highly dynamic systems, must not be underestimated. Based on real-life code samples, we will show how OSGi is used at several levels in our products, from low-level interactions with the framework to very simple creation of (compiled or scripted) services. We will also present some of the automated testing techniques used in our project. Sharing our experience will help you decide if OSGi is for you, and more importantly at which level you should use it.

• Twitter Updates

• Recent Discussions

• PlanetDay

  The latest posts on PlanetDay

• Links on Daigg

• Day developers on Ohloh