[JSR308] Default annotations

[Tom Ball]

Tom Ball wrote:
> Neal Gafter wrote:
>> On 2/24/07, *Michael Ernst* <mernst at csail.mit.edu 
>> <mailto:mernst at csail.mit.edu>> wrote:
>>
>>
>>     Specifying a default for annotations can reduce code size and 
>> (when used
>>     carefully and sparingly) increase code readability.
>>
>>     For instance, Figure 1 of the JSR 308 proposal (which is available at
>>        http://pag.csail.mit.edu/jsr308/java-annotation-design.pdf
>>       http://pag.csail.mit.edu/jsr308/java-annotation-design.html
>>     ) uses @NonNullDefault to avoid the clutter of  5 @NonNull 
>> annotations.
>>     But it would be nicer to have a general mechanism, such as
>>
>>       @DefaultAnnotation(NonNull.CLASS,
>>     locations={ElementType.LOCAL_VARIABLE})
>>
>>     It would be even better to be able to specify the arguments to the
>>     defaulted annotation, as in
>>
>>       @DefaultAnnotation(@MyAnnotation(arg="foo"))
>>
>>     but that is not currently possible -- we would have to extend the 
>> Java
>>     syntax in a new way to accommodate it.
>>
>>
>>     Should the issue of default annotations be taken up by us (JSR 308)
>>     or by
>>     JSR 305?  (Recall that JSR 305 is defining a set of annotations,
>>     along with
>>     their semantics. For instance, it is JSR 305's role to decide
>>     whether Java
>>     programmers will write @NonNull or @Nonnull or @NotNull, and what it
>>     means
>>     when they write it.)
>>
>>
>> No, I do not think that the issue of default annotations should be 
>> taken up by us or by jsr305.  I don't see it as being in scope for 
>> either JSR.
> 
> I disagree:  from my discussions with customers who have large existing 
> source bases, there is a strong desire to have tools that can find 
> quality issues, which is coupled with a strong resistance to massive 
> source edits to support such tools.  Default annotations give such 
> customers the ability to set a general policy (such as no null parameter 
> or return values), which can be excepted on a case-by-case basis.
> 
> Besides the much smaller source deltas, an advantage of this approach is 
> that exceptions to expressed policies are called out, instead of 
> compliance.  For example, say you have a large class where all 
> parameters but three should never be null.  Which would you prefer in a 
> code review:  a large class where every parameter but those three was 
> annotated with a @NonNull, or just @Null on those three parameters?  The 
> reason I'd prefer the latter is because the @Null annotations are more 
> easily detected by readers than the absense of @NonNull, so I can 
> quickly focus on getting justifications for those exceptions.
> 
> Another advantage is that default annotations leverage the natural 
> laziness in all programmers (myself included!).  If there is less typing 
> to create a new method which doesn't need any annotations because it 
> adheres to the project's default policies, that's usually what will get 
> written.  Take Effective Java's recommendation to always return empty 
> collections instead of null for example.  Today, it is easier to write 
> "return null;" in the heat of development, and worry about fixing it 
> later (if ever).  If a default annotation required you add a @NonNull 
> annotation which the build would flag since it hasn't been approved 
> (NetBeans has a similar build process to block unintentionally 
> introducing new public API) and you don't care one way or the other, 
> then typing "return Collections<Foo>.emptyList-Map-Set();" is much 
> easier and therefore more likely to happen.  Reducing common bugs like 
> this in the world's set of Java source increases its value, which can 
> determine ten or more years down the road what language we will be using.
> 
> I realize that the JSR 305 and 308 discussion lists are top-heavy with 
> type-theorists and the like, but Java's success was due not to its 
> language purity but to its pragmatic balance between type safety and 
> ease-of-declaration.  Default annotations are an example of a feature 
> that the theorists might not like, but pragmatists will embrace.
> 
> Tom
>