Quality assurance at Mysema

We at Mysema follow high quality standards in our projects. This manifests itself both in our development process and the tools we use to develop and build our projects. We follow agile processes in our projects and Scrum is our process model of choice for most of our projects.

One of the main focuses of the Scrum process in continuous feedback. In our daily development practice this applies to our usage of Continuous integration, which provides immediate feedback on failing builds.

Our build toolset consists of the following applications

  • Hudson for Continuous integration
  • Sonar for Code quality metrics

Hudson polls our code versioning system for changes to the source code of our projects, and when changes are detected, the projects are built on the Hudson server. For failing builds notifications are sent to the committers for immediate reaction.

Sonar is used for nightly builds to provide detailed analysis results on test coverage, source code style and bugs inspected from the compiled bytecode. Sonar internally uses CheckStyle, FindBugs, PMD and Cobertura and provides the analysis results in a very readable way.

We have configured the following alerts in Sonar

  • Blocker violations : Error threshold 0
  • Coverage : Warning threshold 50%, Error threshold 25%
  • Critical violations : Error threshold 0
  • Package tangle index : Warning threshold 5%, Error threshold 10%
  • Rules compliance : Warning threshold 95%, Error threshold 90%

As can be seen from the configuration, we focus on consistent design (Package tangle index), no critical errors (Blocker and Critical violations) and general Rules compliance.

Test coverage is also important, but as we have lots of highly modular builds, the tests for a particular artifact are not always located in the source tree of the artifact itself, so the results of the Cobertura test coverage do not fully reflect the total test coverage.

Here are some examples from the Sonar pages of Querydsl, our Open Source framework for type-safe queries:

Dashboard view

The high code duplication level comes from delegation pattern duplications in the Querydsl expression model.


The combination of Hudson and Sonar brings us the continuous feedback on our coding we need. All of our active projects are continuously built in Hudson and nightly builds are available for Sonar.

Make sure you visit Nemo, the public live instance of Sonar, which displays the analysis results of prominent Java Open Source frameworks.

Now we are aiming to further improve our code reuse level. We extensively use Open Source frameworks and host also our own frameworks, but sometimes helpful code snippets are buried in our SCM tool Subversion, where it is not easily found.

OpenGrok seems like a good solution for maintaining an index of program sources. Stay tuned for further posts.


Querydsl as an alternative to the JPA 2 Criteria API

Querydsl is our flagship Open Source project for type-safe queries in JDO, JPA, SQL and other querying languages.

Last weekend I posted a thread in our Mysema Source Forum related to the verbosity of JPA 2 Criteria queries.

The thread presents JPA 2 and Querydsl queries side by side. Just that, not more. Here is one query comparison example.

The use case of this example is to query for single men and women as an cartesian view. At first the query expressed via the JPA 2 Criteria API :

CriteriaQuery query = builder.createQuery();
Root<Person> men = query.from( Person.class );
Root<Person> women = query.from( Person.class );
Predicate menRestriction = builder.and(
    builder.equal( men.get( Person_.gender ), Gender.MALE ),
    builder.equal( men.get( Person_.relationshipStatus ),
RelationshipStatus.SINGLE ));
Predicate womenRestriction = builder.and(
    builder.equal( women.get( Person_.gender ), Gender.FEMALE ),
    builder.equal( women.get( Person_.relationshipStatus ),
RelationshipStatus.SINGLE ));
query.where( builder.and( menRestriction, womenRestriction ) );

and now via Querydsl

JPAQuery query = new JPAQuery(em);
QPerson men = new QPerson("men");
QPerson women = new QPerson("women");
query.from(men, women).where(

The guys from the JPA group decided that fluent expression construction is not an option so a CriteriaBuilder for criteria construction was needed. CriteriaBuilder contains methods for all possible operation constructs, not grouped in any way.

Compare this with Querydsl, which has a dynamic query model with a fluent API, which supports IDE autocomplete and a much faster and compact way to write queries.

Also the distinction of paths, joins and the metamodel doesn't really make query construction easy.

A root path for the Person type is constructed like this in JPA 2 :

Root<Person> men = query.from( Person.class );

In Querydsl you just create an instance of the metatype for Person :

QPerson men = new QPerson("men");

In most cases though you can use the default instance of the metatype like this :

QPerson men = QPerson.person;

And to refer to the gender property of the Person path :


whereas in Querydsl you just use a field of the metatype instance :


The dynamic metatypes of Querydsl combine a type-safe representation of the query domain, path references and operation construction in a fluent and concise way.

In addition to JPAQL and HQL Querydsl supports JDOQL, SQL, RDF, Lucene, Hibernate Search and Java collections.

We at Mysema use Querydsl in all our own projects with multiple backends and are 100% happy with it. ;)

Welcome to our Blog

We are pleased to announce the launch of our Mysema blog. This is the space where you can read posts on our customer and open source projects as well as comments on external events. The main language of this blog will be English with occasional posts in Finnish or other languages. If you haven't already done, be sure to visit also our Homepage for more information on our company and Mysema Source for more information on our Open Source projects. Hope to see you around!