Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:

1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.

2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,

Kedar

Thanks for taking the initiative, Kedar.

One problem from my experience with Lombok and other similar code generator-like framework its that it generates code that developers don't control without benefits for polyglot support like with Protobuf or Apache Thrift.

So, would love to see possible approach and which areas can be moved or leverage Lombok in JG codebase.

- Henry

On Tue, Jun 6, 2017 at 9:11 AM, 'Kedar Mhaswade' via JanusGraph developer list <janusgr...@googlegroups.com> wrote:

Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:

1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.

2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,

Kedar

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

What are the benefits for polyglot support Lombok lacks that JanusGraph-Core needs? I think a non-Java rewrite of JanusGraph is not on the radar of our short-term and medium-term roadmap.

Also, the service interface of JanusGraph is provided by Gremlin Server over HTTP and Websockets, not inside JanusGraph, so it also seems like supporting polyglot service front ends within JanusGraph-Core is out of scope.

On Tuesday, June 6, 2017 at 7:42:37 AM UTC-10, Henry Saputra wrote:

Thanks for taking the initiative, Kedar.

One problem from my experience with Lombok and other similar code generator-like framework its that it generates code that developers don't control without benefits for polyglot support like with Protobuf or Apache Thrift.

So, would love to see possible approach and which areas can be moved or leverage Lombok in JG codebase.

- Henry

On Tue, Jun 6, 2017 at 9:11 AM, 'Kedar Mhaswade' via JanusGraph developer list <jan...@...> wrote:

Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:

1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.

2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,

Kedar

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Too bad JanusGraph wasn't written in Scala - boilerplate is kinda Java's thing right haha ;-p

My thought exactly - oh well!!
Regards.
-Samik

On 07-Jun-17 6:31 AM, Terry Moschou wrote:

Too bad JanusGraph wasn't written in Scala - boilerplate is kinda Java's thing right haha ;-p

Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:

1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.

2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,

Kedar

In reviewing Lombok for the recent PR #741 I thought the feedback should go here instead of GitHub to allow more interaction and since there is already this existing discussion.

Widespread adoption of Lombok in JanusGraph would tie us to the dependency more so than I think any other current dependency. I think this is a risk and it's not worth it just to improve a loc metric. IDEs do not natively support Lombok and require custom plugins. JanusGraph can already be very challenging to debug and I wouldn't think we'd want to add another abstraction layer that might make this even more difficult unless there's a compelling reason to do so.

Lombok also appears to have issues with Java 9 that currently require compile flags of the form "permit-illegal-access" (see here). Even if that works I find it concerning in terms of the long term sustainability of their current implementation.

+1 for going to Scala though if we're dreaming big

On Tuesday, June 6, 2017 at 11:12:06 AM UTC-5, Kedar Mhaswade wrote:

Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:

1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.

2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,

Kedar

i agree with sjudeng. Right now its a challenge with JG in debugging.

This will add another layer of abstraction, till the time we have mature/acceptable version another abstraction do not hold good.

~

On Tuesday, November 28, 2017 at 6:30:56 AM UTC+5:30, sjudeng wrote:

In reviewing Lombok for the recent PR #741 I thought the feedback should go here instead of GitHub to allow more interaction and since there is already this existing discussion.

Widespread adoption of Lombok in JanusGraph would tie us to the dependency more so than I think any other current dependency. I think this is a risk and it's not worth it just to improve a loc metric. IDEs do not natively support Lombok and require custom plugins. JanusGraph can already be very challenging to debug and I wouldn't think we'd want to add another abstraction layer that might make this even more difficult unless there's a compelling reason to do so.

Lombok also appears to have issues with Java 9 that currently require compile flags of the form "permit-illegal-access" (see here). Even if that works I find it concerning in terms of the long term sustainability of their current implementation.

+1 for going to Scala though if we're dreaming big

On Tuesday, June 6, 2017 at 11:12:06 AM UTC-5, Kedar Mhaswade wrote:

Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:

1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.

2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,

Kedar

i agree with sjudeng. Right now its a challenge with JG in debugging.

This will add another layer of abstraction, till the time we have mature/acceptable version another abstraction do not hold good.

~

On Tuesday, November 28, 2017 at 6:30:56 AM UTC+5:30, sjudeng wrote:

In reviewing Lombok for the recent PR #741 I thought the feedback should go here instead of GitHub to allow more interaction and since there is already this existing discussion.

Widespread adoption of Lombok in JanusGraph would tie us to the dependency more so than I think any other current dependency. I think this is a risk and it's not worth it just to improve a loc metric. IDEs do not natively support Lombok and require custom plugins. JanusGraph can already be very challenging to debug and I wouldn't think we'd want to add another abstraction layer that might make this even more difficult unless there's a compelling reason to do so.

Lombok also appears to have issues with Java 9 that currently require compile flags of the form "permit-illegal-access" (see here). Even if that works I find it concerning in terms of the long term sustainability of their current implementation.

+1 for going to Scala though if we're dreaming big

On Tuesday, June 6, 2017 at 11:12:06 AM UTC-5, Kedar Mhaswade wrote:

Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:

1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.

2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,

Kedar