SonarQube, FindBugs and Java 8

This post describes how to patch SonarQube to make the FindBugs plugin analyze Java 8 code.

Background

We start with an official installation of SonarQube 4.3.2 with Sonar Java 2.3. The Sonar Findbugs plugin uses findbugs 2.0.3. This version uses ASM 3.3 for byte code analysis, but Java 8 requires ASM 5.0.x.

FindBugs snapshots have been using ASM 5.0.2 for a while, and a Java 8 compliant FindBugs 3.0.0 release has now been published, but the artifacts are not yet available in Maven Central or any other Maven repository.

In fact, the FindBugs Maven build process is not quite clean, relying on a local snapshot of an external dependency (Apache BCEL).

Thus, for patching SonarQube, we need to do a clean Maven build of FindBugs, then build sonar-findbugs with this updated dependency and finally overwrite the sonar-findbugs plugin in our SonarQube installation.

Whenever patching third-party Maven artifacts, I use a project or company suffix on the version identifiers, e.g. -eos-1, to distinguish my patches from official releases.

Building FindBugs

git clone https://code.google.com/p/findbugs
cd findbugs/findbugs
mvn install:install-file -Dfile=lib/bcel-6.0-SNAPSHOT.jar -DgroupId=com.google.code.findbugs -DartifactId=bcel -Dversion=6.0-eos-1 -Dpackaging=jar

Then edit pom.xml, setting the version to 3.0.0-eos-1 and replacing the bcel dependency version 6.0-SNAPSHOT by 6.0-eos-1.

Now build and install FindBugs 3.0.0-eos-1 to your local repo:

mvn clean install

Building sonar-findbugs

git clone https://github.com/SonarSource/sonar-findbugs.git
cd sonar-findbugs

Edit pom.xml, set findbugs.version to 3.0.0-eos-1 and maxsize in the maven-enforcer-plugin rules to 6000000.

Now build and install sonar-findbugs 2.4-SNAPHOT in your local repository:

mvn clean install

Install the patched plugin

• Stop your SonarQube server.
• Go to SONARQUBE_HOME/extensions/plugins and replace sonar-findbugs-plugin-2.3.jar by sonar-findbugs-plugin-2.4-SNAPSHOT.jar
• Restart your SonarQube server and run a FindBugs analysis under Java 8.

Download patched plugin

You can download the patched plugin from DropBox.

Disclaimer

Use these instructions at your own risk.

No More Commercial Support for GlassFish - So What?

"GlassFish reduced to toy product" and "R.I.P. GlassFish" are some of the headlines regarding Oracle's announcement to withdraw commercial support for the application server acting as Java EE reference implementation.

Oh well, I've stopped using GlassFish 3.x on a regular basis about a year ago when it became apparent that GlassFish 3.1.2.2 was a dead end for the Java EE 6 Open Source product (see comments of the linked blog post), and I've never really started using GlassFish 4.0 except for quick demos, knowing the release policy would be just the same as for 2.x and 3.x, where the Open Source release was more of a public beta for the closed-source commercial product.

It's nice to know you can get commercial support for a server if you need it and if somebody is willing to pay for it. On the other hand, lots of companies run successful businesses with applications built on Open Source web containers or application servers without any commercial support, because commercial support is not affordable in their business models. Moreover, commercial support is not a guarantee for getting a hot-fix when you need it, if the vendor's priorities happen to differ from your own.

Like many others, I've turned from GlassFish to JBoss AS/WildFly (after evaluating and dismissing TomEE for lack of stability and documentation). JBoss AS 7 has surpassed GlassFish in terms of usability and reliability, and it's just a shame that RedHat has now converted JBoss AS to a Not-So-Open Source project, hiding branches and tags in a private repository and no longer publishing Community binaries. But that's another story...

Browsing a Lucene 4.x index with Luke

Luke is a small desktop client for browsing Lucene indices. It is very useful for troubleshooting when you work with Lucene directly embedded in your application.

While upgrading an application from Lucene 3.4 to Lucene 4.3.1, I realized that Luke is not quite up-to-date with Lucene, it is stuck somewhere in 4.0.0 alpha.

But the good thing about Open Source is, if the original project owners lose time, resources or interest, others may show up and fork or continue the work.

A number of people have forked or copied Luke to GitHub. tarzanek/luke also offers binary builds on java.net, and this version works fine for me with Lucene 4.3.1 so far.

Eclipse Juno Patch for XML Editor Performance

Eclipse Juno has a number of performance regressions compared to Indigo. Switching back and forth between XML and Java editors can be tediously slow even in Juno SR1.

The patch provided for bug 394588 solves the issue or at least significantly improves the response time of the IDE.

In my team, we have tested the patch successfully on Windows 32 bit and Ubuntu Linux 64 bit with Oracle Java 6 and 7.

The patch can be installed from a special update site via Help | Install New Software.

Logging with SLF4J and Logback in Tomcat and TomEE

Logging in Java would be a lot easier if every open source project out there would use SLF4J logging API, but of course this will never happen.

The fact that java.util.logging made it into the JRE does not make it any better than it is, so there's a good reason to hide it behind a facade and never use it directly. But there is no reason for everyone to invent their own logging facades instead of simply using SLF4J.

In my own applications, I always use SLF4J with Logback. Working with Tomcat, this means I'm getting an ugly mixture of log messages in different formats from my web application logging to System.out with Logback, and from Tomcat itself logging to System.err via JULI and java.util.logging, not to mention any third-party libraries contained in my application which use log4j, Apache Commons Logging or whatever.

There are two independent but similar approaches of replacing the official Tomcat JULI libraries by an SLF4J or Logback adapter: tomcat-slf4j and tomcat-slf-logback.

I've tried both, but in the end, I think it's easier to use nothing but the JUL-to-SLF4J bridge and other standard artifacts.

Read more »

Using the Maven 3 API with Maven 2 Components

Working on a Maven plugin, I was trying to upgrade the Maven API from 2.x to 3.0.4. After the upgrade, the plugin would no longer compile due to an unsatisfied transitive dependency of the maven-archiver used by the plugin: The class org.apache.maven.artifact.DependencyResolutionRequiredException could not be resolved.

The same issue was posted on the Maven Users list, but never answered.

Solution: Add a dependency on maven-core, or on maven-compat which should handle all compatibility issues with Maven 2.

New OSGi Console in Equinox 3.8.0

Equinox 3.8.0, the OSGi framework running Eclipse Juno, comes with a new console built on top of Apache Felix Gogo Shell.

It is debatable whether or not this is an improvement. Veteran Equinox users are greeted with the following message when trying to activate the console:

Read more »

Maven Build Info for Web Applications

Problem

* You want to include build info like build number, revision number etc. as a web resource in your web applications.
* You have a multi-module Maven project with more than one WAR module and a number of JAR modules.
* You want to minimize copy-and-paste configuration in your POMs.
* The mechanism should not depend on a CI server.

Solution

This can be achieved using the Build Number Maven Plugin and the overlay feature of the Maven WAR plugin.

Read more »

OSGi and CDI Combined

Pax CDI is a new OPS4J community project I've started to combine the best of OSGi and CDI.

Once you've worked with CDI or with an up-to-date annotation-based flavour of Spring, the service registry API or XML-based dependency injection in the Blueprint or Declarative Services style suddenly appears rather verbose.

On the other hand, even though Java EE 6 is more lightweight than ever, its monolithic nature feels rather a burden when you're used to OSGi.

Why not have the best of both worlds? The idea is not new, it has been implemented to some extent both in weld-osgi and in the FighterFish subproject of GlassFish.

Unlike these two projects, Pax CDI is independent of any given CDI, Java EE or OSGi implementation. The first proof-of-concept release is based on Apache OpenWebBeans and Equinox. In contrast to weld-osgi, which required some modifications in Weld itself, Pax CDI works with an unmodified version of OpenWebBeans.

Trying to do the same with Weld is one of the next goals for Pax CDI.

An alpha release Pax CDI 0.1.0 is available from Maven Central.

Fixing Editor Tab Fonts in Eclipse Juno

Eclipse Juno is out! It starts a good deal faster than Indigo, shows a more colourful (but ill-proportioned) splash screen, and then opens a workbench window with oversized and truncated labels in all editor tabs.

This applies to Ubuntu 12.04 with KDE and the QtCurve GTK+ theme.

This issue is not due to QtCurve or SWT, as I had first suspected, but to the new CSS-based widget styling of the e4 platform. There is an E4 CSS Editor which is not included in Juno by default, but can be installed via the Update Manager.

With this editor, you can change the font-size and font-family properties of the MPartStack style used by the editor tabs.

Much better!

Update 14 Aug 2012: If you develop web applications and edit CSS files in Eclipse, you'd better deinstall the E4 CSS editor after customizing the workbench layout to fall back to the standard WTP CSS editor. The XText-based E4 editor does not recognize some legal syntax like unquoted URLs.

Actually, you don't need any Eclipse plugin to change the CSS, you can directly edit the CSS file in your Eclipse installation at plugins/org.eclipse.platform_4.2.0.v20120608140/css/e4_default_gtk.css.