Guided use of Lombok in JG?


Kedar Mhaswade <ke...@...>
 

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


Henry Saputra <henry....@...>
 

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...@...> 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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Terry Moschou <tmos...@...>
 

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

First time I've heard of Lombok so I though I would try out their @Cleanup since in my experience ARM is usually implemented with unintended semantics. Looks like it allows exceptions thrown in finally-close() to mask any original exception currently throwing which isn't good and differs from java try-with-resource semantics (perhaps it came before Java 7?). I wouldn't recommend that feature at least.


On Wednesday, 7 June 2017 01:42:06 UTC+9:30, 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


Alexander Patrikalakis <amcpatr...@...>
 

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


Ted Wilmes <twi...@...>
 

I like your proposed steps 1 & 2 Kedar. If we decided to continue with it after step 2, I think we should go through and finish up refactoring all the other packages to use whichever pieces of Lombok we've decided on. If we piecemeal it in as we make other changes, I think we'll just end up with a confusing mishmash of coding styles.

--Ted


On Wednesday, June 7, 2017 at 1:58:25 PM UTC-5, Alexander Patrikalakis wrote:
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.


Henry Saputra <henry....@...>
 

Sorry, I did not mean to sidetrack disucssion about adding Lombok semantics to JG code, especially in core modules.
I was trying to imply that adding "magic" annotation could cause hard to follow/debug compare to the ones defining interface such as with with protobuf.

But I am +1 with Kedar approaches for introducing pros/cons to introduce Lombok uses in JG codebase.

- Henry

On Fri, Jun 9, 2017 at 6:39 AM, Ted Wilmes <twi...@...> wrote:
I like your proposed steps 1 & 2 Kedar. If we decided to continue with it after step 2, I think we should go through and finish up refactoring all the other packages to use whichever pieces of Lombok we've decided on. If we piecemeal it in as we make other changes, I think we'll just end up with a confusing mishmash of coding styles.

--Ted


On Wednesday, June 7, 2017 at 1:58:25 PM UTC-5, Alexander Patrikalakis wrote:
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.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Samik Raychaudhuri <sam...@...>
 

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



Alexander Patrikalakis <amcpatr...@...>
 

To help spark discussion, I have proposed a use of Lombok here:
https://github.com/JanusGraph/janusgraph/pull/386

It reduces the janusgraph-core code base by 2327 lines.


On Tuesday, June 13, 2017 at 4:15:53 PM UTC+8, Samik R wrote:
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



sjudeng <sju...@...>
 

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


ankur...@...
 

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


Jason Plurad <plu...@...>
 

I haven't used lombok, so I'm +0 for now, but I'm willing to be convinced. Boilerplate in Java doesn't really bother me.

The IDE experience is important. I wouldn't want lombok to make developing JanusGraph more difficult. I assume the custom plugins are all free open source. It'd be nice to have a developer guide on how to set up and configure IDEs with those plugins for JanusGraph development and debugging.


On Tuesday, November 28, 2017 at 12:32:11 AM UTC-5, ankurgoelmb wrote:
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


Alexander Patrikalakis <amcpatr...@...>
 

Difficulty of debugging is good enough reason to not introduce this change now. Removing this code removes the ability to add a breakpoint (unless you attach it to the jars after annotation processing, and then line number math gets screwed up when stepping in the debugger). I will retire the PR and revisit if lombok ever goes GA with JDK 9 support.

I would like to note that lombok does support two major IDEs (Eclipse, IntelliJ), even if it means installing a plugin etc.


On Tuesday, November 28, 2017 at 2:32:11 PM UTC+9, an...@... wrote:
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