Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lombok makes Java cool again

bytes.grubhub.com

Post reply on HN
Print view View original

211–220 of 239 posts

Re: Lombok makes Java cool again

#211

Post by erik_seaberg »

cakeface wrote: post #119
platelminto wrote: post #6

I'm interested in the downsides of using Lombok, since the article seems to only focus on its positives and makes it seem like I should download it and start using it right now. Is there anyone here with Lombok experience that wants to share any issues they've run into while using it? All I can think of right now is the fact that the source code isn't compatible with Java.

I dislike Lombok. One reason I dislike it is that it makes IDE navigation, even with a required Lombok plugin, more difficult. A common task in a Java IDE is finding usages. It's harder with Lombok. Generally it's just more friction than plain Java code. I also don't like that the generated code is not checked in or visible. It makes code review harder. In theory you can have magic change to all Lombok classes just b…

> Most of this code can be generated by the IDE.

If you check in generated code, you have to prevent anyone from editing it (so it doesn't become something you have to start testing and reviewing) and include some kind of summary so nobody wastes time looking at it.

Re: Lombok makes Java cool again

#212

Post by tandr »

nine_k wrote: post #206
ganonm wrote: post #3

Lombok is a useful crutch if you're writing lots of Java code on a day to day basis. However, given how easy it is to use Kotlin alongside Java I would question whether Lombok is the right solution to the problem. Kotlin has data classes which auto generate sensible 'toString' and 'hashCode' methods which is a massive time saver. Really, if you are considering introducing Kotlin to a Java project I'd recommend you ju…

Kotlin is great. But go and try to persuade your company to bless another language for production. It may be easy when your engineering org is 5 persons. It's much harder, genuinely harder, when it's 250 engineers, and an hour of downtime costs hundreds of thousands. Adoption of another language, even clearly superior and interoperable, becomes a large and costly undertaking. So " just use Kotlin" is not always possi…

I am not parent commenter, but your comment really struct the chord here. I failed to convince 2 people (my mgr and team-lead) for our relatively-green-field project 2 years ago to use Kotlin... Thing is - same people killed an idea to use Lombok as well. So it is an uphill crawl no matter how "big" is the change - it is how comfortable people are with what you are proposing, and where they (and you) are in a command (aka responsibility-and-headache-if-something-new-goes-wrong) chain.

Re: Lombok makes Java cool again

#213

Post by pjmlp »

dajohnson89 wrote: post #210
pjmlp wrote: post #197

Earlier quoted context omitted.

I think that it brought a good competition against JEE (back when it was still J2EE), however I would still just use JEE for Java Web projects.

Just curious -- why?

Short answer, experience and employers.

My experience doing Web development in Java started with joining a team that was ramping up a project on WebSphere 5.1, alongside a migration from BEA WebLogic.

I went through a couple of WebSphere, JBoss and TomcatEE versions up to JEE 6, was the technical lead for an in-house JSF framework built on top of RichFaces, and on very last JEE project used PrimeFaces.

All the employers that I worked for, mostly used JEE stacks for their Java projects. Spring was the exception, rather than the norm.

Additionally, even if a bit slowly, many of the Spring improvements ended up in JEE and Spring also supports the JSR related to JEE anyway.

Nowadays I live in the .NET world, and the Java teams next door are happily delivering JEE based solutions.

So if I was suddenly asked to architect a Java based solution, naturally it would be JEE based.

Re: Lombok makes Java cool again

#214

Post by raz32dust »

apo wrote: post #132

Annotation-based programming might seem cool now, but wait a few years. Magic always seems cool when you add it to a project - hey, look - I don't have to do anymore. Then time goes on, and you (or your successor) opens up the project to track down a bug. Only there's no logical flow - things just seem to happen as if by magic. Lombok strikes me as magic in these ways. I actually had to go to the project home page to…

+1, I would rather have the cruft than have magic annotations. These dumb data classes also tend to proliferate when you are using other annotation heavy magic libraries like hibernate/spring. If you are having a dumb data class that is not a class that is meant to be serialized on disk (protobuf/avro etc.), then you are likely doing something wrong. See if you can avoid it.

Re: Lombok makes Java cool again

#215

Post by raz32dust »

vbsteven wrote: post #179

Spring boot with Lombok has been my go to framework for a few years now. Annotation-based programming seems to get a lot of negative attention here on HN, and it definitely is not perfect but there is just no other framework that (in my opinion) comes close in terms of productivity and workflow. Currently I'm building my SaaS + Selfhosted software licensing product with this Spring Boot + Lombok + Postgresql combo an…

While it is great while you are trying to get your product to market quickly, I would highly recommend getting rid of all these annotations as soon as you can. Preferably before your team grows to 5+ people or complexity grows beyond around 100k lines of code. It's hard to explain this to people from non-Java background, but the time writing non-annotation code will save you in debugging and maintainability is well worth it beyond that point.

Re: Lombok makes Java cool again

#216

Post by erik_seaberg »

hota_mazi wrote: post #169
kodablah wrote: post #120

Earlier quoted context omitted.

> This is similar to saying that since error codes are ignored by most developers, functions shouldn't bother returning them at all. It's not like saying they shouldn't return them (unchecked exceptions exist), it's like saying they shouldn't be forced to check the error code or declare that they will return that error code themselves. Checked exceptions aren't sound when in practice the same ones are reused to mean…

Checked exceptions are the compiler forcing the developer to consider error cases. What's not to like about that? Contrast with all the other approaches (runtime exceptions, return codes, Either/Result, etc...) where the developer can happily ignore errors, the code will compile, and then crash at runtime.

I'd be happier with checked exceptions if Java assumed that

  list.stream().map(doStuff)
might throw whatever doStuff might throw, but instead map is defined so that doStuff can never throw any checked exception, which requires smuggling out every real-world failure mode.

Re: Lombok makes Java cool again

#217

Post by apta »

chii wrote: post #105
zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

> all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. i would think javascript is the language with which the mistakes wasted the millions in man hours, not java.

Not to mention languages like golang that decided not to learn from previous mistakes (like the billion dollar mistake by including null in the language)

Re: Lombok makes Java cool again

#218

Post by apta »

jrockway wrote: post #153
fogetti wrote: post #103

Earlier quoted context omitted.

I am sorry to disagree but if you think that the iterator or visitor pattern or the state pattern or abstract factories are only bound to Java than you have a very low skills/understanding of those patterns and you really don't understand their importance and/or applicability.

I think it's a cultural thing. Other languages don't name things that seem obvious, like iterators or filters. Consider something like filepath.Walk in go; you give it a function that gets called for every file and directory in the root of your choosing. They don't call it a visitor, though, they call it a "walk function". It's just as clear, it's just as much of a design pattern, but they don't make a big deal about…

> Consider something like filepath.Walk in go; you give it a function that gets called for every file and directory in the root of your choosing. They don't call it a visitor, though, they call it a "walk function".

The ironic thing is that golang doesn't have an even better construct for this kind of pattern, namely pattern matching.

Re: Lombok makes Java cool again

#219

Post by willtim »

dmux wrote: post #207
ninja10 wrote: post #130

Earlier quoted context omitted.

Of those three (Kotlin, Scala, Groovy), Kotlin is by far the most pragmatic. Scala is nice, more powerful, but has a high cost when it comes to learning curve, complexity, and the library ecosystem. I'm not sure of the state of Groovy at this point after it got transferred to the apache foundation. Kotlin on the other hand strikes a nice balance in many areas.

How do you define pragmatic? Apache Groovy is still under active development. We've actually started using it more for green-field development where I work.

What exactly does "Groovy" offer that another JVM based language doesn't? Am genuinely interested.

Re: Lombok makes Java cool again

#220

Post by int_19h »

pjmlp wrote: post #194
int_19h wrote: post #137

Earlier quoted context omitted.

C++ circa 1995 was a lot more like Java with manual memory management, really. Templates were a rare sight, STL was not yet a thing, and it was still considered an impure OO language rather than multi-paradigm.

STL wasn't a thing, but MFC, OWL and ATL surely.

These were also closer to Java libraries of late 90s in design. Even ATL mostly used templates to optimize (using the curiously recurring template pattern, usually).

Qt was also born in that era, and look at how strikingly similar its standard library is to Java's in many cases, and how unlike STL and Boost.

Post reply on HN