Re: Exploring using Kotlin for building the "Cluster Management Service"
Bringing the discussion on the PR back to the dev list An important point that was raised by Anthony was: " Introducing a new language to the Geode project raises some questions that we need to answer as a community before adopting this proposal: - When is it appropriate to use Kotlin? When should we prefer Java? - Are there a sufficient number of committers with Kotlin experience to maintain the work over the long-term? - How will the introduction of Kotlin affect the development experience and build times? - Does this increase the learning curve for new committers? I think I would be more comfortable exploring this change in a submodule rather than in geode-core. I would also like to see all the REST code move to geode-web or geode-mgmtso that we can finally fix those broken dependencies. Specifically we should aim to delete thewebJar` Gradle task from geode-core." I feel that some of these questions can be answered better by actually introducing Kotlin into the codebase and seeing the results -- but obviously there is a concern with how locked-in we get if we come to the conclusion that Kotlin is not for us. We will look into introducing as a submodule that is a sibling to geode-core, and revisit things. Closing the PR for now, I feel I have the feedback I need. -Aditya On Wed, Jan 2, 2019 at 3:11 PM Aditya Anchuri wrote: > Hi everyone, > > As part of work on the proposed Cluster Management API ( > https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service), > some of us have been exploring introducing Kotlin into the codebase. One of > the things I personally love about Kotlin is null references being > controlled by the type system, reducing the incidence of null pointer > errors. > > Other pros can be found here: > https://kotlinlang.org/docs/reference/comparison-to-java.html > > We have made a very basic PR as to how this could potentially work. > Personally, I see this usecase as less of a chance to shine for Kotlin than > other potential usecases within geode, because of the fact that we'd still > end up using a lot of Java objects from geode-core in order to exercise the > "create region" functionality. However, I could make a case for Kotlin just > from the fact that it is a more modern language. > > Would love to get people's feedback on what they think about introducing > Kotlin to the geode codebase, and whether it makes sense for the Cluster > Management API. > > https://github.com/apache/geode/pull/3049 > > Thanks, > -Aditya > >
Exploring using Kotlin for building the "Cluster Management Service"
Hi everyone, As part of work on the proposed Cluster Management API ( https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service), some of us have been exploring introducing Kotlin into the codebase. One of the things I personally love about Kotlin is null references being controlled by the type system, reducing the incidence of null pointer errors. Other pros can be found here: https://kotlinlang.org/docs/reference/comparison-to-java.html We have made a very basic PR as to how this could potentially work. Personally, I see this usecase as less of a chance to shine for Kotlin than other potential usecases within geode, because of the fact that we'd still end up using a lot of Java objects from geode-core in order to exercise the "create region" functionality. However, I could make a case for Kotlin just from the fact that it is a more modern language. Would love to get people's feedback on what they think about introducing Kotlin to the geode codebase, and whether it makes sense for the Cluster Management API. https://github.com/apache/geode/pull/3049 Thanks, -Aditya
Re: Javadoc errors in org/apache/geode/cache/configuration/RegionAttributesType.java
Okay. Please go ahead and merge, I can’t since I’m not a committer. On Thu, Dec 20, 2018 at 3:00 PM Kirk Lund wrote: > Looks good. Thanks! I added my approval. > > On Thu, Dec 20, 2018 at 2:20 PM Aditya Anchuri > wrote: > > > PR to fix: https://github.com/apache/geode/pull/3030 > > > > On Thu, Dec 20, 2018 at 1:58 PM Aditya Anchuri > > wrote: > > > > > These classes were removed recently, but it looks like we forgot to > clean > > > up the javadocs. Will make a PR to fix ASAP. > > > > > > -Aditya > > > > > > On Thu, Dec 20, 2018 at 1:57 PM Kirk Lund wrote: > > > > > >> Just a reminder that any classes not behind internal packages need to > > have > > >> functional Javadocs. > > >> > > >> We have Javadoc errors involving > > >> org/apache/geode/cache/configuration/RegionAttributesType.java > referring > > >> to > > >> RegionTimeToLive which I can't find when I grep. > > >> > > >> > Task :geode-assembly:docs > > >> > > >> > > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:479: > > >> warning - Tag @link: reference not found: > > >> RegionAttributesType.RegionTimeToLive > > >> > > >> > > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:490: > > >> warning - Tag @link: reference not found: > > >> RegionAttributesType.RegionTimeToLive > > >> > > >> > > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:501: > > >> warning - Tag @link: reference not found: > > >> RegionAttributesType.RegionIdleTime > > >> > > >> > > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:512: > > >> warning - Tag @link: reference not found: > > >> RegionAttributesType.RegionIdleTime > > >> > > >> > > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:523: > > >> warning - Tag @link: reference not found: > > >> RegionAttributesType.EntryTimeToLive > > >> > > >> > > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:534: > > >> warning - Tag @link: reference not found: > > >> RegionAttributesType.EntryTimeToLive > > >> > > >> > > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:545: > > >> warning - Tag @link: reference not found: > > >> RegionAttributesType.EntryIdleTime > > >> > > >> > > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:556: > > >> warning - Tag @link: reference not found: > > >> RegionAttributesType.EntryIdleTime > > >> 8 warnings > > >> > > > > > >
Re: Javadoc errors in org/apache/geode/cache/configuration/RegionAttributesType.java
PR to fix: https://github.com/apache/geode/pull/3030 On Thu, Dec 20, 2018 at 1:58 PM Aditya Anchuri wrote: > These classes were removed recently, but it looks like we forgot to clean > up the javadocs. Will make a PR to fix ASAP. > > -Aditya > > On Thu, Dec 20, 2018 at 1:57 PM Kirk Lund wrote: > >> Just a reminder that any classes not behind internal packages need to have >> functional Javadocs. >> >> We have Javadoc errors involving >> org/apache/geode/cache/configuration/RegionAttributesType.java referring >> to >> RegionTimeToLive which I can't find when I grep. >> >> > Task :geode-assembly:docs >> >> /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:479: >> warning - Tag @link: reference not found: >> RegionAttributesType.RegionTimeToLive >> >> /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:490: >> warning - Tag @link: reference not found: >> RegionAttributesType.RegionTimeToLive >> >> /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:501: >> warning - Tag @link: reference not found: >> RegionAttributesType.RegionIdleTime >> >> /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:512: >> warning - Tag @link: reference not found: >> RegionAttributesType.RegionIdleTime >> >> /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:523: >> warning - Tag @link: reference not found: >> RegionAttributesType.EntryTimeToLive >> >> /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:534: >> warning - Tag @link: reference not found: >> RegionAttributesType.EntryTimeToLive >> >> /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:545: >> warning - Tag @link: reference not found: >> RegionAttributesType.EntryIdleTime >> >> /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:556: >> warning - Tag @link: reference not found: >> RegionAttributesType.EntryIdleTime >> 8 warnings >> >
Re: Javadoc errors in org/apache/geode/cache/configuration/RegionAttributesType.java
These classes were removed recently, but it looks like we forgot to clean up the javadocs. Will make a PR to fix ASAP. -Aditya On Thu, Dec 20, 2018 at 1:57 PM Kirk Lund wrote: > Just a reminder that any classes not behind internal packages need to have > functional Javadocs. > > We have Javadoc errors involving > org/apache/geode/cache/configuration/RegionAttributesType.java referring to > RegionTimeToLive which I can't find when I grep. > > > Task :geode-assembly:docs > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:479: > warning - Tag @link: reference not found: > RegionAttributesType.RegionTimeToLive > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:490: > warning - Tag @link: reference not found: > RegionAttributesType.RegionTimeToLive > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:501: > warning - Tag @link: reference not found: > RegionAttributesType.RegionIdleTime > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:512: > warning - Tag @link: reference not found: > RegionAttributesType.RegionIdleTime > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:523: > warning - Tag @link: reference not found: > RegionAttributesType.EntryTimeToLive > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:534: > warning - Tag @link: reference not found: > RegionAttributesType.EntryTimeToLive > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:545: > warning - Tag @link: reference not found: > RegionAttributesType.EntryIdleTime > > /Users/klund/dev/gemfire1/open/geode-core/src/main/java/org/apache/geode/cache/configuration/RegionAttributesType.java:556: > warning - Tag @link: reference not found: > RegionAttributesType.EntryIdleTime > 8 warnings >
Re: [DISCUSS] LGTM on pull requests
+1, although I do wonder about the overhead of making PRs increasing more than it already feels like to me as a new contributor (as the person who made the geospatial contribution). If this was a gradle task maybe like spotless? On Fri, Nov 9, 2018 at 2:20 PM Bruce Schuchardt wrote: > I'd like to see LGTM run on pull requests. Otherwise I think we're > fighting a losing battle trying to improve the quality of our code. For > instance, we just had a nice contribution of geospatial functionality > that raised 5 alerts, but we only found out about it after the code was > merged to develop. > > LGTM allows that kind of integration but you have to be the repo "owner" > to set it up. > > > https://lgtm.com/projects/g/apache/geode/ > > >
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, Nov 9, 2018 at 9:52 AM Aditya Anchuri wrote:
> 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:40 AM Kirk Lund wrote:
>
>> -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 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 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 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 ?
>> > >&g
Re: Lombok
unctionArgs
> > >> @JvmOverloads private constructor(val manualStart: Boolean, val
> > startPort:
> > >> Int?, val endPort: Int?, val bindAddress: String, val
> socketBufferSize:
> > >> Int?, val maximumTimeBetweenPings: Int?, val gatewayTransportFilters:
> > >> Array, 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()
> > >> ?: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
> 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
> >
> >
>
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 Baker 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 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 > 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 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 > >>>> > >>> > >>> > >
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 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 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 >> > >> >>
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/apache/geode/pull/2815 -Aditya On Thu, Nov 8, 2018 at 11:24 AM Udo Kohlmeyer 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 > > > >
Lombok
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
Geospatial command support in Redis adapter
Hello, I recently forked geode on github and started working on adding geospatial commands (supported in Redis >3.2) to the Redis adapter (GEOADD, GEOPOS, GEOHASH, GEODIST, GEORADIUS and GEORADIUSBYMEMBER). I am wrapping up my work on this, but before I make a PR I would like to know if this is a feature that people are interested in having? If so, would there be a JIRA ticket created? This is my first time contributing to Geode. Thanks, -Aditya
