Reflective access to 305 data?

Skip to first unread message

Jan 23, 2009, 12:22:03 AM1/23/09
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

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

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.


Reply all
Reply to author
0 new messages