Using LGTM when using lombok in java

28 Oct 2019 on Development, Java, Interlok

Code analysis is good; some code analyzers are closer to my definition of useful

I quite like LGTM since it doesn’t tend to flag up that many false positives when scanning your code. The problem with a lot of the code analysis tools like spotbugs, sonarqube, codacy etc¹ is that they often apply rules without understanding the context or the style of the code in question; having false positives as shown² is frustrating, and invariably ends up with a large number of customised rule configurations for any new static code analysis tool, or in fact ignoring the tool completely and marking it as worse than useless (which isn’t helpful either).

Maybe you’ll like this false positive better³:

I get that context is hard, and you might argue better safe than sorry when it comes to these kinds of things; but the point here is that the security wonks will run the tool against your codebase, and promptly complain at you that your code has 1234 Critical vulnerabilities; which is of course 1234 too many. What they don’t understand is that their security tool has no context, and is pretty stupid actually.

Anyway LGTM hasn’t caused any kind of friction like that, the ones it’s raised have been useful; and it allows you to comment your source code to mark something as a false positive; this means that all the configuration is stored where you want it as a developer; i.e. in the source code itself.

We’ve started using lombok for a bunch of projects since it removes boilerplate code which can mean higher coverage since you don’t have to explicitly test getters/setters/builders anymore. However, source files that are lombokified are ignored by LGTM which means that the code analysis step will scan less code than you expect. Since lombok has a delombok step to turn your source code into actual java code, we can force LGTM to scan our code by customising it and our build script. We’re using gradle here as the build system, so the required customisations are actually fairly minimal.

Customise/add .lgtm.yml

The important part here is the custom build_command and generated. The other things are useful since we wanted to exclude .html from being scanned (otherwise LGTM can think you’re a javascript project) and .yml files can get pinged sometimes for being configuration with passwords in them⁴. What you’re effectively saying is “I have a custom build command; so execute that and please make sure you scan all java files that you think have been generated by the build step”. By default the gradle system build default is to execute testCompile which we want to change.

extraction:
  java:
    index:
      gradle:
        version: 5.6.3
      build_command:
        - ./gradlew --no-daemon -S lgtmCompile

path_classifiers:
  docs:
    - "LICENSE*"
    - "*.md"
    - "*.html"
  ci:
    - "appveyor.yml"
    - ".codecov.yml"
    - ".travis.yml"
    - ".circleci"
    - ".dependabot"
  generated:
    exclude: "**/*.java"

Add custom tasks into build.gradle

We’re using the freefair lombok gradle plugin which has made things pretty seamless in terms of the build process, but we need to make sure that our custom lgtmCompile task uses the source generated out of delombok.

delombok {
  target = new File("${project.projectDir}/src/main/generated")
}

task lgtmCompile(type: JavaCompile, dependsOn: delombok) {
  group 'Build'
  description 'Compile for lgtm'

  source = sourceSets.main.extensions.delombokTask
  destinationDir = sourceSets.main.java.outputDir
  classpath = project.sourceSets.main.compileClasspath
}

Note that you will want to tidy up in your gradle script and/or ignore that directory in your .gitignore since you don’t want git clutter. After that you can commit+push.

Don’t use @NonNull

Since LGTM will apparently ignore all files that have lombok in them -> lgtm community discussion; that means you can’t use the @NonNull annotation that lombok provides, since it is preserved in the source code generated by delombok as it is considered a form of documentation; it would be nice if that could be controlled via lombok configuration, but everyone’s allowed to have an opinion. It’s a small price to pay for getting benefits that LGTM provides.

Finally

You can see the result of the scan on one of the Interlok optional components on LGTM itself; it now completely ignores what’s in src/main/java and only scans src/main/generated. Things could still be improved I suspect, but this is a good start to getting your lombok projects enabled with LGTM.

1. Other code analysis tools are available, like scrutinizr, PMD, etc ↩︎

2. You can argue this is a style thing; but this is absolutely a false positive. ↩︎

3. I’m not ashamed to say that I turned the air blue. ↩︎

4. Our travis/circleci configuration may install database instances for test purposes into the test image with the passwords in plain text, but since we don’t use either to publish anything… ↩︎