Requirements
From Arnout Engelen
We have already highlighted some important aspects of the existing tools, and have started focussing and describing why we're choosing this focus for this research. Some code examples are in place.
TODO: Propagation needs better examples.
Contents |
[edit] Acceptability of annotations in general
[edit] Percieved goal of annotation
There are 2 main schools of thought about the value of annotations: some see adding annotations merely as a way of reducing false positives when running analysis tools (such as FindBugs). The other approach, which we are more attracted to, sees annotations as a way to more exactly specify the design of the application, and allow the checker to warn about 'more' possible problems.
[edit] Annotation burden
A common complaint about annotation is the extra burden it lays on the programmer. Mitigating factors:
- ESC/Java is more intelligent than a traditional typesystem, and thus requires less annotations while giving a real value-added.
- A concise syntax can be chosen, such as the !Object/?Object annotations in Nice and Spec#.
- In the computer languages design community, the static versus dynamic typing discussion is far from resolved. A quite interesting approach that has received positive remarks from both sites is the idea of a 'optional pluggable type system' as described at http://lambda-the-ultimate.org/node/1311. Nullness annotations seem to fit into this model quite nicely.
[edit] Iterative nature
Because interaction is inevitable, the tool must be able to support this well. This among other things means:
- it should leave manually added annotations alone.
- it should support .spec files
- it the check/edit/check cycle should be short (and if it calls the checker, it shouldn't (have to) do that too often)
