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.
