limpb...@gmail.com
unread,Jan 23, 2009, 12:22:03 AM1/23/09Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to JSR-305: Annotations for Software Defect Detection
We do some null-handling stuff in Guice. If the user wants to inject a
null, Guice will explode unless the injected field or method has
@Nullable. Currently our code is a little naive and a little clever:
if there is any annotation whose simple name is "Nullable", then we
treat the field or parameter as nullable. This means that we support
the Google Collections @Nullable and the JSR-305 annotation
simultaneously.
Unfortunately, these @Nullable rules are dumber than the JSR-305
rules. For example, we don't allow nullability to cascade from
inheritance, or containment. So if your entire package supports null-
free-for-all, Guice will still insist on an @Nullable tag on each
field or parameter.
Perhaps as a part of the JSR 305 spec you could expose this
information via reflection? Perhaps something along the lines of these
APIs:
class Field {
boolean isNullable();
}
class Method {
boolean isParameterNullable(int index);
}
class Constructor {
boolean isParameterNullable(int index);
}
The boolean might not be sufficient, but I think the idea is clear. I
imagine this would be useful for a variety of APIs, especially those
that reflectively invoke methods.
Thanks!
Jesse