Personally I am not a fan of Lombok either. I do recognize there can be some (small) convenience in using it [1]. However, I think it would be better to drive our efforts towards modernizing the codebase to use features from newer Java versions (*when* the time comes). Some of these features will, eventually, bring similar convenience we see in Lombok (i.e.: Java records) at the cost of a smaller maintenance effort.
1. https://stackoverflow.com/posts/61325018/revisions On Thu, Nov 4, 2021 at 7:18 AM Tadayoshi Sato <[email protected]> wrote: > Yes, Lombok should be best for using with a Camel application, but not > necessary so for the framework/library code of Camel itself. > Code simplicity is great but sometimes being explicit wins over magical > simplicity. > As an object-oriented programmer, if we need getters/setters in the code I > think it's already somewhat losing. Ideally we should be able to live > without getters/setters, but if it's unavoidable then in my opinionated > view it's less important whether it's implicit or not. > > On Wed, Nov 3, 2021 at 7:36 AM Vyacheslav Boyko <[email protected]> > wrote: > > > Lombok have advantages and disadvantages both. > > With bringing reducing of annoying boilerplate it brings its "magic" of > > underlying code generation which could be understood only by having some > > level of practice using Lobmok. For example, deserialization troubles > > when a constructor have more than one parameter with the same type (it > > needs to be annotated with @Creator or @ConstructorProperties). I guess, > > the maintainers of Camel don't want to be involved into such issues. > > > > On 11/3/21 00:35, Steve973 wrote: > > > You see no advantage in getting boilerplate code for free, and keeping > > your > > > beans, etc, free from accessors/mutators, no arg constructors, all arg > > > constructors, getting a builder for free, and lots of other stuff? I > can > > > see avoiding it in a project for particular reasons, but most of the > > > "favorite" frameworks reduce a lot of boilerplate code, and Camel is > > > included in that. I'm not arguing, but I really am curious why you see > > no > > > advantage. That is, of course, if it's appropriate to have this > > > conversation here, on this list. > > > > > > On Tue, Nov 2, 2021 at 5:31 PM Andrea Cosentino <[email protected]> > > wrote: > > > > > >> There is no problem with license. Personally i never find any > advantage > > in > > >> using Lombok. > > >> > > >> Il mar 2 nov 2021, 21:23 Steve973 <[email protected]> ha scritto: > > >> > > >>> Hello. I normally use lombok to take care of boiler plate code in > > >> projects > > >>> that I work on. I have noticed that lombok is not used in the camel > > code > > >>> base. Is there something about it (licensing or something else) that > > >> makes > > >>> it unsuitable for camel? I am working on something in camel-core, > and > > it > > >>> would be great to be able to use it to keep things cleaner. But I > > would > > >>> think that if it was acceptable in an apache project, people would > > >> already > > >>> be using it. Does anyone have the details on this? > > >>> > > >>> Thanks, > > >>> Steve > > >>> > > > > > -- > Tadayoshi Sato > -- Otavio R. Piske http://orpiske.net
