You DON'T Need Lombok
ฝัง
- เผยแพร่เมื่อ 11 ต.ค. 2024
- Discover the power of clean code, concise code as we explore the pros and cons of using Project Lombok in your Java projects.
In this video I dissect the intricacies of Lombok and showcase alternative techniques to achieve the same results, without adding unnecessary dependencies.
Don't Forget to
===========================================
💯 Subscribe to Amigoscode - bit.ly/2HpF5V8
💯 Courses Available for free here - amigoscode.com...
💯 Join Private Facebook Group and Discord - amigoscode.com...
🙊 Here are the goods for all my videos video 🙊
► Recommended Books
===========================================
Clean Code - amzn.to/2UGDPlX
HTTP: The Definitive Guide - amzn.to/2JDVi8s
Clean Architecture - amzn.to/2xOBNXW
► Computer and Monitor
===========================================
New Apple MacBook Pro - amzn.to/3464Mmn
Dell 27 INCH Ultrasharp U2719D Monitor - amzn.to/2xM3nW1
Double Arm Stand Desk Mount - amzn.to/3aYKKfs
USB C Hub Multiport Adapter - amzn.to/2Jz7NlL
► Camera Gear
=============================================
Sony ILCE7M3B Full Frame Mirrorless Camera - amzn.to/346QIJn
Sigma 16 mm F1.4 DC DN - amzn.to/2wbic3Q
Sigma 33B965 30 mm F1.4 DC DC - amzn.to/39G37Fd
► IDE & Tools I use for coding 💻 🎒
===========================================
ITerm
VsCode
GoLand
IntelliJ Ultimate
Sublime
P.S
===========================================
💯 Don't forget to subscribe | bit.ly/2HpF5V8
💯 Join Private Facebook Group and Discord - amigoscode.com...
💯 Follow me on Instagram | bit.ly/2TSkA9w
❤️ Thanks for watching
#java #lombok #programming
![[LIVE] : ONE ลุมพินี : คู่มวยแห่งยุค (11 ตุลาคม 2567)](http://i.ytimg.com/vi/aTc7-tPYuJM/mqdefault.jpg)
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.
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.
El simplemente a veces ya no sabe que contenido subir
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
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
@@actualprogramming maybe you just need to get better at reading code.
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.
I Agree)) Also if u really scared that some new version of lombok generates something bad - cower that logic by tests.
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.
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.
@@tsalVlog I'd love to learn more about this.
@@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👍
It makes it cleaner while at the same time adding complexity and extra logic to your code
@@lukeav6097 I don't find it complex at all. maybe it's a you issue. In fact, it removed complexity by having less boilerplate code to me. I do stick to only using getters and setters notations
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.
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
@@lukeav6097 Stop using Spring then, KEK
really hard if you are developing minecraft java plugins
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 think some tools are useful but i also think you should stick to those that are worth it. If you use too many tools its also a pain if you want to use those in other projects and also becomes a clutter. I for example never used stuff like bootstrap (HTML styling tool) because it makes your HTML much less readable.
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?
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.
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.
Generating toString and hashCode with an IDE will be as dangerous as lombok's annotations if you don't know what are you doing.
If somebody adds new members to a class with @tostrong annotation, this data could get exposed to e.g. logs without intention. I saw juniors doing it and the reviewing senior didnt saw the annotation in merge request.
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 😅
Honestly, never get bored watching how you teach, really enjoy it
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
I love Lombok though 😅. But thanks for the insight always man🙏🏽🙏🏽
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.
I agree
For POJOs / protocols that change often, I do agree Lombok could help.
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'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
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.
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
I have more than 10 years experience I have never put a breakpoint neither getter/setter or builder, the important part what is outcome after builder or setter. So it just make things complicated (specially it makes hard your pr to read). Anyone who argues otherwise has not worked on a major project
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 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.
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 :)
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.
I know it's easy to generate with the IdE but I just like Lombok. I find it much simpler
Valid reasons but I doubt they would stop anyone from using it. More preferential than a need.
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
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 quite agree to use lombok. Is really useful however like you say we need to be careful when is applied it in entity classes.
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.
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.
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.
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.
Lombok is NECESSARY!!! and is widely know as best practice. Too much boilerplate code to handle is horrible to deal with, in my company we have a lot of tables with more than 50 fields.
I think you may better change your tables to a nosql tables. I think it keeps getting bigger?
Well that is just bad design of the database if you ask me. Have you thought about revisiting your data model design? 50 fields is really too much for a single table in a general OLTP style application. I am always terrified of seeing something like this in old code bases that are and will be too far behind the ecosystem to salvage... better to rewrite and start over again.
As usual, the difference between youtube coder and professional coder is conspicuous
When Java implements something like properties in C# maybe then I won't use lombok. Until then I absolutely will.
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.
Just use the tool wisely. Stick to stuff like only getters setters and maybe some other stuff. Also stick to tools you actually need. If you have annotations that differ with other libraries then your most likely using too many libraries.
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).
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!
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
what about adding @Data which inside include base annotations ?
Could you please do a video on how much real maths actually applies to coding or any computer engineering format.
So much of today's maths feel like endless futile Greek wrangles or meretricious hieroglyphics.
I would be grateful if you share your insight into this matter.
I think I'm gonna have to go with Lombok being better than just generating the boiler plate yourself. It seems like a hassle i mean it is the reason we use spring to begin with. I think that tipped the scale for me. I learned how to write everything in enterprise java without spring but it would be a pain in the ass. Lombok just helps with boilerplate imo
Should we use Jackson library then? or create your own mapper?
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
I got your point, but for me the trade off is positive, so I will continue using it.
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 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?
As a Java dev for 10 years, I use Lombok for POJOs (like DTOs) but never for Entities.
I thought lombok means lombok island in Indonesia where i live
And i thought you just don't need the things in here 😂
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.
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
OMG!! I thought this day would never come.
Please, I have more reasons to use Lombok!
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.
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
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.
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
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.
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
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.
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.
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.
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 ?
Honestly it depends on your usage. Everyone has their own favorite after all
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?
yes you do, development time writing boilerplate goes down way too much to not use it
@Amigoscode is vs code enough for u as a spring java developer comparing with ideaj?
this is ideaj i see
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).
I am a senior java and kotlin developer. And I see more cons. And the few pros become less relevant with latest java features.
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 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.
And what's about writing plain Java code instead of using Spring or any other frameworks?😊 Where's the borderline?
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
do not understand how people compare lombox with spring. spring is a design for general approach, where you write services, components, data models and they are managed by the framework.
where lombox is a code generator/injector. its like if you would compare libraries and macros in C. and there are a lot of reasons to not use C macros. lombox is by far not as bad as C macros are, but there are still reasons to limit its usage.
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
Lombok 'toString' did me wrong on many to many relationship. I spent hours trying to figure out what was wrong.
Thats why you need to be carefull where you use the Lombok annotations. For Hibernate entities equals() and hashcode() should check for HibernateProxy objects too and if it relates to an entity with the same id. And the generated toString() method includes all fields which might load lazy loaded fields, which triggers extra database queries. Its like a knife, it could be a usefull tool or a weapon (depending how it is used).
My philosophy is "only use the very essential Lombok annotations if you're sure of what they are doing, otherwise don't use them"
The use of Lombok in core/domain should be a crime though 😂😂
I don't agree. This is like saying, why you use spring? It is better to use plain java to implement those applications so "you have more control of what it is being done and you don't have to teach a new member what spring does". It sounds simply out of the scope. Why we use spring? Why we use lombok? Maybe because community has developed something that is good enough to be faster on doing applications and we do not reinvent the wheel. This is the same... why lombok? Will I cry about the hashcode method that was generated? Well if i really need performance and I know that i will need a specific hashcode method i can implement it myself but getters and setters is very XD
This video got me thinking. Do I really need Lombok?
Lombok is kind of a standard for my team. No one uses getters and setters these days.
"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.
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.
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.
I think that we must use Lombok ONLY on the stage of REFACTORING. When everything was completely tested.
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.
You enter the videos by saying "Es-salamu Alaikum". I am being so happy
Thanks. What's the theme for IntelliJ please.
Maybe a compromise would be to only use it when you need a builder?
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.
what do you think about mapstruct?
hi, like your videos... can you make video on pluggins on IntelliJ that you recomend please
Whilst we are talking about maintaining control of your code, have you seen springboot!!!
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
Love Lombok Builder annotation
Whether agree or not of using Lombok, I feel better to use old school ways to generate the mutator / accessor / constructors.
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.
you can use chain in setters instead of builder
I feel you are typical tutorial creator who does not create real production ready code. Lombok covers much larger scope than record. it works at much broader level than record. If you are working with a real enterprise application and using Spring Boot, you will understand how much effort Lombok will save you.
Tbh, I disagree with not using it. I actually just learned it and while doing so I immediately noticed that I might only want to use getters and setters rarely something else (at least for now) because as he says in the video you will have less visibility. But everyone knows what a simple getter and setter is. If I know my variable will need more than just setting a variable equal to the function params, I will overwrite the setter by implementing my own.
Hard disagree on almost all your points.
No visility is less error prone than typing a million setters manually. Also abstraction is a good thing imo
IDE Support: Why would you not use such an IDE in the first place?
Debugging: why would you need a breakpoint in a getter or setter?
Tostring with entities: Devs fault not the framework.
Dependency: Imo only valid point, but irrelevant as long as no vulnerability
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
🤣
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.
Pls give a video how the interview happend for Java developer in uk