How records would fit into Google's codebase

[Vicente Romero]

Hi Alan,

Thanks for sharing this doc,

On 4/3/19 2:53 PM, Brian Goetz wrote:
> Thanks Alan for this good work; grounding the analysis in real codebases is a valuable tool for validating our theories.
>
> Some comments inline.
>
>> One additional thing I would have liked to do is to somehow find classes which were “almost” records, but which ended up not using @AutoValue. A survey of these might help us decide what changes we could make to increase adoption, or simply confirm for us, “Yes, it’s a good thing we included restriction X, because this class is a bad candidate for a record, but without restriction X it might have become a record”. Alas, unsurprisingly, it is much easier to find actual @AutoValue classes than to design a heuristic for “almost an @AutoValue”, and so I have not done this.
> This is desirable, but as you point out, hard to do — you can’t grep for “@WishIWasAnAutoValue”.  Often the best we can do is recall specific instances of coding in the past when we tumbled off the cliff, and try to reconstruct what was going on.

on this respect you can probably find useful class: 
com.sun.tools.javac.comp.Analyzer, we have used to find things like what 
initializations could be diamonds or lambdas, etc. Most recently it was 
used to find out what explicit variable declarations could be 
substituted by `var`. This analyzer is very powerful. I can help 
providing an analyzer that you can test on your code base. Could you 
please share some of the patters of those could-have-been-autovalue 
classes?
>
>> * Records can expect to be about as common as enums
>
Thanks,
Vicente