Oh, regarding my other question, which might have gotten lost among the bigger discussion about Lombok: is the camel component codebase java-only, or is Kotlin also ok?
On Sun, Nov 19, 2023 at 9:20 AM Steve973 <steve...@gmail.com> wrote: > 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 >> >> >> > >> >
