AutoValue is awesome and reduces a lot of boilerplate, and yes it has other advantages as well. Unfortunately, there is no tool that can solve everything - our requirements are too specific. For example, as we discussed before, builders are not supported in AutoValue (they might be supported eventually but despite the multiple issues filed, their current documentation suggests otherwise) - and that's ok, AutoValue serves a specific purpose and does it well.
Immutables addresses a different type of boilerplate. I am not suggesting the two annotation processors should be used together, but they can be used to solve different problems. They also work the same way, and provide a set of features that seem to closely match a set of issues we face in jclouds. I don't think I should play advocate for Immutables any further - I just don't know the project well enough. Overall, it seems an even better solution would be if AutoValue supported immutable types with builders. Adrian mentioned that might be something that will be available eventually - it seems they are still discussing it internally? Thanks! ________________________________________ From: Adrian Cole [adrian.f.c...@gmail.com] Sent: Monday, November 17, 2014 10:01 AM To: dev@jclouds.apache.org Subject: Re: Immutables.value I am not in favor of this. We should get more experience with what we have first. At least in google, azure, and docker, auto is fine and has reduced thousands of lines of code. More comments inline. On Mon, Nov 17, 2014 at 5:34 AM, Zack Shoylev <zack.shoy...@rackspace.com> wrote: > Since we have started using autovalue, I would like us to explore using > http://immutables.github.io/ (Immutables) as well. > From what I see using the standalone version might work similar to autovalue > (it does require guava 18 and java 7 to run, but generated code shouldn't). First, coordinating multiple annotation processors doing different things is a recipe for confusion. Moreover, autovalue not only helps with boilerplate, but also decreases the surface area of maintenance by forbidding squirrelly practice like inheritance in value types. Immutables, however, has an extremely wide interface, which is the opposite. Even if Immutables common seems to have no deps, features you are hinting at do. It is an easy scope creep as unlike auto, immutables is not single purpose https://github.com/immutables/immutables/blob/master/dependency/technology/pom.xml Finally, Immutables is largely one developer with very few people contributing code. Even with few developers, google projects are far better documented and likely to live longer. We cannot directly compare a largely single-author annotation processor with something like auto. > In the openstack world (and other places) it would be very useful as it will > continue to allow us to provide users with a way to generate complex > immutable objects which can then be serialized and sent to the service, > avoiding heavy use of binders and options classes. Jeremy sugeested I look > into it, and it seems very promising. Of the 100 features of immutables, it is true that jackson support is one of them. However, we don't actually support jackson, so this is just > Some work might have to be done (with the jclouds gson) to make sure this > works consistently with custom name serialization and to make sure everything > is consistent with autovalue. AutoValue classes will still be used to parse > json as returned by the service. > Thoughts? Seems like a new mess to clean up. If openstack ends up solely in its own repo, it may make sense there, but I strongly oppose adding another similar code generator for value types.
