#"Lombok Functionality Explained"

1 messages · Page 1 of 1 (latest)

livid patrolBOT
#

@magic pendant has a question:

.jjsd.

What does lombok do?

#

<@&987246399047479336> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
What does lombok do?

Lombok is a Java library that helps reduce boilerplate code by automatically generating common code such as getters, setters, constructors, equals, hashCode, and toString methods. This allows developers to focus more on the actual logic of their code rather than writing repetitive and mundane code.

Some key features of Lombok include:

  • Annotation-based: Lombok provides annotations that can be added to Java classes to trigger the generation of code at compile time.
  • Getter and Setter methods: Annotations like @Getter and @Setter can automatically generate getter and setter methods for class fields.
  • Constructor generation: Annotations like @NoArgsConstructor, @RequiredArgsConstructor, and @AllArgsConstructor can generate constructors with no arguments or with specific arguments.
  • Equals and HashCode methods: Annotations like @EqualsAndHashCode can generate equals and hashCode methods based on the fields of a class.
  • toString method: The @ToString annotation generates a toString method that includes all fields of a class.

Overall, Lombok simplifies Java development by reducing the amount of boilerplate code that needs to be written. However, it is worth noting that Lombok modifies the bytecode of compiled classes, so developers using Lombok should ensure that their build tools are set up correctly to handle this modification.

- AI generated response
livid patrolBOT
#
TJ-Bot
Share the downsides of using Lombok. Include how it hijacks and how any version increase of java can break Lombok completely

Lombok is a popular library in Java that aims to reduce boilerplate code by automatically generating getters, setters, constructors, and more through annotations. However, there are several downsides to using Lombok.

One major drawback is that Lombok "hijacks" the compiler during compilation. This means that the actual Java source code does not contain the generated methods, as they are added by Lombok at compile time. This can make code harder to read and maintain as developers may not immediately see all the methods available in a class.

Another downside is that any version increase of Java can potentially break Lombok completely. Since Lombok relies on compiler internals and specific annotations to generate code, changes in Java versions can lead to compatibility issues. This can result in unexpected errors or behavior when upgrading Java versions without also updating Lombok.

Additionally, there may be performance implications when using Lombok due to the additional processing required during compilation. While these performance impacts are generally minimal, they can add up in larger projects or with frequent use of Lombok annotations.

Overall, while Lombok can be a useful tool for reducing boilerplate code in Java projects, it's important for developers to be aware of its limitations and potential drawbacks before incorporating it into their codebase.

- AI generated response
lunar crow
#

@magic pendant Have you checked their GitHub, yet?
Usually there's a (big) README explaining you what it does

magic pendant
#

I was just asking generally I wasn't really looking to apply it anywhere also I didn't know how to close this :3

lunar crow
tribal dune
#

think of it as a Java++

lunar crow
#

also I didn't know how to close this :3
/help-thread close

tribal dune
#

it hooks into the Java compiler and "adds features" to Java

magic pendant
livid patrolBOT
#

Closed the thread.

patent sigil
#

i think the "project could break if you update Java, but not lombok". that applies for many dependencies

#

if you go from Java 21 to Java 23, chances are some dependencies may break, forcing you to upgrade

#

it even applies to core systems, like build tools. if you upgrade Java, you may have to upgrade Gradle aswell

#

you may need to upgrade your IDE to support the new features

#

Lombok only gained this heat once Java started supporting the tooling that Lombok provided

#

so its more of a "its not worth using" now. but even then, lombok does still provide some good tooling for things that Java doesnt support yet

#

all of this "lombok hacks the compiler, its bad" is silly. many big frameworks hack something, and no one complains about that. but since its the compiler, everyone leans on "if Java updates, lombok breaks"

#

as if that doesnt occur for many other systems we use

#

lombok is just part of the environment, and yeah, when you update Java, chances are you may have to update the environment

#

this is spoonfeeding the AI to give an answer that is wanted

#

"share the downsides, include [things i dont like about lombok]"

tribal dune
patent sigil
#

ya'll gotta dislodge yourselves from lomboks butt 😬

patent sigil
tribal dune
#

"think of it like kotlin" is pretty accurate though

patent sigil
#

and they get showered with personal vendettas

#

it aint even just click, its about everyone here who hears of lombok

#

lombok was a powerful tool, still is. yeah, Java has made it redundant in many areas. but the whole "if java updates, lombok breaks unless you update lombok"

#

that aint just lombok. its other big systems, which arent shunned

#

the hate seems vengeful, simply because it "hacks the compiler". but to what extent does it hack? really not that much, compared to some other tooling out there

#

really seems like a "once you get big, you become a target"

#

no one complained about Lombok to this extent before records were introduced

#

yet the lombok issues started with Java 9. yet no one really complained, it was just worries. now "lombok is cancer"

#

its wild

#

Java 16 came around, and Lombok became the poster-child of hatred

#

but the reasons are insane

#

its a bandwagon situation

#

TL;DR:

when you update your language, chances are you have to update your environment. not just lombok, but other systems

#

if thats where the hate centralizes, its time to rethink

#

as for functionality, lombok is still amazing when it comes to Jackson integration

iron sedge
#

When Java updates, it's not a fact that you'll have to update all of your other stuff. Only things that dive deep into the jdk code or use a lot of reflection are likely to encounter compatibility issues, because otherwise the stdlib api is rock solid and most of the libraries still have Java 8 as their compile target. For Lombok though, it's pretty much a guarantee. I don't think there was ever a Java release that was supported by an old Lombok version out of the box.
Also, Java really haven't made it redundant. Records are cool, and I appreciate them for what they are, but they are a sad shell of what data classes could be. And other features are just not there.
Lombok is very useful and I can't imagine doing a Java project without it. I dislike not the tool, but the fact that such a tool is necessary, almost as if the things it provides would be a great addition to the language itself. So I simply recommend considering Kotlin for personal projects, which truly makes Lombok obsolete.

patent sigil
#

dont dislike the tool, but the fact that it is necessary

that is Lombok in a nutshell. Java doesnt support all the needs

#

hyperfocusing on the fact that "lombok messes with the compiler" is a pretty bad take. there are tools which do worse

#

would be cool if the language supported it. or even having some kind of API that provides the same (synchronized in Kotlin is not a lang feature, its provided through an API)

#

lombok still has productivity behind it. just seems like theres a lot of hate cause "it hacks the compiler"

#

as long as you keep Lombok up to date, that shouldnt be an issue, because they are keeping on top of their updates

#

and that applies to many tools. IDEs, build tools, etc..

serene crow
#

Most of the hate is excessive, but is not just limited to its demands to retain unsupported uses of the compiler.

serene crow
#
  • Some hate comes from its introductory times when IDE support was nil
  • Some comes from its violation of the idiomatic rules of annotations - that the code should be valid Java in the absence of the annotation processor (so it works with any Java parser).
  • Some comes from the more recent combative demands to continue to use Java compiler features that were never supported behaviour (placing a drag on Java internal development)
  • Some hate is just a difference in personal position on the impacts of Java boilerplate. And this is always going to be subjective.

And Lombok meets a desire, not a need.

Lombok doesn't really add any novel functionality, it just provides a terse language for providing content that we'd otherwise need to write ourselves or generate in IDEs.

There is value in the terseness of the Lombok language. Yes, you don't have to write code if an IDE generates it, but there is a maintenance cost (not just in keeping it up to date, but in the 'woods for the trees' problem of readability).

Lombok is a tooling choice. Once using Lombok you are beholden to their ability to keep that tool up to date with JDK development, or accept a migration constraint (or 'de-lombok' the code) - thus far Lombok has fared reasonably well here.

The pro of Lombok is terseness and productivity. The con of Lombok is the support dependency (and that has proven to be less of a concern than many - including myself - have predicted)

#

Brian Goetz's position (and I think the JDK architectural guidance in general) has generally seemed to be that things that don't allow you to express new things, or that don't help make bad-states harder to represent, are less urgent than the many of the boilerplate issues.

I understand the position, and valuing work to eliminate boilerplate (that only eliminated boilerplate) is always going to mean a balancing act - there's always an engineering budget to consider.

I personally do think more effort is needed to address boilerplate - but I don't think any reasonable amount of effort would completely eliminate Lombok's features.

patent sigil
#

shouldnt need to depend on Lombok, but if you do have to, then it is what it is

#

thats the lifestyle of a software engineer

#

pick your battles