Implementing quality in Java projects

Implementing Quality
on Java projects
Vincent Massol
Committer XWiki
CTO XWiki SAS
@vmassol
Saturday, April 20, 13

Vincent Massol
• Speaker Bio
•CTO XWiki SAS
• Your Projects
•XWiki (community-driven open source project)
•Past: Maven, Apache Cargo, Apache Cactus, Pattern
Testing
• Other Credentials:
•LesCastCodeurs podcast
•Creator of OSSGTP open source group in Paris

What is Quality?

The XWiki project in summary
• 9 years old
• 28 active
committers
• 7 committers
do 80% of
work
• 700K
NCLOC
• 11 commits/
day

Examples of Quality actions
• Coding rules (Checkstyle, ...)
• Test coverage
• Track bugs
• Don’t use Commons Lang 2.x
• Use SLF4J and don’t draw
Log4J/JCL in dependencies
• Automated build
• Automated unit tests
• Stable automated functional
tests
• Ensure API stability
• Code reviews
• License header checks
• Release with Java 6
• Ensure javadoc exist
• Prevent JAR hell
• Release often (every 2 weeks)
• Collaborative design
• Test on supported
environments (DB & Browsers)

Quality Tip #1
API Stability

The Problem
Class Not Found or Method Not
Found

API Stability - Deprecations
/**
* ...
* @deprecated since 2.4M1 use {@link #transform(
* Block, TransformationContext)}
*/
@Deprecated
void transform(XDOM dom, Syntax syntax)
throws TransformationException;

API Stability - CLIRR (1/2)
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>clirr-maven-plugin</artifactId>
<configuration>
<ignored>
<difference>
<differenceType>7006</differenceType>
<className>org/xwiki/.../MetaDataBlock</className>
<method>org.xwiki....block.Block clone()</method>
<to>org.xwiki.rendering.block.MetaDataBlock</to>
<justification>XDOM#clone() doesn't clone the meta
data</justification>
</difference>
...

API Stability - CLIRR (2/2)
Example from XWiki 5.0M1 Release notes

API Stability - Internal Package
Javadoc
CLIRR
<plugin>
<artifactId>clirr-maven-plugin</artifactId>
<excludes>
<exclude>**/internal/**</exclude>
<exclude>**/test/**</exclude>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin
<configuration>
<excludePackageNames>*.internal.*
</excludePackageNames>

API Stability - Legacy Module
Aspect Weaving
+ “Legacy” Profile
<plugin>
<artifactId>aspectj-maven-plugin</...>
...
<configuration>
<weaveDependencies>
<weaveDependency>
<groupId>org.xwiki.rendering</...>
<artifactId>xwiki-rendering-api</...>
...

API Stability - Young APIs
/**
* ...
* @since 5.0M1
*/
@Unstable(<optional explanation>)
public EntityReference createEntityReference(String name,...)
{
...
}
+ max duration for keeping the annotation!

API Stability - Next steps
• Annotation or package for SPI?
• Better deﬁne when to use the @Unstable
annotation
• Not possible to add a new method to an existing
Interface without breaking compatibility
•Java 8 and Virtual Extension/Defender methods
interface TestInterface {
  public void testMe();
  public void newMethod() default {
    System.out.println("Default from interface"); }

Quality Tip #2
JAR Hell

The Problem
Class Not Found or Method Not
Found or not working feature

No duplicate classes @ runtime
<plugin>
<groupId>com.ning.maven.plugins</groupId>
<artifactId>maven-duplicate-finder-plugin</artifactId>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<failBuildInCaseOfConflict>true</...>
<exceptions>
...

Surprising results...
• Commons Beanutils bundles some classes from Commons
Collections, apparently to avoid drawing a dependency to it...
• Xalan bundles a lot of other projects (org/apache/xml/**, org/
apache/bcel/**, JLex/**, java_cup/**, org/apache/regexp/**). In
addition, it even has these jars in its source tree without any
indication about their versions...
• stax-api, geronimo-stax-api_1.0_spec and xml-apis all draw
javax.xml.stream.* classes
• xmlbeans and xml-apis draw incompatible versions of
org.w3c.dom.* classes
14 exceptions in total!

Maven: dependency version issue
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.4.0</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>0.9.9</version>

</dependency>
</dependencies>
Will run logback 0.9.9
with slf4J-api 1.4.0
instead of 1.5.0!

Maven: ensure correct version
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-version-compatibility</id>
<phase>verify</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireUpperBoundDeps/>
</rules>

Quality Tip #3
Test Coverage

The Problem
More bugs reported, overall
quality goes down and harder to
debug software

Use Jacoco to fail the build
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution><id>jacoco-prepare</id>
<goals><goal>prepare-agent</goal></goals>
</execution>
<execution><id>jacoco-check</id>
<goals><goal>check</goal></goals>
</execution>
</executions>
<configuration>
<check>
<instructionRatio>${xwiki.jacoco.instructionRatio}</...>
</check>}

Strategy
• When devs add code (and thus
tests), increase the TPC percentage
• Put the Jacoco check in “Quality”
Maven Proﬁle
• Have a CI job to execute that
proﬁle regularly
•About 15% overhead compared to build
without checks
• “Cheat mode”: Add easier-to-write
test

Quizz Time!
[INFO] --- jacoco-maven-plugin:0.6.2.201302030002:check (jacoco-check)
[INFO] All coverage checks have been met.
[INFO] --- jacoco-maven-plugin:0.6.2.201302030002:check (jacoco-check)
[WARNING] Insufficient code coverage for INSTRUCTION: 75.52% < 75.53%
Step 1: Building on my local machine gives the following:
Step 2: Building on the CI machine gave:
Non determinism! Why?

Quizz Answer
private Map componentEntries = new ConcurrentHashMap();
...
for (Map.Entry entry : componentEntries.entrySet())
{
if (entry.getValue().instance == component) {
key = entry.getKey();
oldDescriptor = entry.getValue().descriptor;
break;
}
}
... because the JVM is non deterministic!

Quality Tip #4
Functional Testing
Stability

The Problem
Too many false positives
leading to developers not
paying attention to CI emails
anymore... leading to failing
software

False positives examples
• The JVM has crashed
• VNC is down (we run Selenium tests)
• Browser crash (we run Selenium tests)
• Git connection issue
• Machine slowness (if XWiki cannot start under 2 minutes
then it means the machine has some problems)
• Nexus is down (we deploy our artifacts to a Nexus
repository)
• Connection issue (Read time out)

Step 1: Groovy PostBuild Plugin (1/2)
def messages = [
[".*A fatal error has been detected by the Java Runtime Environment.*",
"JVM Crash", "A JVM crash happened!"],
[".*Error: cannot open display: :1.0.*",
"VNC not running", "VNC connection issue!"],
...
]
def shouldSendEmail = true
messages.each { message ->
if (manager.logContains(message.get(0))) {
manager.addWarningBadge(message.get(1))
manager.createSummary("warning.gif").appendText(...)
manager.buildUnstable()
shouldSendEmail = false
}
}

Step 1: Groovy PostBuild Plugin (2/2)
... continued from previous slide...
if (!shouldSendEmail) {
def pa = new ParametersAction([
new BooleanParameterValue("noEmail", true)
])
manager.build.addAction(pa)
}

Step 2: Mail Ext Plugin
import hudson.model.*
build.actions.each { action ->
if (action instanceof ParametersAction) {
if (action.getParameter("noEmail")) {
cancel = true
}
}
}
Pre-send Script

Results
+ use the Scriptler plugin to automate configuration for all jobs

Quality Tip #5
Bug Fixing Day

The Problem
Bugs increasing, even
simple to ﬁx
ones, devs focusing too much on
new features (i.e. scope creep)
vs ﬁxing what exists
Bugs created vs closed

Bug Fixing Day
• Every Thursday
• Goal is to close the max number of bugs
• Triaging: Can be closed with Won’t fix,
Duplicate, Cannot Reproduce, etc
• Close low hanging fruits in priority
• Started with last 365 days then with last 547
days and currently with last 730 days (we
need to catch up with 6 bugs!)

Results

Conclusion

Parting words
• Slowly add new quality check over time
• Everyone must be on board
• Favor Active Quality (i.e. make the build fail) over
Passive checks
• Be ready to adapt/remove checks if found not useful
enough
• Quality brings some risks:
•Potentially less committers for your project (especially open
source)

Be proud of your Quality!
“I have offended God and
mankind because my work
didn't reach the quality it should
have.”
Leonardo da Vinci, on his death bed

Implementing quality in Java projects

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to Implementing quality in Java projects

Similar to Implementing quality in Java projects (20)

More from Vincent Massol

More from Vincent Massol (20)

Recently uploaded

Recently uploaded (20)

Implementing quality in Java projects