[JSR308] A little prototype experience...

Arnout Engelen arnouten at bzzt.net
Sat May 5 15:05:35 EDT 2007


Neal Gafter wrote:

> On 5/5/07, *Perry James* <perry.dsrg at gmail.com 
> <mailto:perry.dsrg at gmail.com>> wrote:
>
>     Runtime checks should be emitted to throw a cast exception if null
>     is ever cast to non-null.  This would prevent a reference declared
>     to be non-null from ever becoming null
>
Alternatively, instead of emitting runtime checks, another way to go 
could be to allow/require the programmer to write code like:

void method1 (@Nullable String s) {
  if (s != null) {
    // the tool can infer statically that 's' is non-null at this point
    method2(s)
  }
}
void method2(@NonNull String s) { ... }

(of course, this /is/ a runtime check, but explicitly written down by 
the programmer instead of somehow generated)

> Unless it is a field (static or instance), in which case it starts out 
> as null no matter how it is declared.

Indeed there are a lot of interesting design choices when building a 
tool that leverages those annotations: if I remember correctly ESC/Java2 
and Spec# resolve this specific case by defining the semantics of their 
'nonnullability' of fields as something like 'only non-null assignments 
are allowed to this field, and we guarantee that something will have 
been assigned to it after any constructor for this object has finished'. 
Of course, this opens up an entire following (interesting) can of worms*.

I do think, however, that we're drifting off-topic here: the main point 
is that we can imagine (several different kinds of) useful tools being 
developed that make use of such annotations.


Arnout

* e.g. http://citeseer.ist.psu.edu/fahndrich03*declaring*.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070505/7c2cd8a1/attachment.htm


More information about the JSR308 mailing list