Allow injected member to declare that null is acceptable

[GoogleCodeExporter]

We must allow for injection of null.  User demand is loud and clear, and if
you don't like it, you don't have to use it.

It would be great to just expand the meaning of @Inject(optional=true), but
that leaves you no way for some method/constructor parameters to be
nullable while others aren't.

Probably we should introduce a new annotation like @CanBeNull, and every
place of injection that is willing to accept a null must use this
annotation.  We could also require that any Provider that might return null
must also use this annotation on its get() method, but I'm not sure whether
we could reasonably enforce that types provided by can-be-null providers
can only be injected into can-be-null injection points.  That may be trying
to be too smart, and it may not always make sense.

Original issue reported on code.google.com by kevin...@gmail.com on 6 Jun 2007 at 3:37

[GoogleCodeExporter]

Another suggestion:

bind(SomeObject.class)
    .annotatedWith(CanBeNull.class)
    .toProvider(NullProvider.class);

That way we can choose the annotation, or even leave it out.

Original comment by robbie.v...@gmail.com on 16 Jul 2007 at 2:45

[GoogleCodeExporter]

What about just reusing @Nullable from JSR-305/IntelliJ ?
http://groups.google.com/group/google-guice/browse_frm/thread/1581ec0c1fb4cc68/c
3b894b7a92207b4

Just give me the go-ahead, I'd love to implement this (and I need it).

Original comment by limpbizkit on 22 Aug 2007 at 12:16

[GoogleCodeExporter]

Implemented!
Now injection points can be annotated as @Nullable, and they can be injected 
with null without error.

Consequences:
- bind(Foo.class).toInstance(null) is not an error anymore. This violated some 
other assumptions about 
constants, but I've cleaned those up.
- scopes should support null as a regular value. Code like "if (map.get(key) == 
null)" may be problematic.
- Guice doesn't include its own @Nullable annotation, but can piggyback on any 
@Nullable annotation type 
whose simplename is "Nullable".

My implementation adds a new method, InternalContext#sanitize() that all 
InternalFactories should call on 
their return values. The method is a no-op for non-null values.

I'm going to try this out with the large Guice-using codebase that I have 
access to, to try and find other 
potential issues.

Original comment by limpbizkit on 25 Aug 2007 at 8:29

• Changed state: Started

[GoogleCodeExporter]

Uh oh, it looks like org.jetbrains.annotations.Nullable doesn't have runtime 
retention. This means that the code 
doesn't work with that version of Nullable. Uh-oh...

Original comment by limpbizkit on 26 Aug 2007 at 7:13

[GoogleCodeExporter]

I've posted to the JSR 305 lists describing how Guice benefits from runtime 
retention
for @Nullable. Currently I believe they're swaying towards runtime retention 
anyway:
http://groups.google.com/group/jsr-305/browse_thread/thread/99cb455eedf21801

Hopefully they commit to runtime retention! And if they do, we should be able to
persuade IntelliJ to do likewise...

Original comment by limpbizkit on 27 Aug 2007 at 5:56

[GoogleCodeExporter]

Yeah, @Nullable would be a lot less useful w/o runtime retention.

Original comment by crazybob...@gmail.com on 27 Aug 2007 at 6:19

[GoogleCodeExporter]

Posted to Jetbrains' forum:
http://intellij.net/forums/thread.jspa?threadID=275503

Original comment by limpbizkit on 30 May 2008 at 7:05

• Added labels: Milestone-Release2.0
• Removed labels: 1.1

[GoogleCodeExporter]

If anyone's interested, we've got JetBrains' blessing to patch the @Nullable 
annotation:
  http://intellij.net/forums/thread.jspa?messageID=5215656

At a risk of offending users of other IDEs, we could post this on our downloads 
page. JSR-305 is probably our 
best bet in the longrun.

For now, Guice will recognize any annotation whose simplename is "Nullable".

Original comment by limpbizkit on 5 Jun 2008 at 6:43

• Changed state: Fixed