While reviewing a PR from one of our newer FE devs, I ended up spending more time than I would like mulling over its composition. The work was acceptable for the most part; the code worked. The part that got me was the heavy usage of options objects.

When encountering the options object pattern (or anti-pattern, at times) in complex scenarios, I have to resist the urge to stop whatever I'm doing and convert it to the builder pattern/smack them in the head with a software design manual. As much as I would like to, code janitor is one of the least valuable activities I engage in daily, and consistently telling someone to go back to the drawing board for work that is functional, but not excellent is a great way to kill morale. Usually, I'll add a note on the PR, approve it, add a brown bag or two on that sort of thing, and make attendance mandatory for repeat slackers. Skills building and catharsis all rolled up in a tiny ball of investing in your people.

Builders make things so much cleaner; they inform users what actions are available in a context; they tend to be immutable, and when done well, provide an intuitive fluent interface for configuration that removes the guesswork. As a bonus, they're naturally compositional, so you can pass it around and accumulate data and only execute the heavy lifting bits when you need to. As a bonus, with typescript, the boilerplate is generally reduced as well, even without any code generation. And they're not just a dumping ground for whatever shit someone was too lazy to figure out how to integrate into the API neatly.

They're more work in js-land, sure; you can't annotate @builder like with Lombok, but they're generally not all that much work and friendlier to use.

I get it, Java is an old language that's verbose as the day is long. But damn, please don't make it *even more verbose* than it needs to be. We've got the tools now to make it at least somewhat tolerable.

I mean, come on, we've got lombok, we've got streams, and we've had Comparator.comparing since Java 8. That's the best part of a decade you've had the luxury of writing single line comparator implementations out the box, but noooo, certain people have to pretend they're stuck in the 90's by thinking these multiple if / else statements are somehow still the best way of doing things.

Dahhh. Skill up people. This is not an industry where you can just do everything how you did it 20 years ago and call it good.

The first time I've used JPA and Lombok annotations and suddenly didn't have to bother about getters and setters anymore and pretty much persisted my whole data tables with no effort.

Total game changer for me.

Spring Frameworks and the projects surrounding it such as Spring Boot, Thymeleaf, and recently lombok. Without these API's and frameworks I wouldn't be using Java half as competently as I am.

Development is moving further and further towards containerization and it's a massive time saver.

*updates to java 9*
rip lombok :(

I setup ELK for our team and went live with it on Production VM.

I'm the only one that knows how it works, is setup... Because no one else cares or wants to know as long as it works...

And well if it doesn't, let's just say they hope that I'm around...

On a side note, I think I'll leave a bit early today since I cut or main projects build process time by 50%.

Root cause: SONAR complains if you implement that using if else to match each field... it is pretty ugly...

And can use Lombok to clean it up, last rant.

So shaved off 10 minutes in each build... And well I'm like seriously? No one else bothered to figure this out for the last year or 2?

I mean I've been pretty busy too but the team had like 20 ppl and at least 4 senior devs and well u don't even need to be senior? Just inquisitive and proactive?

Existing projects, fair enough, but why you'd start a new Java project these days and *not* use Lombok is beyond me. The amount of boilerplate cut down is staggering. Some people still seem to hate it though - the mere mention of the word sends them into tremors.

(also, in b4 the predictable smartarses come in with "why you'd use Java these days at all is beyond me" 😉)

Lombok looks great! The dream of getting rid of boilerplate!

What are your experiences with it?

We have a huge domain model in Java and something is really fucked up with our equals/hashcode implementations and know body can track it down.

I have suggested Lombok/Groovy several times but they didn't listen.

Anyways it is so fucked up, that map.contains(foo) returns false, although it is part of the map.

So we wrote something like this:

for (Entity e: map.keyset) {
if (foo.equals(e) {
return true;
}
}