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

Lombok Saved My Ass

devolution.tech

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Lombok Saved My Ass

#51

Post by pacala »

lmilcin wrote: post #48
azth wrote: post #17

Earlier quoted context omitted.

> 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.

If you use @Data you say that all fields will be available with getters and setters that will have no other special logic. Why not consider making those fields public then and not bother with @Data?. This is how Java language was designed, then everybody started mindlessly putting getters and setters around private fields to pretend they are private while giving everybody access to do whatever they want with them (si…

hash, equals, toString.

Re: Lombok Saved My Ass

#52

Post by rumanator »

vbezhenar wrote: post #31
azth wrote: post #17

Earlier quoted context omitted.

> 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.

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.

Some people find data transfer objects to be very useful, even fundamental to implement a well architects software project.

Re: Lombok Saved My Ass

#53

Post by rumanator »

lmilcin wrote: post #49
NOGDP wrote: post #27

Earlier quoted context omitted.

How does Lombok decrease reliability of tools?

Lombok creates new code that is not present in the source code. This throws off tools in some cases.

You do have a point, but if a tool is able to parse Java them I believe it is trivial to extend it to support Lombok, which by now is a quasi standard and fundamental component of a lot of java projects.

Edit: why anyone in their right mind would downvote this comment?

Re: Lombok Saved My Ass

#54

Post by lmilcin »

rumanator wrote: post #53
lmilcin wrote: post #49

Earlier quoted context omitted.

Lombok creates new code that is not present in the source code. This throws off tools in some cases.

You do have a point, but if a tool is able to parse Java them I believe it is trivial to extend it to support Lombok, which by now is a quasi standard and fundamental component of a lot of java projects. Edit: why anyone in their right mind would downvote this comment?

Probably because there is enough people that also value being able to always trace the code written by less experienced team members?

Hint: it is in bad manner to discuss voting on HN. Voting is a popularity contest. If you want your comments to be popular try to be pleasing to everybody and if you don't, don't get upset by downvotes.

Re: Lombok Saved My Ass

#55

Post by democracy »

lmilcin wrote: post #47
tuczi wrote: post #46

Earlier quoted context omitted.

Absolutely agree that Lombok increases Java readability. If I cannot use JVM alternatives like Kotlin or Scala (for whatever reasons), Lombok is a perfect tool to help beeing productive. IMO saving one line with @Cleanup is not worth it but if the class doesn't implement AutoClosable, I think it makes code more readable too.

If you absolutely, really need @Data, why not consider making your fields public? I mean, if the only access semantic is going to be exactly the same as public field why have getters and setters in the first place? It just seems dumb to me and not how Java language was designed in the first place. For me it is trying to fix problems of one bad pattern with another bad pattern (now you have two problems). Readability…

This is true as the point of getters and setters is encapsulation, if you totally ignore it there is no real reason to have them at all and public access is a language feature to use.

Re: Lombok Saved My Ass

#56

Post by slaymaker1907 »

lmilcin wrote: post #49
NOGDP wrote: post #27

Earlier quoted context omitted.

How does Lombok decrease reliability of tools?

Lombok creates new code that is not present in the source code. This throws off tools in some cases.

It’s not that hard to just run delombok and then run these tools.

Re: Lombok Saved My Ass

#57

Post by foxyv »

safaci2000 wrote: post #12
lmilcin wrote: 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 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…

I still can't figure it out. Why do people still use auto-generated Getters and Setters instead of just making the field public? What is the advantage of using Beans these days? I've never run into a situation where I wanted my getter/setter to do something other than return/set the value.

Re: Lombok Saved My Ass

#58

Post by NOGDP »

lmilcin wrote: post #49
NOGDP wrote: post #27

Earlier quoted context omitted.

How does Lombok decrease reliability of tools?

Lombok creates new code that is not present in the source code. This throws off tools in some cases.

What do you mean by 'not present in the source code'? Annotation processors generate code before the whole codebase is compiled, any tool can analyse the generated lombok source code, the same as with any other code-generating annotation processor.

Re: Lombok Saved My Ass

#59

Post by NOGDP »

lmilcin wrote: post #54
rumanator wrote: post #53

Earlier quoted context omitted.

You do have a point, but if a tool is able to parse Java them I believe it is trivial to extend it to support Lombok, which by now is a quasi standard and fundamental component of a lot of java projects. Edit: why anyone in their right mind would downvote this comment?

Probably because there is enough people that also value being able to always trace the code written by less experienced team members? Hint: it is in bad manner to discuss voting on HN. Voting is a popularity contest. If you want your comments to be popular try to be pleasing to everybody and if you don't, don't get upset by downvotes.

> Probably because there is enough people that also value being able to always trace the code written by less experienced team members?

You can trace/debug lombok generated code though...

Re: Lombok Saved My Ass

#60

Post by lunias »

foxyv wrote: post #57
safaci2000 wrote: post #12

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…

I still can't figure it out. Why do people still use auto-generated Getters and Setters instead of just making the field public? What is the advantage of using Beans these days? I've never run into a situation where I wanted my getter/setter to do something other than return/set the value.

Mostly just convention, but it's also a more flexible pattern. A public instance variable cannot have public reads, but private writes for instance.

There is also the case of derived properties. e.g.

LocalDateTime ranAt

LocalDateTime finishedAt

getRuntime() { ... }

Post reply on HN