I was basing this off of https://github.com/google/auto/issues/111 https://github.com/google/auto/issues/155 https://github.com/google/auto/issues/150 (my issue)
and in the docs "Many users have asked for AutoValue to generate a builder class. We explored this idea deeply. It is much more complex than it seems, especially because field values often need validation. We also feel that, unlike the simple value objects themselves, there is a lot of natural variation in how builders for different types should be written, and it would be a disservice for us to start coercing everything into the same mold." This is pretty much it. I think you can see why I was confused. Thank you for clearing things up a bit, though! ________________________________________ From: Adrian Cole [adrian.f.c...@gmail.com] Sent: Monday, November 17, 2014 11:25 AM To: dev@jclouds.apache.org Subject: RE: Immutables.value Zach, I don't understand how you have doubt about auto-value working on builders. Not only did I tell you, but you also raised an issue, where they also told you. Auto have also invited me to their discussion on gson support. Never mind the fact that we already have a solution for gson. Your arguments for adding another niche annotation processor for value types are flimsy with this in mind. As openstack create a lot of code, yet scarcely help with shared codebase issues, I have serious doubts the responsibility that would go with this freedom would land on the right shoulders. That's why I suggest this is quarantined if implemented at all. -A On Nov 17, 2014 9:08 AM, "Zack Shoylev" <zack.shoy...@rackspace.com> wrote: > 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. >
