Re: Lombok

I'm happy to put this work on hold for now. As I mentioned there are other benefits beyond just getters and setters -- but I guess the risk with JDK10 (I was unaware of the problems between Lombok and JDK10) may be unknown enough for us to take pause. Thanks for all your input! -Aditya On Fri, No

Re: Lombok

I apologize, I was slightly wrong earlier with regards to the the IntelliJ Lombok plugin -- people will not need the IntelliJ plugin for their code to compile -- but they will need to enable compile-time annotation processing as an option. The plugin is a nice-to-have. On Fri, Nov 9, 2018 at 9:4

Re: Lombok

-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 hi

Re: Lombok

I was talking with Dale and he pointed me to this discussion: 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

Re: Lombok

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 contributor

Re: Lombok

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

Re: Lombok

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

Re: Lombok

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

Re: Lombok

I know that this is "pedantic".. but to me "isDiskSynchronous" reads better than "getDiskSynchronous" but in the end, it returns the declared field. Kotlin's data class on the other plays a little "nicer". If you define the field as "isDiskSynchronous" the generated getter is "isDiskSynchrono

Re: Lombok

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

Re: Lombok

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/apac

Re: Lombok

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 reduc