Re: [DISCUSS] Static analysis of statics
On Wed, Feb 13, 2019 at 9:03 AM Dan Smith wrote: … > I can switch them to @MakeReferentImmutable if that makes more sense. > > -Dan I think you understand my concerns. I trust you to decide what's best.
Re: [DISCUSS] Static analysis of statics
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 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. >
Re: [DISCUSS] Static analysis of statics
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.
[DISCUSS] Static analysis of statics
Hi devs, We've expressed interest in getting rid of singletons and allowing multiple copies of cache to run in the same JVM. I'd like to get a handle on what static state we have. As a first step I'd like to introduce a few annotations and some static analysis to find all of our mutable static fields. I intend to add a PMD rule to look for mutable static state, and some new annotations to the fields we have right now to indicate what we want to do with them. More details are in this PR - https://github.com/apache/geode/pull/3178 Are people ok with adding these additional annotations? You will see static fields be marked with things like @MakeNotStatic or @MakeImmutable until we get them all cleaned up. -Dan
