Regarding is vs get, Lombok generates a getter as "isFoo" if foo is a boolean type -- but a Boolean object type by default gets generated as getFoo().
I personally like that, because I want to make sure I communicate in that getter that the type is nullable. On Thu, Nov 8, 2018 at 2:33 PM Anthony Baker <aba...@pivotal.io> wrote: > I’d prefer to keep lombok usage out of our public API’s. I’d like to be > able to write javadoc for all public methods. Also, I don’t want a user to > have to understand Lombok to read our API’s or do an extra step to setup > their IDE. > > For internal usage I’m agnostic with a small dose of concern on > equals/hashcode in critical code paths. > > My $0.02, > Anthony > > > > On Nov 8, 2018, at 1:57 PM, Aditya Anchuri <aanch...@pivotal.io> wrote: > > > > Note: If the PR gets accepted, people that use IntelliJ idea or Eclipse > > will need to use the Lombok plugin for their respective IDEs -- for > > IntelliJ people will also need to enable annotation processing in the > > compiler settings if not already enabled. > > > > On Thu, Nov 8, 2018 at 12:02 PM Aditya Anchuri <aanch...@pivotal.io> > wrote: > > > >> I've only touched a few classes in my PR, but I feel like there's a lot > >> more boilerplate floating around that can be removed. Having said that, > I > >> agree with your point regarding Kotlin, but for the Java code I would > find > >> Lombok pretty useful. Have included a link to the PR: > >> > >> https://github.com/apache/geode/pull/2815 > >> > >> -Aditya > >> > >> > >> > >> On Thu, Nov 8, 2018 at 11:24 AM Udo Kohlmeyer <u...@apache.org> wrote: > >> > >>> The Spring world/community are heavy users of Lombok. > >>> > >>> In essence it is "nice", BUT it does now add a new dependency on a > >>> library that is to provide functionality that developers should > provide. > >>> IJ Idea does provide support for Lombok. > >>> > >>> I have not yet seen any code bloat that Lombok could reduce for us. > >>> Also, the reduction is only in terms of "visible", the compiled class > >>> might be more verbose. > >>> > >>> Kotlin on the other hand, as some of the boilerplate code built in as a > >>> language feature. I prefer that over choosing a library, that might > have > >>> compatibility issues in the future. > >>> > >>> Also, Kotlin's conciseness is also a language feature rather than > >>> library plugin. I've also seen cases where compiled Java was larger > than > >>> the equivalent compiled Kotlin code. > >>> > >>> --Udo > >>> > >>> > >>> On 11/8/18 10:31, Aditya Anchuri wrote: > >>>> Hi everyone, > >>>> > >>>> I am considering adding Lombok as a compile-time dependency ( > >>>> https://projectlombok.org/) so we can reduce the amount of > boilerplate > >>> code > >>>> and reduce the size of some of our classes. I have a small proof of > >>> concept > >>>> PR ready to go. Before I do so, I want to find out if people have > tried > >>> it > >>>> before and how they feel about it, especially when used with IDEs like > >>>> IntelliJ and/or Eclipse? > >>>> > >>>> Thanks, > >>>> -Aditya > >>>> > >>> > >>> > >
