Lombok makes Java cool again • Hacker News Board

Re: Lombok makes Java cool again

#231

Post by vbsteven » Sat, Feb 02, 2019, 8:23 AM UTC

raz32dust wrote: post #215

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 w…

I can see that the dependency injection annotations can be complex for people not experienced with the whole Spring/IoC/DI setup. I have some rules and general guidelines I use for keeping them in check which I can explain in about 10minutes (and have done to team members in a few companies)

Honestly, I prefer to debug with annotations and a debugger over a manually coded configuration class with hundreds of lines of wiring components together.

And for removing the other annotations: Why should I decouple apidocs from my code? They are litterally annotating the source code so it makes sense to have them close.

Stuff like the validators and JSON properties and configuration also makes sense to have them close to the fields that they are about instead of in a separate JsonSerializer class or whatever.

Re: Lombok makes Java cool again

#232

Post by dmux » Sat, Feb 02, 2019, 3:52 PM UTC

zmmmmm wrote: post #223

willtim wrote: post #219

Earlier quoted context omitted.

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

Not the parent, but I prefer Groovy over other JVM languages because: - supports both dynamic and static typing - it works just as well for bash level scripting as it does for full application development. For example, you can use it exactly like an interpreted language (no compilation needed). - seamless Java integration. I know many JVM languages say that, but Groovy actually makes it one of its core features. It h…

The seamless integration is amazing. For a lot of existing Java code, it's as simple as renaming the file to .groovy. In addition to your list, some of our most used features are

- The amazing SQL library - HTML builders (there are XML builders too) - Literal collections (lists and maps)

Re: Lombok makes Java cool again

#233

Post by isbvhodnvemrwvn » Sat, Feb 02, 2019, 6:56 PM UTC

chvid wrote: post #39

berbec wrote: post #37

Earlier quoted context omitted.

Is it not the definition of a JVM language?

Java is by far the most popular JVM language - probably by a factor of at least 10.

10 is a low estimate. I'd say it's more like 20, with Scala dominating the rest.

Re: Lombok makes Java cool again

#234

Post by vorg » Sat, Feb 02, 2019, 10:01 PM UTC

dmux wrote: post #232

zmmmmm wrote: post #223

Earlier quoted context omitted.

Not the parent, but I prefer Groovy over other JVM languages because: - supports both dynamic and static typing - it works just as well for bash level scripting as it does for full application development. For example, you can use it exactly like an interpreted language (no compilation needed). - seamless Java integration. I know many JVM languages say that, but Groovy actually makes it one of its core features. It h…

The seamless integration is amazing. For a lot of existing Java code, it's as simple as renaming the file to .groovy. In addition to your list, some of our most used features are - The amazing SQL library - HTML builders (there are XML builders too) - Literal collections (lists and maps)

> For a lot of existing Java code, it's as simple as renaming the file to .groovy

This causes the program to run in dynamically-typed mode, much sloooower, so why do it? You'd have to add @Static annotations everywhere to get anything approaching Java-like speeds. One of the Apache Groovy project managers has long since wanted to make Groovy statically compiled by default, but that's never going to happen because they're running an unofficial go-as-slow-as-possible in the official upcoming upgrade to Groovy 3.

Re: Lombok makes Java cool again

#235

Post by vorg » Sat, Feb 02, 2019, 10:05 PM UTC

EmpirePhoenix wrote: post #201

mindcrime wrote: post #192

Earlier quoted context omitted.

True, but Groovy is even cooler!

Only for small stuff, if you have a 100k lines project you are absolutely unable to maintain it while staying sane.

Even a 1k line project is unmaintainable when written in Apache Groovy.

Re: Lombok makes Java cool again

#236

Post by zmmmmm » Sun, Feb 03, 2019, 3:24 AM UTC

EmpirePhoenix wrote: post #201

mindcrime wrote: post #192

Earlier quoted context omitted.

True, but Groovy is even cooler!

Only for small stuff, if you have a 100k lines project you are absolutely unable to maintain it while staying sane.

I think you definitely need to approach a 100k line project differently to smaller code (for example declare types more often, static type at least your interfaces and methods, etc) - but it is completely possible to write Groovy in a style that scales to that size and is still maintainable. After all, it can look almost exactly like Java.

On the other hand, it's impossible to scale Java down to the point where it would be sensible choice for what would otherwise be a bash script.

Re: Lombok makes Java cool again

#237

Post by zmmmmm » Sun, Feb 03, 2019, 3:35 AM UTC

pjmlp wrote: post #198

mindcrime wrote: post #192

Earlier quoted context omitted.

True, but Groovy is even cooler!

And slower, as the tricks employed to make Gradle keep up with Maven show.

I think Gradle is mostly implemented in Java. I wouldn't think its speed is limited by the language of the DSL. Although I would guess startup time is longer as it definitely does have to load up groovy in the classpath and initialize all its classes.

Re: Lombok makes Java cool again

#238

Post by ec109685 » Sun, Feb 03, 2019, 6:01 AM UTC

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…

You’d have to spending 192M a year on developers for 1 hour of downtime to cost hundreds of thousands.

Re: Lombok makes Java cool again

#239

Post by ec109685 » Sun, Feb 03, 2019, 6:10 AM UTC

geezerjay wrote: post #180

arcticbull wrote: post #135

Earlier quoted context omitted.

I liked to refer to the genre as MOP -- Magic Oriented Programming. Every ecosystem I've seen go down that route ends up bailing out. A good example of this would be Apple's Cocoa Bindings [1] on macOS that were killed with fire when the iOS APIs were defined, and KVO [2] which is flat out rejected at every company I've ever worked. On the other hand, when built into the language, this kind of explicit but automatic…

> An alternative approach to Lombok would be to think about how the project ended up with so many dumb data classes. Mapping entities to/from data transfer objects is a well established technique, as using dumb POJOs to drive serialzation/deserialization. If you throw CQRS into the mix you can get a POJO/endpoint ratio that is greater than 1:1. Do you want to write bug-prone boilerplate code for all those POJOs you a…

Why bother with getters and setters for a POJO though if it’s all in a project you control? You can always make a property private later if you really need to add behavior to the fetcher.