Hard disagree on not using Lombok, at least at my job. When you go into these ancient classes that have tons of methods and surrounded by all these getters/setters/builders, it makes it so much more difficult to parse and work around. Having Lombok clean things up is really valuable and makes code easier to maintain and read. I simplifies things and does a good job of that. Being worried that Lombok will break your app in a future update is a silly reason not to use it. I can agree maybe don't use if starting on a small app or something but it has its purpose.

@actualprogramming

10 ай бұрын

Agreed. I am working on a old project which doesn't uses, it's just difficult to read. And I don't need to see the fluff stuff.

@RochaNahuel

10 ай бұрын

El simplemente a veces ya no sabe que contenido subir

@lukeav6097

5 ай бұрын

I disagree. If you have that many fields in your class there's something wrong with your code. Lombok is the stupidest lirary out there

@yardy88

2 ай бұрын

IntelliJ allows you to search through symbols like field and method names using Ctrl + F12. There you go, you no longer need lombok. Also your classes are too big. Kthxbye

I have been coding Java for more than 15 years I know what Lombok generates. I can create my own builder pattern, to string, equal and hashcode, but why should I? I can have lombok generate those for me. Also lombok makes it super easy to add or remove fields in the model , try doing that with your own builder pattern, to string and equal/hashcode implementation.

@a_cen

10 ай бұрын

I Agree)) Also if u really scared that some new version of lombok generates something bad - cower that logic by tests.

@wardibald

10 ай бұрын

Who debugs a setter anyway? Debug the line below where the value is declared you're going to set, or the method providing it. A setter should remain a setter except in extraordinary circumstances, and Lombok removes the urge of some juniors to put extra logic in it. It may add some complexity, but it also removes some and encourages cleaner code. On entities, it's mostly a matter of EqualsAndHashcode-onlyExplicitlyIncluded and toString-exclude to allow entity equality and avoid cartesian product issues. If a junior doesn't understand these things, Lombok's the least of your worries if they start messing with entities.

@tsalVlog

10 ай бұрын

Java 15 + Intellij makes it unnecessary to force a build pipeline that needs to generate lombok classes. It was great, just like Spring was great when it was needed. Now, it really isn't.

@Dalendrion

10 ай бұрын

@@tsalVlog I'd love to learn more about this.

@m3hdim3hdi

10 ай бұрын

@@tsalVlog is Spring not needed any more? And if yes how do you replace it

Good to know another perspective as well. But personally i feel Lombok makes your POJO/Entity looks much cleaner. Generating using IDE is an option but when you need to update some fields then you have to go through complete class and find the affected areas(eg: toString() or equals()). Moreover, Lombok is not a complex library so it's very easy for new Developers to understand and start using it. Official documentation explains everything so well :-) UpVote for Lombok👍

@lukeav6097

5 ай бұрын

It makes it cleaner while at the same time adding complexity and extra logic to your code

If you want to have full control over your code move to C++. Java is all about improvement, abstraction (SOLID by the way) and easy implementation and iteration. Instead of rewriting toString or equals when something changes you can rely on a popular dependency to handle it for you. If we go on with the full control, switch from spring boot to handling sockets yourself, we rely on dependencies and nothing wrong with it generally.

@lukeav6097

5 ай бұрын

No need to move to c++ and he's not saying do that. But adding hidden logic and complexity to your code avoid writing a few lines code is stupid AF

@halavich9672

5 ай бұрын

@@lukeav6097 Stop using Spring then, KEK

Honestly, never get bored watching how you teach, really enjoy it

You need to remember to regenerate the methods every time you add or remove a field in any class, which is a huge pain in the ass. As for records, my company is still on Java 8/11, but can you even annotate the fields properly for things like JPA or Jackson?

So using lombok helps in reducing redundant code and static ones like getters, setters, constructors, etc. And it also helps in fast development. Now on the other hand you raised some very valid points. At the end of the day it really comes down to who is using lombok if you have a team of juniors without anyone with experience reviewing what was used and its impact then its better to remain with the normal approach. Moreover, when managing a huge project lombok is a huge help, specially for boilerplate codes. At least that's my way of seeing it 😅

I love Lombok though 😅. But thanks for the insight always man🙏🏽🙏🏽

I think that simple annotations like getter setter noargs and allargs are simple to understand, and it saves a lot of space in the class, especially if you have like 10 or more properties.But as you said, some other annotations can be dangerous so you must be careful with that.

@momokoko9864

4 ай бұрын

I agree, I only use those you mentioned and avoid using @tostring or even @Data xd

we don't NEED most things, lack of lombok, spring boot, maven, libraries... you can still make a finished product. BUT they shorten the time we have to work and make us happier.

I have been coding Java for a year. Luckily, my team lead has concern about all those abstractions to make sure that new comer will be easily understand what’s show in the codebase and contribute to team early enough. It annoys that you have to write constructor every times until record comes in to play.

I'm a beginner Java developer, and I starts my familiarity with the lombok less then 3 month ago. This is really useful thing at the first look, but i don't now how it exactly works under the hood. Anyway i use it for my pet-projects and this is really conveniently :)

Assalamualaikum, I think Lombok can be useful when you need to change for instance a POJO a lot. It's better earlier on but maybe when refactoring after implemention you could auto generate.

@Runnable19

10 ай бұрын

I agree

@tsalVlog

10 ай бұрын

For POJOs / protocols that change often, I do agree Lombok could help.

Generating toString and hashCode with an IDE will be as dangerous as lombok's annotations if you don't know what are you doing.

Hi Amigoscode ! I really enjoy your videos on programming in Java. I was wondering if you could make a video about asynchronous methods. I've been able to use them successfully, but I sometimes have trouble creating efficient callbacks. My callbacks can be long or be executed after the instructions I need. Thanks for your time!

I agree that using the IDE to generate these codes is a good way to know what's going on and even makes it easier to debug the code, but I'm also in favor of using Lombok for simple things like Getters, Setters and Constructors.

I like Lombok because is simpliest, but I agree with you too about the dangers and it is important to maintain control and knowledge of your own code.

I recently discovered Lombork a year or 2 years ago. Since then, it has saved me a lot of time. Having to reduce boilerplate code it's the best. I think there is so much benefits when compared to the dangers of using it. For me the feeling is almost the same as switing from JEE to Spring Boot.

You are a great teacher. I have a question for you. Which course of yours would you recommend to me, I know a bit of java, but I want to learn Spring Boot, so I can learn to create my own API's with some backend? (i'm a front end developer). I want to be fullstack.

As usual, the difference between youtube coder and professional coder is conspicuous

I quite agree to use lombok. Is really useful however like you say we need to be careful when is applied it in entity classes.

I think if you want Lombok better to switch to Kotlin. Lombok is not silver bullet for the class creation. Unfortunately there are a lot of the projects where all decisions were made before we came on the project so all we have just to work with what we have

OMG!! I thought this day would never come. Please, I have more reasons to use Lombok!

I just want as little boilerplate code as possible. So I love Lombok and will use it. Don't see no danger or steep learning curve for annotations here. Pretty clear.

Completely with you - and it is not only about the Lombok - usually there are plenty of different annotations where the same annotation might even be interpreted by multiple libraries and frameworks in the same project. Unfortunately Lombok is used in all recent projects where I am involved. People only look at the number of lines they need to write while that is not the problem and not what is holding back and hindering development. I have seen classes with more annotations than regular code lines and then you are not coding any more - you are writing configuration files! - And the pitty of configuration files is that you do not see what is actually done until you look it up in documentation or some (decompiled) classes. On the other hand, looking at the code always tells you what is actually done in the first place.

Should we use Jackson library then? or create your own mapper?

I've worked for a few very big companies and all of them use lombok. You can't always use records, nor is it always the best option

Valid reasons but I doubt they would stop anyone from using it. More preferential than a need.

Which icon theme do you use?

Hey, could you make video about Kotlin and how it might impact java popularity ? I'm a java developer with close to 4 years of experience and quite recently I've started learning Kotlin. Quite frankly I become more and more convinced it is the future. Have you given any thoughts to that ?

what about adding @Data which inside include base annotations ?

I thought lombok means lombok island in Indonesia where i live And i thought you just don't need the things in here 😂

@nurhadi-dev

10 ай бұрын

there are some terms in java programming language related to Indonesia. java itself and lombok, are island names in Indonesia. and also, Jakarat Enterprise Edition (JakartaEE, formerly JavaEE) is capital city of Indonesia.

Yes I use Lombok.. And hard disagree on not using it.. I think if you know what you're doing, it makes the codebase look very clean. And the arguments for dependency and learning curve are applicable to any framework. Ultimately, if it's worth it.. You accept the dependency and learn the intricacies.

Well the debugging can be a reason to avoid lombok but it for last unless needed. Do use lombok effectively till it does not cause trouble.

I know it's easy to generate with the IdE but I just like Lombok. I find it much simpler

As we lean into AI-assisted coding, the clarity and conciseness of our codebase become crucial. Lombok, by trimming boilerplate, ensures we're maximizing AI's context window, making a strong case for its integration in modern development.

Thanks sir for making useful videos for us. But I request you very respectfully to work in a project in spring boot having at least 6 entities/tables using spring boot in the back end and React/Angular/Next in the front end

I tried the simple calculator program in Android studio but I can't use the I'd of the button switch case in the onClick method how should resolve this error

what do you think about mapstruct?

Hey , Amigoscode nice video! I was wondering if I could help you edit your videos and also make a highly engaging shorts out of them.

I think it's acceptable to use Lobmok in small projects or in demo projects for learning. in case to not trash in entity classes. so you can see clearly business logic

I hated Lombok when I was using Eclipse because you need to do extra configuration but after I switched to IntelliJ IDEA then I started to like Lombok as you don't need any extra configurations as it just works.

Hi Amigo! 👋 i tried to sign up for the fullstack course and subscribed to get the pdf and the discount, i even confirmed my email but tge second email was never sent to me. Can you please help?

1. for debugging purposes you can just 'delombok' and rebuild, then go back to using lombok, it still reduces boilerplate, and prevents you from having to add/delete code over and over in case ur class changes. 2. if an annotation can be dangerous if not used properly, then you simply shouldnt be using it if you arent sure what it does, but it works the same way for manually created code. 3. i dont get how using annotations like '@Getter' or 'AllArgsConstructor' adds complexity for your team, its very straightforward, and you dont even need to know what is annotation processing to use it. the only explanation i can possibly see is someone not knowing what getters/constructors even are, but in this case i highly doubt its someone who should be hired in the first place.

The problem with records is that as records are inmutable by default then it does not give you setters, and is equally tedious to recreate the entire object just to change one of the fields, So i think that for that reason people still stick with lombok. Kotlin by other hand do the things more elegantly with data classes

hi, like your videos... can you make video on pluggins on IntelliJ that you recomend please

I agree with your points, since all of that can be generated by the IDE - i don't see any real benefit. Anyway at the end of the day it depends on the team decision.

Thanks. What's the theme for IntelliJ please.

@Amigoscode is vs code enough for u as a spring java developer comparing with ideaj?

@dabeatfan

9 ай бұрын

this is ideaj i see

yes you do, development time writing boilerplate goes down way too much to not use it

I would give edge to Lombok. Unless you have some specific reason not to use it which I cannot think of. I am being using for more than 3 years and had no issue.

Oh yeah, toString with ManyToMany association is a tough thing 😂 When I found that the reason of stack overflow was a generated toString method by Lombok - I really didn't know what to do - to be mad or to laugh. But anyway, in many cases Lombok is helpful, just need to know some "dangerous" features. Thank you for alternative view on Lombok in this video.

Using lombok adds additional complexity into setting up your text editor to deal with it. It's easy enough with IntelliJ, and I assume vscode, but once you start going into more advanced editors like neovim, it is a problem I would much rather not deal with. A much better alternative I would use, even if it goes all good object oriented programming practices, is making those fields public instead, since lombok pretty much effectively does that for me anyway.

I believe Lombok works well for 90% of the cases, but for instance I worked in a project that needed some fields for databases optimisations that made it not enjoyable experience using Lombok. At this point I believe you should give a try to kotlin that removes these verbose parts of Java

This video got me thinking. Do I really need Lombok?

I totally disagree with the title and the message transmitted on the video itself. ofc lombok is something don't you need, is only a way to avoid boilerplate code and do the things quick, also have in mind there's to many companies which still stuck using Java 8/11 (in general versions minor than 14 which was the version who included records), so records is not an option. In general correct me if I'm wrong, but I think the message you tried to spread in this video was more like "don't use a tool if you and your team doesn't understand the implications well", if is this the case atleast the words choosen for this purpose was not the right ones, from my perspective all the reasons exposed on the video can be summarized with the unfamiliarity, and personally i think there's not much extra work on read a little bit of the docs of lombok to be familiar with it. (And sorry if my comment looks "aggresive" was not the purpose on my comment, but I didn't find another words to express my opinion).

@GuihVicentini

10 ай бұрын

I understood the message more like, don’t use a library that you don’t need. I myself, a lazy programmer, love to use libraries to help me do things, but sometimes, for small things, these libraries and the learning curve can get on the way and delay things instead of speeding it. This is what I understood from the message, or how it applies to my experience. Nevertheless, the overall situation should be evaluated and maybe the learning curve and hassles in the beginning will pay off in the future Cheers!

When Java implements something like properties in C# maybe then I won't use lombok. Until then I absolutely will.

You enter the videos by saying "Es-salamu Alaikum". I am being so happy

Maybe a compromise would be to only use it when you need a builder?

you can use chain in setters instead of builder

I agree with your point to some extent. But isn't the purpose of using libraries the same as why we use frameworks? Because if developers were to abide strictly with your logic on this subject, they'd have to build their applications from scratch implementing all functions and features. This will be the only guarantee that a developer would have complete visibility and ownership of his source code. I guess at some points we need to find a middle ground and just do our best to understand the libraries we use. But I'm just a Java student at this moment. Perhaps my point of view may not be as low-level as senior devs. What do you think about my pov?

Love Lombok Builder annotation

I would said half lambok just for getters, setters and two cuncstroctor. Because project is in starting mode is just frustrating adding in cuncstroctor and geters and setters.

awesome video, as always! but you saying that @ToString @Getter @Setter, and more of boiler plate annotations are bad, and using `record` isn't the same thing? I mean, you got a lot of things being auto generated for you as well, like overriding toString() and such.

Pls give a video how the interview happend for Java developer in uk

Lombok 'toString' did me wrong on many to many relationship. I spent hours trying to figure out what was wrong.

hi I'm Fresher am learning Java , I graduated this year i don't Know what to do Development or Dsa From Which One I Learn Can you Please guide me. I want Job as soon as possible and am learning Java . Can i Continue Java or start development.

@Data is a go to annotation that I use with Lombok

Assalamu Alaikum. We use Lombok just to reduce boiler code

And what's about writing plain Java code instead of using Spring or any other frameworks?😊 Where's the borderline?

I always go from scratch with the core domain since I don't want it to depends on anything. On outer layers, lombok is very handy

at least for using getters/setter don't think it's problematic that you can't set break point within, makes code a lot less messy

I think its a 50/50. To keep it simple, maybe you want to remove 3 fields from a class or rather add. With Lombok the getters and setters are injected upon declaring the instance field. You need a few seconds more of typing if you don’t have lombok - to attach those to getters and setters hahaha

Honestly it depends on your usage. Everyone has their own favorite after all

Of course at first sight lombok can be useful, but all of these things IDE can generate, and classes that have getters and setters for all the fields shoud have only that and nothing else. if you have some POJO class its clear to have fields on top, getters and setters on bottom and contructors in between. But i have been coding for one and half year and i didint even got my first job so this is just my point of view. And also lombok is another dependency that you have to know and maintain.

I think that to use lombok or not depend of the needs and expertise level in the development of the any proyect. You can make e mistake in the use of toString using lombok or not.

Lombok's interaction with other libraries is not always effective, and the reasons for its ineffectiveness vary. For instance, when mixing Lombok with the Jackson Library, adding the @Data annotation is necessary to avoid errors. However, using @Builder alongside XML property annotations can lead to issues. Furthermore, attempting to use @SuperBuilder to mitigate constructor impacts, but it is found that @SuperBuilder cannot be used with elements in collections. See? These hurdles arise due to Lombok, which adds unexpected learning curves to what initially appeared to be convenient features. These complications can be avoided.

Hi guys. In addition to all the reasons listed in the video, - I would also add that it's more difficult to debug with Lombok IMHO

Im from the old school, I like to click source -> generate getters and setters on eclipse.I don't know it feels like is the way to go

@sidof8065

5 ай бұрын

🤣

I'd argue that Lombok is no more "magical" than Spring Boot's autoconfiguraton magic. OTOH, probably easier, since the generate class source is easy to find and read since it's generated by an annotation processor up front.

As a Java dev for 10 years, I use Lombok for POJOs (like DTOs) but never for Entities.

Generally I'm into Lombok more than against. Those cons were good and pointing crucial areas where You need to pay attention how You use this library. With one statement I won't fully agree which are problems with debugging and testing the code that is generated by Lombok during compilation. The adventage of the Lombok is that You can override each peace of code it generates by Your own explicit implementation whitin POJO/Entity. So in case of more additional logic has to be perform, or simple debuging, in a for (stupid) example: builder() method witin @Buiilder annotation's generated code You can explicity declare this method and perform/validation this logic.

Bro, do you know any good bootcamp school???

While these are all valid points, the idea of Lombok is to reduce boilerplate code. Using IDE tools to generate the same code will result in, well, more boilerplate code, longer code files which can be difficult to read when you have large POJO classes. He says that Lombok requires extra IDE tooling, but if you generate this code using IDE tools, well, you require that extra tooling, too, so the point becomes moot. And if you have all the getter/setter code written manually, you will probably still require IDE tooling to refactor it when you change a property name. IDE tooling is not a bad thing. It is there to simplify tasks, which is the point of developing itself. In the end, using Lombok or not is a trade off that needs to be considered on a per project basis. I totally agree with his points on the Equals and Hash Code annotations. For the moment I only use Data, Builder, and the constructor ones (and these last ones sparingly).

Which IDE is this

Lombok is kind of a standard for my team. No one uses getters and setters these days.

1- I do not think that Lombok has a steep learning curve at all. 2- I think it is a dependency very worth adding. 3- equals and hashcode are dangerous but they are as dangerous if someone implements them manuallly if they do not know much about them. 4- You can make the Intellij and some other IDEs generate most of the things for you and you may have better flexibility to change them but how many times do you want more flexibility? It is also pretty easy to achieve the same flexibility by implementing what you want manually when needed 5- Having so much boiler plate code will make it very difficult to tell from the first glance whether this is indeed boiler plate standard implementation (the one that can be auto generated) of the Builder, getters, setters, etc or it is a different implementation because our use case needs that. If you use Lombok and I see that you implemented the setter method for one of the attributes, it will catch my eye immediately. This wont be the case though if you have 10 setters without Lombok I have not used Java for 3 years now (kinda) but I think all of what I said is still applicable

Java Record class instead?

I like and dislike Lombok. One of the things I really appreciate is the object instantiation using @Builder which can limit the use of setting each field and the boilerplate. I know that we can implement the pattern, but it's a lot easier to use annotations for simplification.

Whilst we are talking about maintaining control of your code, have you seen springboot!!!

The only potential problem with lombok is in large projects where this mountain of potentially useless code slows down the buid a lot. Leaving that aside you obviously have never worked under QA control, good luck testing all those methods manually and doing 80%+ coverage, even doing an abstract test is full of exceptions that have to be handled manually. Instead just configure lombok for it to add @Generated automatically and skip a ton of work. Most importantly, is it easier for lombok to give you problems or for updating a model to forget to regenerate all the methods? in my opinion the second one

You don't need lombok but it's good to have

you are my GOAT but i think this video you posted for the sake of being active on social media

I think that we must use Lombok ONLY on the stage of REFACTORING. When everything was completely tested.

Just like all other magic code out their (serialization looking at you) lombok should be used sparingly because of the lack of visibility. Also keep it at a tankship size distance away from JPA entity objects. The java bean specification that JPA leans on comes from an era when distributed objects where thought to have been the saviour in terms of cutting down on complexity. It never did that job and nowadays you shouldnt use mutable objects anyhow. Hibernate does not care about you getters and setters anyway to yeet them if you dont expect to switch JPA provider any day.

debugging setter is working with lombok and intellij

Just switch to kotlin and still having features of the JVM

Whether agree or not of using Lombok, I feel better to use old school ways to generate the mutator / accessor / constructors.

"The best code, is code never written" So this is the reason, why some developers avoid boilerplate code. One way to do this is using lombok. Getters and Setters are not the problem.

I don’t really like Lombok but I have more reasons for that than the ones provided in this video. Lombok makes creating POJO classes easy - that’s a fact. But IMHO it makes it too easy… If you had to write all those getters and setters manually you would probably think twice before doing so. The approach of not using Lombok encourages to put some logic to the entity class, expose real methods to interact with it and hide the inner state. All of that will eventually happen because people are just to lazy to write boilerplate code (and that’s great!). This naturally leads to actual OOP programming and cleaner architecture. If you limit your class to be the data structure why just not make every field public? The reason why we have such a concept like POJO is because old persistence frameworks relied on having property accessors but this is a problem of those frameworks. We should think of methods as a way for objects to interact with each other - not as a way to achieve persistence. For this we have a mechanism of reflection which will be used no matter if the persistence tool reads the inner state field by field or uses getters & setters (which have to be introspected anyway). Lombok promotes anemic domain model. If the innards of the object are exposed, the domain logic ends up being written in services moving us back to structural paradigm. Services are off course an indispensable part of domain model but in many cases they are overused. Think of all the „Processors” and „Do’ers” you see everyday in your company’s codebase.