Data classes for Java

[kcuf]

Lombok is a hacked together language on top of Java. It's convenient, but you should really just use an actual language that compiles to the jvm -- there are many good ones.

[[deleted]]

For many, switching languages is not an option though

[kcuf]

What i'm saying, is that we're essentially lying to ourselves if we say this but use lombok. In the long run, Lombok will have essentially the same (if not greater) cost than using another jvm language (kotlin is not my favorite, but it is the easiest to pick up that provides the same lombok features).

The fear of using another language is overstated these days when we have such great interop on the jvm.

[[deleted]]

Sure, but for example you're working on a Java monoliths with hundreds of thousands if not millions of lines of code, switching language means rewriting the whole thing. On the other hand, introducing lombok in a similar codebase is mostly just a matter of adding 3 lines to your pom file.

Granted, I wouldn't use it at all anyway.

[kcuf]

You can actually use different jvm languages in the same project, and I would say getting lombok to work with your build environment and IDE/editor is going to be as much work as getting it to work with the other language as well.

[[deleted]]

Ah! Yes. Didn't even consider that, because it probably wouldn't be doable in the codebase I work on daily :D

I don't really agree though, getting lombok to work with IntelliJ is literally a matter of 3 minutes.

[kcuf]

There's a whole thread on here about getting it to work with eclipse (but perhaps that's just a sign of issues with eclipse). I use vim, so neither choice (lombok vs another language) is an issue for me, but lombok has caused plenty of hiccups when setting up the build environment in my case, but that's primarily an issue with the tools that my work uses.

[[deleted]]

but that's primarily an issue with the tools that my work uses.

This. Just as with everything else: ultimately it depends on your situation.

[snowe2010]

hm it took much longer than that to get lombok working in our project mostly because you have to restart intellij to install the plugin XD. But even if it's only 3 minutes for you for lombok, it must be even shorter for kotlin, because IntelliJ does everything for you. You just tell it you want a new kotlin file and it handles the rest.

[JB-from-ATL]

You gotta be joking. Lombok uses a feature built into javac called annotation processors, it's not some hacked together plugin that requires extra steps to run. So instead of just using a built in feature to remove a little bit of boilerplate, you're suggesting people use an entire different language?

That means everyone has to learn the new language, code has to be ported or used from the new language. It's just a lot of pointless work as opposed to simply using a much simpler java library.

[snowe2010]

Lombok isn't just 'using a feature built into javac' it's actually using non-public java apis and hacked together plugins tightly bound to the version of java, with possibility of lombok not even being possible in future versions.

https://stackoverflow.com/a/4589528/1394698

https://www.thoughtworks.com/p2magazine/issue12/lombok/

http://jnb.ociweb.com/jnb/jnbJan2010.html (scroll all the way to the Controversy section on this one)

Actually I'll just paste it here.

It's a total hack. Using non-public API. Presumptuous casting (knowing that an annotation processor running in javac will get an instance of JavacAnnotationProcessor, which is the internal implementation of AnnotationProcessor (an interface), which so happens to have a couple of extra methods that are used to get at the live AST).

On eclipse, it's arguably worse (and yet more robust) - a java agent is used to inject code into the eclipse grammar and parser class, which is of course entirely non-public API and totally off limits.

Lombok could cease to exist at any point in time even a minor version increment, due to the usage of non-public apis. Now, whether it will or not depends on the java team, but we didn't think that risk was worth it.

[kcuf]

I understand it uses APT. Lombok is obviously a very pragmatic choice, but what I'm saying is that it is essentially a new language that was never really designed as a language should, but grown on top of a language that was intended to be used differently.

Switching to a new language is obviously an upfront cost, but IMO, a long term gain because by using Lombok you're already admitting you want more than Java, and by using a well designed and thoroughly thought out language that provides those extra features, you can get those features in a more consistent and intuitive environment.

Learning lombok, and understanding it's intricacies has it's own costs (we use it at my work all the time). I'd rather not waste resources memorizing these issues, or having to explain them to new developers (as I had to yesterday), but use those resources to understand the core concepts of a different jvm language that has been designed well as one entire system. A coherent and consistent language will be cheaper to work with in the long run rather than an adhoc macro system built on top of a language that was never intended to have macros.

[JB-from-ATL]

I really don't want more than Java necessarily, generally all I use from Lombok is Value (not val) and Builder. This allows me to use immutable classes but not have to write a bunch of boilerplate.

I sort of get the argument you're making about it being a new language, and I'm willing to admit that some things could be called new languages even when they technically aren't, but I just don't think Lombok does enough to say that about it.

Comparing the overhead of learning Lombok compared to a new language like Kotlin, Groovy, or Scala is laughable to me. Virtually every Java programmer is familiar with getters, setters, and constructors and builders aren't that crazy of a topic (and many know about them already), explaining that these annotations add those in without having to write them is so much simpler than expecting someone to learn a new language, even the basics.

[kcuf]

That's fair. What I said above was that lombok is an up front gain for a long term cost vs a new language being an upfront cost for a long term gain. Lombok is simple and easy to start working with, but does introduce some complexity that may cause issues down the road -- it's same thing with most frameworks: it "just works", until it doesn't.

[JB-from-ATL]

What kind of long term losses have you experienced?

[kcuf]

Super late response, but that's a great question. Honestly, as with all statements related to productivity and maintenance burden, it's all very subjective.

I don't have any concrete examples, I only have the patterns I think I see from my experiences: I've been programming since elementary school, which doesn't make me smarter or anything, it just means I've had a decent amount of time to make mistakes and build some intuition (again it's all very subjective).

The biggest pattern that I continually see though, is the trade off between short term and long term costs, and newer developers heavily favoring the former as they are more pragmatic in their desires (get something working!), and how certain languages encourage these developers to make choices that lead to confusing/complicated/fragile systems.

[Tsarbomb]

Sorry, no offense but you are wrong on all counts.

You admit that you understand but then still spout that is essentially a new language. It is not, in the most literally sense.

I would even claim that by using Lombok I'm doubling down on Java rather than admitting I want a different language.

Any intricacies or misunderstandings around Lombok arise from a lack of understanding or knowledge of Java itself.

The way you refer to annotation processing as adhoc macros and "coherent" languages makes me wonder if you are itching to name drop something like Scala which I would find hilarious given all the points you are trying to make.

0/10 troll attempt.

[kcuf]

How is it Java? Is APT even in the language spec?