lombok and modern js
A quick look at some technologies I've been playing with.
So, I started using a few new-to-me technologies and thought I’d write a bit about my experiences with them so far.
First up, we have the Lombok library for Java. Lombok is, in short, a decimator of boilerplate in Java through some annotation based magic. You can annotate your boring data objects with @Data
and no longer need to worry about writing required args constructors, getters, setters, hashCode, equals, or toString methods. Each of those can also be done individually, as well, giving a lot of flexibility. I was playing around with it on a project that was starting to get a little too repetitive and was thoroughly impressed by the amount of mental garbage I was able to remove from most model objects. Lombok checks the strings that you use to configure those properties against the fields on the class automatically, giving warnings and errors as necessary–none of the standard stringly typed weaknesses here that make you give up help from your compiler.
The only thing that Lombok seems to be missing is a good way to only partially call toString
on objects inside of a class, though maybe I’ve just not played with it enough yet. Otherwise, the equals
and toString
calls that it generates (and allows you to configure) are pretty solid. You can use the excludes on the equals
generator to limit equality to be entirely based off a superclass by just listing all of the members of the class you’re writing, which comes in handy for objects that are entirely determined to be equal off of something such as their database primary key / version.
Setting up Lombok was especially trivial using Spring Boot, since it happens to be included. Specify the dependency in your pom.xml
and all of the compilation will kick in for your builds. To see the magic and generated methods in an IDE outline, you do need to download lombok.jar
, double-click it, and install it onto your IDE–installations should be auto-detected, but you can also manually point it at a folder.
Moving on, one of my major goals at work lately has been trying to modernize various parts of our stack. This started with some heavy maven plugins to handle minification and LESS compilation, but recently I found a great way to bind npm into maven through frontend-maven-plugin
. Don’t run away screaming quite yet, because as horrible as that sounds, binding to individual maven lifecycle steps actually results in a pretty great integration since you can choose to run individual scripts from your package.json
.
Naturally, I wanted to see how far the rabbit hole goes, which resulted in setting up webpack. End result is that changing a Javascript or LESS file in Eclipse automatically builds and repackages the bundle into a webjar that Spring can serve up off the classpath with unique versioning to handle cache issues.
Mostly automatically, anyway, since I haven’t quite worked out how to get Eclipse to automatically discover the resources that have been built into a source folder without a manual refresh. Compared to the old plugins we used that required dropping down to the command line and then a refresh (since they didn’t support lifecycle bindings), this is actually a pretty huge step up in time saving that simplifies using npm down to being trivial for new developers that we introduce onto projects. Why they wouldn’t have it anyways is a subject for some other time.
I could write volumes about how mindbogglingly unintuitive it is to get webpack working properly if you don’t start from someone’s boilerplate template. In an effort to not relive some of that experience, I’m going to instead move on to say that another iteration of this post will probably include some talk of Phaser and React. I’ve got a new side project that I’m vaguely tossing around from being dissatisfied with a few of the idle games I’ve been playing with recently.