Thanks, Andra, for the informative reply. I understand and appreciate your assessment, and it seems like the correct decision for Apache Camel, given your reasoning. That clears a lot of things up for me. My questions are only out of curiosity, so I hope this discussion is reasonable and welcome for you and Claus. Making the decision for everyone else -- a considerably large community -- is, perhaps, my favorite point on your list. I had not considered that, but that's huge! It is also good to know that delombok might not be reliable, since I have not used it before. I will keep that in mind in the future. I am going to experiment with that, so that I might know what to expect.
For only the sake of this discussion (and not in the hope that the use of lombok might be reconsidered), I would like to offer a couple of points for lombok use *outside of Camel and its related repositories*: 1. Since version 1.12, javadoc is handled quite well, and you can see more here <https://projectlombok.org/features/GetterSetter> at the end of the "overview" section (at the top). 2. For me, it is not a matter of laziness; as you said, most of the boilerplate is easily generated by IDEs. To me, it is a matter of " *boilerplate noise"*. When I look at source code, and when most of the code that is on my screen is only the business logic, then that makes for a nicely decluttered view. As a workaround, we could utilize things like editor folding regions for getter/setter methods. Another workaround, for builders, is to use an IDE plugin to generate them. Thanks again! I always enjoy the discussion. On Sun, Nov 19, 2023 at 8:51 AM Andrea Cosentino <anco...@gmail.com> wrote: > Last but not least, there are no clear, IMO, advantages is using it, > despite the fact you'll see less boilerplate code. This laziness is > something I don't understand. IDEs will generate setters/getters for you > just with a shortcut on classes with thousands of fields. > > Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino < > anco...@gmail.com> > ha scritto: > > > Hello, > > > > Let me add also add a couple of points: > > 1. It's true that is just a compile dependency but when you decide to use > > lombok, you also decide that everyone else who deals with your code will > > have to use lombok. Lombok is special in that it is a build-time > dependency > > and your IDE needs plugins to figure out what is going on. So this is a > big > > drawback in my opinion. > > 2. Going back from Lombok to without Lombok, in big projects is not easy. > > Delombok is not an answer, because it's not reliable. > > 3. We are using the javadoc on getter and setter for generating > > documentation, with Lombok we need to find a different way and since the > > code is generated I don't think it would be easy. > > 4. Debugging Lombok is a pain. > > > > and I could go ahead. > > > > Il giorno dom 19 nov 2023 alle ore 14:12 Claus Ibsen < > > claus.ib...@gmail.com> ha scritto: > > > >> Hi > >> > >> No lombok is not allowed - we have as minimal dependency as possible. > >> > >> > >> > >> On Sun, Nov 19, 2023 at 2:06 PM Steve973 <steve...@gmail.com> wrote: > >> > >> > Hello. I completely understand the perspective of limiting the > >> addition of > >> > libraries for various reasons, and especially when the library is > >> included > >> > in the distribution. I know that I have asked about Lombok before, > but > >> it > >> > is great for eliminating a lot of boilerplate code, especially when a > >> class > >> > cannot be created as a Java 17 record. Also, Lombok is a compile-only > >> > dependency that uses annotation processing to generate the > >> aforementioned > >> > boilerplate. The license also seems compatible. Is this something > that > >> > can be used in the coding of a component? If not, could somebody > please > >> > explain the problem with it? > >> > > >> > Thanks, > >> > Steve > >> > > >> > >> > >> -- > >> Claus Ibsen > >> ----------------- > >> @davsclaus > >> Camel in Action 2: https://www.manning.com/ibsen2 > >> > > >
