Live data from Hacker News

Lombok Saved My Ass

devolution.tech

41–50 of 60 posts

Re: Lombok Saved My Ass

#41
post #37

Earlier quoted context omitted.

> (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 gi…

"It's not practical to define a separate class for every query."

I'm not sure it's really impractical, at least in my experience. You may not need a separate type for every query, as long as you are willing to have some queries select a few more columns than you actually need right now; and you don't need separate classes, just separate interfaces, which makes the amount of extra code you need smaller.

Re: Lombok Saved My Ass

#42
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's @Data (which is probably 90% of why people use it) is essentially equivalent to Ruby's attr_accessor. It's not "magic" so much as small and useful modification to the language.

Re: Lombok Saved My Ass

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

The concept of records already exists in other languages, including JVM languages (like Scala and Kotlin). The fact that they're immutable and final is important. If they weren't, there would be subtle bugs caused by that. Scala actively recommends that case classes not be extended precisely due to this fact. Overriding methods for equality and hash code make it such that these classes can be used as keys in maps or entries in sets.

Re: Lombok Saved My Ass

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

If you want an object with a few getters and setters, just make a class.

This proposal is to remove the boiler plate of creating immutable objects with value semantics.

Re: Lombok Saved My Ass

#45
post #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.

So the code is inflated because the machine does the code repetition for you. The structure of your program is not getting better I think. I do not argue against annotations but in this case, if there is such a simple thing as try with resources, just use it. If your code is sprinkled over with annotations like this it is hardly getting more understandable. From my experience, a single annotation comes often in packs.

Re: Lombok Saved My Ass

#46
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…

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.

Re: Lombok Saved My Ass

#47
post #46

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…

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 depends on how large work you do and how much experience you have. Readability is not just how much code you have, it is about using consistent patterns to solve your problems. Readability is how fast and how safely you can move around the code to understand how it works at any level of complexity.

I have 17 years of experience working with Java commercially.

I am blind to getters, setters, builders, and bunch of other stuff. It does not bother me, I can recognize patterns immediately and just ignore them.

What bothers me is when I don't trust my IDE to find all uses of something because some jackass decided to add Lombok to the project and now my IDE does see all code exactly as it will be running.

This is much more of a readability fail.

When you make global refactorings on an application that has over a million lines of code it is absolutely crucial you can trust your IDE to find all uses of something.

Re: Lombok Saved My Ass

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

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 (silly).

Now you are putting @Data to further muddle the problem which basically does not exist.

Re: Lombok Saved My Ass

#49
post #27
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…

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.

Re: Lombok Saved My Ass

#50
post #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.

But that just isn't true. Neither finally-block appends a try-block that initializes the stream that it null-checks.

If the `in` stream init throws, the entire try-block isn't run at all. If `out` stream init throws, the following try/finally block isn't run either.

Lombok's docs get this wrong too. Unless I'm going crazy.

Post reply on HN