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.