You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Jeremy Daggett <je...@gmail.com> on 2013/11/11 19:36:26 UTC
Project Lombok - Builders (and other annotations)
Hi devs,
Has anyone in the community ever looked at using Project Lombok[1] to help
simplify our source code? I stumbled across this a couple of years back
and thought it was pretty useful. Just never had a chance to use it with
anything...
I think that the @Builder [2], @EqualsHashCode, and other annotations could
make many of our classes much simpler. We might be able to get rid of all
of that boilerplate code! ;)
WDYT?
[1] http://projectlombok.org/
[2]
https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
/jd
Re: Project Lombok - Builders (and other annotations)
Posted by Adrian Cole <ad...@gmail.com>.
TL;DR For sake of discussion, there's less magical codegen available: write
source. Probably not a silver bullet either.
Tools like Dagger, Wire, and Google Auto generate readable source code.
Also the test infra for how these work internally is getting super robust.
https://github.com/google/auto/blob/master/factory/src/test/java/com/google/auto/factory/processor/AutoFactoryProcessorTest.java
There are pitfalls to any annotation processing, most notably fragile IDE
setup which is hard to setup correctly (even with gradle :) ). Also, round
tripping or last mile stuff can be problematic. Basically they work best
when they do exactly what you want.
Jclouds supports some pretty varied styles in writing domain classes, from
"mind bending generic builder subclasses" to simple no-builder final
ctors. In a project that didnt need to support inheritance or extension,
maybe moving to black-box code gen might be safe. As it is, we have so
many dialects pf both style (ex. How to write equals) and apis pinned to
(the 3 ways keystone is implemented), I've my doubts.
Nice discussion!
On Nov 11, 2013 10:36 AM, "Jeremy Daggett" <je...@gmail.com>
wrote:
> Hi devs,
>
> Has anyone in the community ever looked at using Project Lombok[1] to help
> simplify our source code? I stumbled across this a couple of years back
> and thought it was pretty useful. Just never had a chance to use it with
> anything...
>
> I think that the @Builder [2], @EqualsHashCode, and other annotations could
> make many of our classes much simpler. We might be able to get rid of all
> of that boilerplate code! ;)
>
> WDYT?
>
> [1] http://projectlombok.org/
> [2]
>
> https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
>
> /jd
>
Re: Project Lombok - Builders (and other annotations)
Posted by Matt Stephenson <ma...@mattstep.net>.
-1, agree w/ Gaul. Annotations are abused as a DSL where there is actually
an incredibly limited grammar from the language itself. I recently was
involved in a discussion with the current language spec lead around changes
the java EE community needs in order to support the more extravagant use of
annotations that they're exploring.
One of the pains of using tools like this that generate bytecode is that
they usually fall out of maintenance when the language has a major revision
or the bytecode spec has a revision (such as stack map frames in java 7),
which can mean we have to then refactor away or start maintaining their
code.
The jclouds dependency closure is nice and tight, and we should strive to
keep it that way.
On Mon, Nov 11, 2013 at 11:35 AM, Zack Shoylev
<za...@rackspace.com>wrote:
> We already use a bunch of magic annotation functionality.
> I think perhaps what is needed here is to prototype refactor an api and
> see if this works.
> Specifically for Builder, there's lines upon lines of boilerplate in the
> domain classes I would like to just delete.
>
> -Zack
> ________________________________________
> From: Andrew Gaul [gaul@apache.org]
> Sent: Monday, November 11, 2013 1:11 PM
> To: dev@jclouds.apache.org
> Subject: Re: Project Lombok - Builders (and other annotations)
>
> On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> > Hi devs,
> >
> > Has anyone in the community ever looked at using Project Lombok[1] to
> help
> > simplify our source code? I stumbled across this a couple of years back
> > and thought it was pretty useful. Just never had a chance to use it with
> > anything...
> >
> > I think that the @Builder [2], @EqualsHashCode, and other annotations
> could
> > make many of our classes much simpler. We might be able to get rid of all
> > of that boilerplate code! ;)
> >
> > WDYT?
> >
> > [1] http://projectlombok.org/
> > [2]
> >
> https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
>
> -1, I find that the Java annotation magic libraries tend to create more
> problems than they solve. Specifically, they make debugging more
> difficult and introduce performance problems like JCLOUDS-358. Further
> these dialects make code hard to approach for casual developers.
>
> --
> Andrew Gaul
> http://gaul.org/
>
RE: Project Lombok - Builders (and other annotations)
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
We already use a bunch of magic annotation functionality.
I think perhaps what is needed here is to prototype refactor an api and see if this works.
Specifically for Builder, there's lines upon lines of boilerplate in the domain classes I would like to just delete.
-Zack
________________________________________
From: Andrew Gaul [gaul@apache.org]
Sent: Monday, November 11, 2013 1:11 PM
To: dev@jclouds.apache.org
Subject: Re: Project Lombok - Builders (and other annotations)
On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> Hi devs,
>
> Has anyone in the community ever looked at using Project Lombok[1] to help
> simplify our source code? I stumbled across this a couple of years back
> and thought it was pretty useful. Just never had a chance to use it with
> anything...
>
> I think that the @Builder [2], @EqualsHashCode, and other annotations could
> make many of our classes much simpler. We might be able to get rid of all
> of that boilerplate code! ;)
>
> WDYT?
>
> [1] http://projectlombok.org/
> [2]
> https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
-1, I find that the Java annotation magic libraries tend to create more
problems than they solve. Specifically, they make debugging more
difficult and introduce performance problems like JCLOUDS-358. Further
these dialects make code hard to approach for casual developers.
--
Andrew Gaul
http://gaul.org/
RE: Project Lombok - Builders (and other annotations)
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
They have good documentation...
________________________________________
From: Andrew Gaul [gaul@apache.org]
Sent: Friday, November 15, 2013 12:42 AM
To: dev@jclouds.apache.org
Subject: Re: Project Lombok - Builders (and other annotations)
On Mon, Nov 11, 2013 at 11:11:35AM -0800, Andrew Gaul wrote:
> On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> > Hi devs,
> >
> > Has anyone in the community ever looked at using Project Lombok[1] to help
> > simplify our source code? I stumbled across this a couple of years back
> > and thought it was pretty useful. Just never had a chance to use it with
> > anything...
> >
> > I think that the @Builder [2], @EqualsHashCode, and other annotations could
> > make many of our classes much simpler. We might be able to get rid of all
> > of that boilerplate code! ;)
> >
> > WDYT?
> >
> > [1] http://projectlombok.org/
> > [2]
> > https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
>
> -1, I find that the Java annotation magic libraries tend to create more
> problems than they solve. Specifically, they make debugging more
> difficult and introduce performance problems like JCLOUDS-358. Further
> these dialects make code hard to approach for casual developers.
Still not in favor of magic, but Google recently released AutoValue, a
less invasive annotation approach to value types, including getters:
https://github.com/google/auto
http://goo.gl/Ter394
Auto has some issues but holds promise; we should keep an eye on it.
--
Andrew Gaul
http://gaul.org/
RE: Project Lombok - Builders (and other annotations)
Posted by Adrian Cole <ad...@gmail.com>.
Pretty much all of these require that your ide compiles with their jar in
the classpath as a provided dep. Some IDEs also require explicit enabling
of annotation processing. Maven integration is pretty tight wrt this in
IDEs I've used.
When you change a source file, it is processed with auto or whatever, and
either incidental source is produced and compiled, or the bytecode is
altered directly, availing the new fields etc.
Often, there is some concern about output directories for generated source
or compiled files.
-A
On Nov 15, 2013 12:08 PM, "Zack Shoylev" <za...@rackspace.com> wrote:
> I didn't check - how's the IDE situation with auto? I might find the time
> to add it in some refactorings I have to do anyways.
> ________________________________________
> From: Adrian Cole [adrian.f.cole@gmail.com]
> Sent: Friday, November 15, 2013 11:58 AM
> To: dev@jclouds.apache.org
> Subject: Re: Project Lombok - Builders (and other annotations)
>
> FWIW, I plan to help with auto anyway. If you have problems trying it out,
> cc me on the github issue.
>
> -A
> On Nov 14, 2013 10:42 PM, "Andrew Gaul" <ga...@apache.org> wrote:
>
> > On Mon, Nov 11, 2013 at 11:11:35AM -0800, Andrew Gaul wrote:
> > > On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> > > > Hi devs,
> > > >
> > > > Has anyone in the community ever looked at using Project Lombok[1] to
> > help
> > > > simplify our source code? I stumbled across this a couple of years
> > back
> > > > and thought it was pretty useful. Just never had a chance to use it
> > with
> > > > anything...
> > > >
> > > > I think that the @Builder [2], @EqualsHashCode, and other annotations
> > could
> > > > make many of our classes much simpler. We might be able to get rid of
> > all
> > > > of that boilerplate code! ;)
> > > >
> > > > WDYT?
> > > >
> > > > [1] http://projectlombok.org/
> > > > [2]
> > > >
> >
> https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
> > >
> > > -1, I find that the Java annotation magic libraries tend to create more
> > > problems than they solve. Specifically, they make debugging more
> > > difficult and introduce performance problems like JCLOUDS-358. Further
> > > these dialects make code hard to approach for casual developers.
> >
> > Still not in favor of magic, but Google recently released AutoValue, a
> > less invasive annotation approach to value types, including getters:
> >
> > https://github.com/google/auto
> > http://goo.gl/Ter394
> >
> > Auto has some issues but holds promise; we should keep an eye on it.
> >
> > --
> > Andrew Gaul
> > http://gaul.org/
> >
>
RE: Project Lombok - Builders (and other annotations)
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
I didn't check - how's the IDE situation with auto? I might find the time to add it in some refactorings I have to do anyways.
________________________________________
From: Adrian Cole [adrian.f.cole@gmail.com]
Sent: Friday, November 15, 2013 11:58 AM
To: dev@jclouds.apache.org
Subject: Re: Project Lombok - Builders (and other annotations)
FWIW, I plan to help with auto anyway. If you have problems trying it out,
cc me on the github issue.
-A
On Nov 14, 2013 10:42 PM, "Andrew Gaul" <ga...@apache.org> wrote:
> On Mon, Nov 11, 2013 at 11:11:35AM -0800, Andrew Gaul wrote:
> > On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> > > Hi devs,
> > >
> > > Has anyone in the community ever looked at using Project Lombok[1] to
> help
> > > simplify our source code? I stumbled across this a couple of years
> back
> > > and thought it was pretty useful. Just never had a chance to use it
> with
> > > anything...
> > >
> > > I think that the @Builder [2], @EqualsHashCode, and other annotations
> could
> > > make many of our classes much simpler. We might be able to get rid of
> all
> > > of that boilerplate code! ;)
> > >
> > > WDYT?
> > >
> > > [1] http://projectlombok.org/
> > > [2]
> > >
> https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
> >
> > -1, I find that the Java annotation magic libraries tend to create more
> > problems than they solve. Specifically, they make debugging more
> > difficult and introduce performance problems like JCLOUDS-358. Further
> > these dialects make code hard to approach for casual developers.
>
> Still not in favor of magic, but Google recently released AutoValue, a
> less invasive annotation approach to value types, including getters:
>
> https://github.com/google/auto
> http://goo.gl/Ter394
>
> Auto has some issues but holds promise; we should keep an eye on it.
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: Project Lombok - Builders (and other annotations)
Posted by Adrian Cole <ad...@gmail.com>.
FWIW, I plan to help with auto anyway. If you have problems trying it out,
cc me on the github issue.
-A
On Nov 14, 2013 10:42 PM, "Andrew Gaul" <ga...@apache.org> wrote:
> On Mon, Nov 11, 2013 at 11:11:35AM -0800, Andrew Gaul wrote:
> > On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> > > Hi devs,
> > >
> > > Has anyone in the community ever looked at using Project Lombok[1] to
> help
> > > simplify our source code? I stumbled across this a couple of years
> back
> > > and thought it was pretty useful. Just never had a chance to use it
> with
> > > anything...
> > >
> > > I think that the @Builder [2], @EqualsHashCode, and other annotations
> could
> > > make many of our classes much simpler. We might be able to get rid of
> all
> > > of that boilerplate code! ;)
> > >
> > > WDYT?
> > >
> > > [1] http://projectlombok.org/
> > > [2]
> > >
> https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
> >
> > -1, I find that the Java annotation magic libraries tend to create more
> > problems than they solve. Specifically, they make debugging more
> > difficult and introduce performance problems like JCLOUDS-358. Further
> > these dialects make code hard to approach for casual developers.
>
> Still not in favor of magic, but Google recently released AutoValue, a
> less invasive annotation approach to value types, including getters:
>
> https://github.com/google/auto
> http://goo.gl/Ter394
>
> Auto has some issues but holds promise; we should keep an eye on it.
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: Project Lombok - Builders (and other annotations)
Posted by Adrian Cole <ad...@gmail.com>.
Ps Auto Value (currently) uses asm for bytecode manipulation as opposed to
Auto Factory, which writes generated source files (via javawriter). Makes
it more magicy, but not necessarily bad.
-A
On Nov 14, 2013 10:42 PM, "Andrew Gaul" <ga...@apache.org> wrote:
> On Mon, Nov 11, 2013 at 11:11:35AM -0800, Andrew Gaul wrote:
> > On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> > > Hi devs,
> > >
> > > Has anyone in the community ever looked at using Project Lombok[1] to
> help
> > > simplify our source code? I stumbled across this a couple of years
> back
> > > and thought it was pretty useful. Just never had a chance to use it
> with
> > > anything...
> > >
> > > I think that the @Builder [2], @EqualsHashCode, and other annotations
> could
> > > make many of our classes much simpler. We might be able to get rid of
> all
> > > of that boilerplate code! ;)
> > >
> > > WDYT?
> > >
> > > [1] http://projectlombok.org/
> > > [2]
> > >
> https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
> >
> > -1, I find that the Java annotation magic libraries tend to create more
> > problems than they solve. Specifically, they make debugging more
> > difficult and introduce performance problems like JCLOUDS-358. Further
> > these dialects make code hard to approach for casual developers.
>
> Still not in favor of magic, but Google recently released AutoValue, a
> less invasive annotation approach to value types, including getters:
>
> https://github.com/google/auto
> http://goo.gl/Ter394
>
> Auto has some issues but holds promise; we should keep an eye on it.
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: Project Lombok - Builders (and other annotations)
Posted by Andrew Gaul <ga...@apache.org>.
On Mon, Nov 11, 2013 at 11:11:35AM -0800, Andrew Gaul wrote:
> On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> > Hi devs,
> >
> > Has anyone in the community ever looked at using Project Lombok[1] to help
> > simplify our source code? I stumbled across this a couple of years back
> > and thought it was pretty useful. Just never had a chance to use it with
> > anything...
> >
> > I think that the @Builder [2], @EqualsHashCode, and other annotations could
> > make many of our classes much simpler. We might be able to get rid of all
> > of that boilerplate code! ;)
> >
> > WDYT?
> >
> > [1] http://projectlombok.org/
> > [2]
> > https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
>
> -1, I find that the Java annotation magic libraries tend to create more
> problems than they solve. Specifically, they make debugging more
> difficult and introduce performance problems like JCLOUDS-358. Further
> these dialects make code hard to approach for casual developers.
Still not in favor of magic, but Google recently released AutoValue, a
less invasive annotation approach to value types, including getters:
https://github.com/google/auto
http://goo.gl/Ter394
Auto has some issues but holds promise; we should keep an eye on it.
--
Andrew Gaul
http://gaul.org/
Re: Project Lombok - Builders (and other annotations)
Posted by Andrew Gaul <ga...@apache.org>.
On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote:
> Hi devs,
>
> Has anyone in the community ever looked at using Project Lombok[1] to help
> simplify our source code? I stumbled across this a couple of years back
> and thought it was pretty useful. Just never had a chance to use it with
> anything...
>
> I think that the @Builder [2], @EqualsHashCode, and other annotations could
> make many of our classes much simpler. We might be able to get rid of all
> of that boilerplate code! ;)
>
> WDYT?
>
> [1] http://projectlombok.org/
> [2]
> https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java
-1, I find that the Java annotation magic libraries tend to create more
problems than they solve. Specifically, they make debugging more
difficult and introduce performance problems like JCLOUDS-358. Further
these dialects make code hard to approach for casual developers.
--
Andrew Gaul
http://gaul.org/
Re: Project Lombok - Builders (and other annotations)
Posted by Jeremy Daggett <je...@gmail.com>.
Thanks for all of the feedback here. It is good to get some additional
perspective on this!
/jd
On Mon, Nov 11, 2013 at 2:54 PM, Andrew Phillips <ap...@qrmedia.com>wrote:
> Has anyone in the community ever looked at using Project Lombok[1] to help
>> simplify our source code? I stumbled across this a couple of years back
>> and thought it was pretty useful. Just never had a chance to use it with
>> anything...
>>
>
> Whilst I sympathize with the desire to avoid boilerplate, I'm not
> convinced bytecode generation a la Lombok is the way to go.
>
> Last time I used it, it was not exactly easy to get it hooked up with
> Eclipse (so that you can still use syntax completion etc. on the generated
> methods), and I'm pretty sure there are more IDEs out there in use by the
> jclouds community.
>
> In short: if you can find a way to hook it up to your *local* development
> process so that it's not visible in the committed code, that would
> certainly be interesting to hear about. But I agree with the general
> sentiment that it would be better not to introduce it into the general
> codebase.
>
> ap
>
Re: Project Lombok - Builders (and other annotations)
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Has anyone in the community ever looked at using Project Lombok[1] to help
> simplify our source code? I stumbled across this a couple of years back
> and thought it was pretty useful. Just never had a chance to use it with
> anything...
Whilst I sympathize with the desire to avoid boilerplate, I'm not
convinced bytecode generation a la Lombok is the way to go.
Last time I used it, it was not exactly easy to get it hooked up with
Eclipse (so that you can still use syntax completion etc. on the
generated methods), and I'm pretty sure there are more IDEs out there
in use by the jclouds community.
In short: if you can find a way to hook it up to your *local*
development process so that it's not visible in the committed code,
that would certainly be interesting to hear about. But I agree with
the general sentiment that it would be better not to introduce it into
the general codebase.
ap