Posted on by kons

New library or language? A checklist

Note: This blog is an unfinished form, written late 2016, but rather than write an epic, I thought it would be good to share some of the thoughts here.

A colleague recently suggested we use Project Lombok with our Java code. The company I work for also has some experience with Kotlin. We’re a new team, I could see pros and cons for each.  In a world where Java 8 has been widely adopted, alternate JVM languages don’t get the free lunch that they used to when it comes to simply reducing boilerplate and introducing closures as a way to get developer mindshare.

Picking libraries and frameworks is something we do frequently as technologists. I thought I’d document the mental checklist I went through when Lombok was recently mentioned. The criteria will vary based on your own experience and your feeling on how it will be adopted in your team.

There feels like there is a swing back to native Java over languages. I know of in Melbourne at least, of a few companies that have experimented in another JVM language or two, but are now building code back in Java again because it is easier to get talent, and the domain is now well understood that re-writing and maintaining in Java 8 won’t leave the project lacking.

On a completely new project & new company, the experience, tooling, and team process is all up for grabs.  Most recently, as Java has made strides again in its development, and those who have experimented with other JVM languages and found hiring for that talent more difficult. I’ll spend the rest of this blog looking at Project Lombok, and a checklist I thought about in evaluating it.

Project Lombok

Project Lombok is a set of Java annotations that generate the boring repetitious code that is usually found in Java domain objects and service code.  The end result is smaller classes that are more succinct, and closer to more modern JVM languages like Groovy and Kotlin, in expressing their intent.

On the face of it, who doesn’t love descriptive clean code?  Being a Java annotation processor, the annotations and keywords provided by Lombok are quite clear.  Unlike picking up a new JVM language, the code can be understood by anyone who has had some basic Java knowledge.  This means barrier to entry is quite low. You can hire Java developers knowing that they can adopt Lombok quite easily.

When I was first made aware of Lombok toward the end of the last decade, Eclipse was the only IDE supported.  As I’d moved to IntelliJ IDEA, support was non-existent due to the way Lombok augmented the code, it required a special annotation processor.  Something Eclipse supported but it would be a few years before IDEA also picked up the same level of support.  I had also moved onto Groovy and working on a Grails project.  I was writing my unit tests for Java code in Groovy as well, then replacing Java classes with Groovy implementations where it made sense to do so.  Therefore the perceived benefits of adopting Lombok versus the work we had already done to get Groovy into our build pipeline and developer workflow didn’t win out.

Checklist

Its important to contrast the decisions and benefits made via choosing to adopt a library versus picking up a new language altogether.

  • Licensing
  • Availability
  • Code Activity
    • release frequency,
    • patches accepted,
    • issues reported and resolved
  • Community
    • Issue Tracker
    • Support & Chat Forums
    • StackOverflow participation
    • Perception – who else is using it? Other thoughts from illumaniries on it?
  • Compatibility
    • Interoperability with Java Code
    • Other with Libraries
    • Future versions of the JVM
    • Not quite Java – Android, Aspect Oriented Hooks, other JVM implementations like Azul, bytecode manipulation libraries, reflection libraries
  • Tooling
    • Works with existing IDEs
      • Navigating code – native navigation tools over ⌘Find
      • Refactoring code – understanding concepts over ⌘Replace
    • Works with existing command line tools
    • Testing tools
      • Unit testing and mocking frameworks
    • Build tools
      • Additional time to build
  • Risks
    • Backout plan – When we encounter compatibility issues, can we roll back to a native implementation?  How much are we locked in by the new technology?
    • Lock In- Are we limited in upgrading other libraries, frameworks or JVM implementations due to the way the library works?
  • Developer Growth
    • What new computer science or programming concepts does the library introduce us to?
    • Bad enablement – Does the library or language facilitate an improved way of sustaining our old way of thinking?
    • Disruptive enablement – Does the library or language facilitate the growth of new skills and understanding concepts that let us write and implement better code?
  • Adoptability
    • If the library or framework introduces new paradigms or changes workflow, what are these changes – Will your team accept them?

Under a different light

So in the past, I may have discounted Lombok since it didn’t work with my tools.  How does it compare these days?  And what about Kotlin?  I’ve got developers who use both Eclipse and IDEA, and a build that uses Gradle.  With a bit of research, I found:

  • Is it safe to use Project Lombok – A Stack Overflow question with a particular answer that journals one developers experience through adopting Lombok over a number of years. In particular, there is the occasional issue with some Groovy libraries, and Java 9, but most get resolved soon.
  • Compatibility with IDEA has improved. There is a 3rd party Lombok plugin that appears to be refactoring aware.  Eclipse still has its support.  There were some interesting bugs mentioned in the issue tracker but nothing sev 1
  • AutoValue an alternate Google implementation to Lombok that has supposedly better compatibility with other tools than Lombok
  • Edit Oct 2017: Kotlin becomes a first class language under Android.  Tooling and adoption have increased dramatically.  This has changed how Kotlin is perceived.  My current employer is looking to adopt Kotlin in more microservices, and due to the statically typed nature of Kotlin compared to Groovy and its funky AST transform magic, is rewriting some of the Groovy services in Kotlin.

Leave a Reply