Hey, I'd say this kind of pattern falls in that last 5% of cases where static analysis tool authors are justified in saying "Well, yeah, instances of that class are technically immutable, but meh, you're doing weird stuff". That may not be a good enough view to take for a compiler, but I think it's fair and useful for "ACME Static Tool". The most common cases (e.g. accidentally adding a setter method) are where most of the benefits lie. Also, in this domain, a false positive is a much better prospect than a false negative.
IMO there's enough of an understanding of what's intended with @Immutable, that we should just agree to use one annotation, and let the tools and knowledge revolve around it. But yeah, I can see how that would be really messy :-) Regards, Graham On Oct 12, 5:25 pm, Reinier Zwitserloot <[email protected]> wrote: > Perhaps now is a good time to show off this little snippet just to > highlight how nigh-impossible it is to track immutability: > > public class SeeminglyImmutablePointer { > private static final Map<SeeminglyImmutablePointer, Object> map = > new MapMaker().weakKeys().makeMap(); > > public void set(Object val) { > map.put(this, val); > } > public Object get() { > return map.get(this); > } > > } > > Note that @SEF and @Unchanging have no problem with this snippet; a > compiler can clearly determine that set is not SEF, and that get() is, > and it can also determine that set() is unchanging (trivially - any > method with return type void will have that property), and that get > isn't. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
