Regarding @Immutable - yes it's intentionally a field annotation as well as a class annotation. The reason to make it a field annotation is that the static analysis tools aren't quite cool enough to figure out if a field is really immutable so we have to manually tell the tool that the field is immutable. For example "public static final List = Collections.unmodifiableList(X)" might immutable but it's hard to deduce that.
I agree that an @Immutable field should be final and the referent is immutable. Also agreed - @MakeImmutable should also apply to classes. I'll fix that. I did an earlier pass where I made as many fields as I could final - so most of the remaining cases would be your @MakeReferentImmutable case. I can switch them to @MakeReferentImmutable if that makes more sense. -Dan On Tue, Feb 12, 2019 at 3:18 PM Bill Burcham <bburc...@pivotal.io> wrote: > I think the @Immutable anno in *Java Concurrency and Practice* is a class > annotation—not a field one. > > Looking at that PR, it looks like this @Immutable anno is usable both on a > type (class) and on a field. > > Is that an oversight? If not, then what does it mean? Does @Immutable on a > field mean both: > > • the field is final > • the object referenced by the field is immutable > > ? > > Looks like in the current PR @MakeImmutable applies only to fields—not > classes. I imagine that's an oversight. > > My quick thought is that these two annotations, in the spirit of *JCP*, > should be type/class-level and not field-level, > > Immutable > MakeImmutable > > and that perhaps we could have some field-level annos like: > > MakeNonStatic > MakeFinal > MakeReferentImmutable - change the type referenced by this field to be an > immutable one > > In this way your MakeImmutable field anno is teased apart into two: > MakeFinal, MakeReferentImmutable. The possible benefit is that the two > annos can be used either separately or together to cover 3 situations > instead of just one. >
