-1 Personally, I prefer to being able to see and manipulate ALL code. I hate autogenerated code, and I don't mind boilerplate code. When I see a class that has too many getters, then I see that as a sign that we need to do some refactoring and correct the design of that class. Using Lombok would hide too much and make it less obvious that we have Encapsulation and God Class problems to fix and change.
Generated code also makes stepping through code with a debugger and doing performance engineering a nightmare. On Fri, Nov 9, 2018 at 9:07 AM, Anthony Baker <aba...@pivotal.io> wrote: > I was talking with Dale and he pointed me to this discussion: > https://github.com/jhipster/generator-jhipster/issues/398 < > https://github.com/jhipster/generator-jhipster/issues/398> > > I think it probably warrants more investigation (e.g. do the issues > decried on the the internet still exist?) before we adopt this. > > Anthony > > > > On Nov 9, 2018, at 9:00 AM, Jinmei Liao <jil...@pivotal.io> wrote: > > > > So users who wish to download our code will need to read some > documentation > > on how to setup IDEA/Eclipse before they can compile. It's not a simple > > "import and work with default IDEA setup" now. > > > > +0 on this. Personally I would prefer to bear with the extra > getter/setters > > than giving new contributors more headache at startup. > > > > On Thu, Nov 8, 2018 at 5:10 PM Udo Kohlmeyer <u...@apache.org> wrote: > > > >> As an informative comparison on conciseness offering same functionality: > >> > >> Java Code: > >> > >> import java.io.Serializable; import lombok.Getter; import > >> org.apache.geode.cache.configuration.CacheConfig.GatewayReceiver; > import > >> org.apache.geode.cache.configuration.DeclarableType; /** * This class > >> stores the arguments provided in the create > >> gateway-receiver command. */ @Getter public class > >> GatewayReceiverFunctionArgsimplements Serializable { > >> private static final long serialVersionUID = -5158224572470173267L; > >> private final BooleanmanualStart; private final IntegerstartPort; > private > >> final IntegerendPort; private final StringbindAddress; private final > >> IntegersocketBufferSize; private final IntegermaximumTimeBetweenPings; > >> private final String[]gatewayTransportFilters; private final > >> StringhostnameForSenders; private final BooleanifNotExists; public > >> GatewayReceiverFunctionArgs(GatewayReceiver configuration, Boolean > >> ifNotExists) { > >> this.manualStart = configuration.isManualStart(); this.startPort = > >> configuration.getStartPort() !=null ? > >> Integer.valueOf(configuration.getStartPort()) :null; this.endPort = > >> configuration.getEndPort() !=null ? > >> Integer.valueOf(configuration.getEndPort()) :null; this.bindAddress = > >> configuration.getBindAddress(); this.socketBufferSize = > >> configuration.getSocketBufferSize() !=null ? > >> Integer.valueOf(configuration.getSocketBufferSize()) :null; > >> this.maximumTimeBetweenPings = configuration. > getMaximumTimeBetweenPings() > >> !=null ? Integer.valueOf(configuration.getMaximumTimeBetweenPings()) > :null; > >> this.gatewayTransportFilters = configuration. > getGatewayTransportFilter() > >> !=null ? > >> configuration.getGatewayTransportFilter().stream().map(DeclarableType:: > getClassName) > >> .toArray(String[]::new) > >> :null; this.hostnameForSenders = > >> configuration.getHostnameForSenders(); this.ifNotExists = ifNotExists; > } > >> } > >> > >> The equivalent Kotlin definition is: > >> > >> import org.apache.geode.cache.configuration.CacheConfig > >> import org.apache.geode.cache.configuration.ClassWithParametersType > >> import java.io.Serializable > >> > >> data class GatewayReceiverFunctionArgs > >> @JvmOverloads private constructor(val manualStart: Boolean, val > startPort: > >> Int?, val endPort: Int?, val bindAddress: String, val socketBufferSize: > >> Int?, val maximumTimeBetweenPings: Int?, val gatewayTransportFilters: > >> Array<String>, val hostNameForSender: String, val ifNotExists: Boolean) > : > >> Serializable{ > >> > >> constructor(configuration: CacheConfig.GatewayReceiver, ifNotExists: > >> Boolean) : > >> this(configuration.isManualStart, > >> configuration.startPort?.toInt(), configuration.endPort?.toInt(), > >> configuration.bindAddress, configuration.socketBufferSize?.toInt(), > >> configuration.maximumTimeBetweenPings?.toInt(), > >> configuration.gatewayTransportFilter ?.map { classWithParametersType: > >> ClassWithParametersType-> classWithParametersType.className } > >> ?.toTypedArray<String>() > >> ?:emptyArray(), configuration.hostnameForSenders, > >> ifNotExists) > >> > >> > >> companion object { > >> @JvmStatic val serialVersionUID = -5158224572470173267L } > >> } > >> > >> > >> On 11/8/18 12:02, Aditya Anchuri 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 > >>>>> > >>>> > >> > >> > > > > -- > > Cheers > > > > Jinmei > >
