Just one more thing.

On Tue, Jan 16, 2018 at 10:56 AM, Paul King <paulk@asert.com.au> wrote:
1) for me, if you have to explain a name better, then it is already a bad name. Intuitively suggesting the correct interpretation to another developer, without requiring him to thoroughly read through the documentation, is the art of picking good names (which imho Groovy overall does a good job at).
With regards to @KnownImmutable, "someone (the compiler or the developer) knows" is even more confusing. If it is in fact irrelevant who knows it, why is there a "Known" in the name in the first place ? And why is therefore e.g. @IsImmutable not a better name (it could also carry a parameter which can be true or false, with false allowing a developer to express that a class is definitely not immutable (even if it might look that way on first glance; e.g. effectively blocking or issuing a warning in certain parallel execution scenarios)).

We have since the introduction of @Immutable used the knownImmutable and knownImmutableClasses annotation attributes and people seem to grok what they mean. This is a very similar use case. I think it would be hard to justify renaming @KnownImmutable without renaming the annotation attributes as well.

I guess I missed one point. There are known immutable classes in Java, e.g. String, Integer,  java.awt.Color, java.net.URI, java.util.UUID, etc. @Immutable processing knows about them but you can extend the list of classes with knownImmutableClasses=[...] and we are suggesting a further extension, you can annotate classes with @KnownImmutable.

Cheers, Paul.