There are many nice things about Scala as a language, but compared to Java tool support is poor.
Fortunately we get some time to play with interesting things at work, so a few weeks ago we decied to add a bit of Scala support to one of the tools we use when developing Java.
Last month we ran the first of our two annual "code fests" - two days in which we down tools and build something . . . different.
Different usually means something pointless, but entertaining, implemented using an unfamiliar tech stack.
As an example our fridge is currently wired up to a number of philips hue lightbulbs and a pressure sensor (well a set of kitchen scales crudely hacked to have network connectivity) so we can track when we're low on milk.
Building something to throw away is a great way to learn a new technology, but this time I thought it would be nice to build something that might have a longer lifespan.
We're considering using a Scala based stack for the first time for an upcoming project, so I thought it would be nice to make a small contribution to the Scala ecosystem by adding some Scala support to sonarqube.
I wrote my first Scala application back in 2006, in what I guess must have been Scala 2.0.
When I say application I mean a few hundred lines of clumsy hackery.
Although this introduction to functional programing changed the way I wrote Java from that point onwards, this was my last Scala program of any size.
Over the last 8 years I've kept an eye on Scala and picked up some eldritch knowledge of the low level implementation through my work on mutation testing, but I couldn't call myself a competent Scala programmer. The last time I'd written any was for the coursera course.
My colleagues Keir and Grant didn't have any stronger credentials than myself, with Grant knowing absolutely nothing about the language and Keir being at a similar beginner level.
The great thing about a hack day is that expectations are low and incompetence need not hold you back.
Two sonar plugins for Scala already exist
The first is mainly focussed on tracking metrics such as lines of code. It also supports code coverage and checkstyle, but there sounds to be a plan to remove these features.
When I tried to use it, it null-pointered.
The scoverage plugin is narrowly focused on tacking test coverage.
It's author (Rado Buransky) made contact with the community plugin team about releasing it as a plugin dependent on the community one, but this didn't seem to go anywhere.
The SonarQube philosophy seems to be to have one large plugin handling all Scala concerns, while the model suggested by Rado is a pick and mix approach of small sharply focussed plugins that developers can opt to include.
Personally I think Rado's approach is the better one, particularly considering the rapidly evolving nature of Scala and its ecosystem.
Rather than trying to add a feature to one of the existing plugins we therefore decided to create a new one that could be used stand-alone or in tandem with the existing plugins.
We could probably have pulled something together in Java quite quickly, but this would have rather missed the point. So we set about coding in pure Scala.
Given a whole new eco-system to play with we had to make a few quick technology choices.
There are a number of static analysis tools for Scala such as wart remover and linter but most seem quite immature and work as compiler plugins.
We opted to wrap up ScalaStyle mainly because it does not work as a compiler plugin, instead using the scala parser from scalifrom. This means it can be easily run against a code base without having to include it in the build.
For testing we had to make a choice between ScalaTest and specs2.
As Eric Torreborre is one of the very few people who follow me on twitter I was minded towards specs2. This is not however the strongest basis for a technical decision and ScalaTest's FlatSpec felt reasonably familiar to long time JUnit users, so we went with that.
Development wasn't exactly fast.
Most time was burnt on familiarising ourselves with the sonar api and scalacheck code, plus the usual unpredicatable things.
This error stumped us for a while
[ERROR] uncaught exception during compilation: java.lang.AssertionError
[ERROR] error: java.lang.AssertionError: assertion failed: javax.annotation.CheckForNull
Until we worked out that the scala compiler needed the jsr305 annotations to be available at compile time due to the sonar apis use of @CheckForNull
.
But by the end of day two we had a working plugin that we present now for your consideration over at github.
Henry Coles
Tags: scala, sonarqube
July 11th 2014