-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 <[email protected]>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 [[email protected]] > Sent: Monday, November 11, 2013 1:11 PM > To: [email protected] > 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/ >
