geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Smith <>
Subject Re: [DISCUSS] Static analysis of statics
Date Wed, 13 Feb 2019 17:03:29 GMT
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

I agree that an @Immutable field should be final and the referent is

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.


On Tue, Feb 12, 2019 at 3:18 PM Bill Burcham <> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message