Live data from Hacker News

Lombok Saved My Ass

devolution.tech

31–40 of 60 posts

Re: Lombok Saved My Ass

#31
post #17

Earlier quoted context omitted.

I have the complete opposite point of view. I never used @Cleanup but at least the @Data annotation makes it much more readable IMO. There is tons of boilerplate in a simple Java bean, so when you have 3 pages of getters/setters, equals, hashcode, toString etc... and someone introduces something hacky it doesn't jump out at you. To be fair, it doesn't have to be a hack, but it's doing something weird that's unexpecte…

> but at least the @Data annotation makes it much more readable IMO. Record types for Java are being worked on, and we should be getting them hopefully at some point in the (near) future.

Records are strange feature. They are immutable, they can't be abstract, they can't extend, they have implementations of some methods. I don't need anything of that. I just need short syntax to declare property with trivial getter/setter and that's about it. This is strange proposal.

Re: Lombok Saved My Ass

#32

The irony of people telling me that they don't appreciate Spring or Hibernate for the magic behind the annotations that they don't understand, to then turn around and drag in Lombok. Also, if you are telling me you don't like to write getters and setters, does that mean you are not using an IDE? _Sure_, it's a little cumbersome to write them, but not a lot?

It's easy to write them. It's hard to read them. Say I have a class with 20 properties, it means 40 methods. Now one of those methods not trivial and rest are trivial. How can I quickly find out? I can't. Getter is 4 lines, Setter is 5 lines, 20 pairs is 180 lines of nothing.

Re: Lombok Saved My Ass

#33
post #17

Earlier quoted context omitted.

I have the complete opposite point of view. I never used @Cleanup but at least the @Data annotation makes it much more readable IMO. There is tons of boilerplate in a simple Java bean, so when you have 3 pages of getters/setters, equals, hashcode, toString etc... and someone introduces something hacky it doesn't jump out at you. To be fair, it doesn't have to be a hack, but it's doing something weird that's unexpecte…

> but at least the @Data annotation makes it much more readable IMO. Record types for Java are being worked on, and we should be getting them hopefully at some point in the (near) future.

never soon enough!

Re: Lombok Saved My Ass

#34
post #30

So you introduce a new library that does "magic" instead of using one more line? To me this is the opposite of good code. Let alone that the given example would probably live in some library code anyway.

Lombok is a compile time library that doesn’t do any magic but replacing an annotation with fragments of code. It feels more like using macros which exist in many languages. And it helps in keeping the code readable and DRY.

Re: Lombok Saved My Ass

#35
post #11

While I can understand why somebody would want to use Lombok, this is actually very misguided. If you want to program in better language, just go and use better language. The most important strength of Java and basically the only reason it is being used is that the code is simple to understand (simplistic!), everything is easily trace-able and debuggable and that you get fantastic tools that know everything about cod…

I somewhat agree with you and reluctant to use Lombok. But it's easy to say "use better language". Kotlin is too different. Java is actually pretty good right now and the only thing I really need is property declaration.

Actually I was thinking about different approach last year, didn't get to implement it. Something like declare abstract class with getX() setX() methods and let library to implement missing methods. Now it's one line per method, no trivial code and able to generate other nice things, e.g. I really want to have fast initializeable properties (like getX throws exceptions until I call setX).

Re: Lombok Saved My Ass

#36
post #17

Earlier quoted context omitted.

I have the complete opposite point of view. I never used @Cleanup but at least the @Data annotation makes it much more readable IMO. There is tons of boilerplate in a simple Java bean, so when you have 3 pages of getters/setters, equals, hashcode, toString etc... and someone introduces something hacky it doesn't jump out at you. To be fair, it doesn't have to be a hack, but it's doing something weird that's unexpecte…

> but at least the @Data annotation makes it much more readable IMO. Record types for Java are being worked on, and we should be getting them hopefully at some point in the (near) future.

> Record types for Java are being worked on, and we should be getting them hopefully at some point in the (near) future.

Just 2 days ago JEP 359 [0] was marked to be fixed [1] in Java 14 (as preview feature)!

[0] https://openjdk.java.net/jeps/359

[1] https://bugs.openjdk.java.net/browse/JDK-8222777 (see "History")

Re: Lombok Saved My Ass

#37
post #11

While I can understand why somebody would want to use Lombok, this is actually very misguided. If you want to program in better language, just go and use better language. The most important strength of Java and basically the only reason it is being used is that the code is simple to understand (simplistic!), everything is easily trace-able and debuggable and that you get fantastic tools that know everything about cod…

I somewhat agree with you and reluctant to use Lombok. But it's easy to say "use better language". Kotlin is too different. Java is actually pretty good right now and the only thing I really need is property declaration. Actually I was thinking about different approach last year, didn't get to implement it. Something like declare abstract class with getX() setX() methods and let library to implement missing methods.…

> (like getX throws exceptions until I call setX).

Oh, the wonders of using widespread mutable state! Did you remember to call this other method here before trying to call me??? No?!?! Oh, here's a nasty Exception for you then.

Re: Lombok Saved My Ass

#38
post #37

Earlier quoted context omitted.

I somewhat agree with you and reluctant to use Lombok. But it's easy to say "use better language". Kotlin is too different. Java is actually pretty good right now and the only thing I really need is property declaration. Actually I was thinking about different approach last year, didn't get to implement it. Something like declare abstract class with getX() setX() methods and let library to implement missing methods.…

> (like getX throws exceptions until I call setX). Oh, the wonders of using widespread mutable state! Did you remember to call this other method here before trying to call me??? No?!?! Oh, here's a nasty Exception for you then.

It has nothing with mutable state, actually. I can use this approach with immutable state as well. It's just another value "uninitialized" for property. Like `null` but throws faster (and potentially separate from null, because null could be a valid value).

I'm using it for SQL queries. My query returns subset of some column set. It's not practical to define a separate class for every query. So all queries for the given table returns the same class representing all columns in a given table. But if one method returns subset of those columns, other columns contain uninitialized value and should not be read. Any attempt to use uninitialized value is a bug and must be caught as soon as possible.

Re: Lombok Saved My Ass

#39

OutputStream out = new BarOutputStream(); in.transferTo(out); if (out != null) ... Can someone explain how `out` could possibly be null here?

In the article, the if check occurs in a finally clause. So the code would execute even if the constructor threw an exception. Hence the need to null-check it first.

Re: Lombok Saved My Ass

#40
So I've my self used Lombok but I've been using Kotlin lately. IMHO Kotlin if far far superior in terms of how it provides appropriate constructs that are patches to a stale language (hopefully new release cycle fixes it).

So far I've observed with libraries like Lombok there is a smaller community (compared to language community) that vets the idea; and the features are opinionated to that particular community. Which results into fragmentation; just as example https://immutables.github.io/ and https://github.com/google/auto are two libraries providing features like factories and immutable value classes. Then you get articles like https://codeburst.io/lombok-autovalue-and-immutables-or-how-... for improving your code.

This in my opinion doesn't hurt as long as you are a small company. But when your code is going to be used across teams with different opinions, and language doesn't enforce a single way to define construct these kind of byte-code mangling ideas fall apart. I've personally people complain about Lombok and they hate it every bit. Doing these constructs at language level removes debate, and unifies how people in larger community. I hope newer versions of Java move fast enough to make something simple like `@Cleanup` a thing of past. I will highly encourage everyone to try Kotlin too; it's almost transparent drop-in with better syntax.

Post reply on HN