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.
Lombok Saved My Ass
31–40 of 60 posts
Re: Lombok Saved My Ass
#32The 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?
Re: Lombok Saved My Ass
#33Earlier 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.
Re: Lombok Saved My Ass
#34So 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.
Re: Lombok Saved My Ass
#35While 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…
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
#36Earlier 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.
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
#37While 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.…
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
#38Earlier 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.
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
#39OutputStream out = new BarOutputStream(); in.transferTo(out); if (out != null) ... Can someone explain how `out` could possibly be null here?
Re: Lombok Saved My Ass
#40So 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.