Support for empty collection injection when there is no injection candidates

[GoogleCodeExporter]

I post a new issue as it seems I can't reopen an existing issue.
So don't close this as a duplicate, but please answer this issue correctly.

You don't provide any consistent reason, neither #1 nor in #20, to not inject 
empty collections when one knows there may not be any injection candidate.

For instance:

interface StuffContributor {
}

class StuffUser {

  @Inject
  private Collection<StuffContributor> contributedStuff;

  void aMethod() {
    // Externally contributed stuffs
    for (StuffContributor contributor : contributedStuff) {
      // ...
    }
  }
}

Original issue reported on code.google.com by ptit...@gmail.com on 13 Dec 2011 at 2:56

[GoogleCodeExporter]

I think the reason you get nulls instead of an empty collection is that null is 
more informative, namely, no injection was defined. This is pretty standard 
across all DI frameworks. I used to think the way you think about this, but 
changed my mind to consider the null an important data point. Either I got the 
wiring wrong, or someone using it got the wiring wrong.

If it is an optional wiring, you would be wise to log the null and continue on 
so people know there's an injection point available (also, add an 
@Named("contributedStuff" to the injection point so people know what to call 
it.)

Original comment by m...@thebishops.org on 25 Mar 2012 at 3:36

[GoogleCodeExporter]

This is a completely valid use case. I am writing a framework in which I 
provide a default implementation of an interface, but I want to be able to add 
customised implementations for various circumstances so I have a Manager class 
that I want to inject the set of all customised implementations into.

The problem is that if I put @Inject on the Set, and there are no custom 
implementations, an exception is thrown at runtime. This is not helpful. I want 
an empty collection or, at worst, null.

Original comment by rjs...@gmail.com on 5 Sep 2012 at 10:32

[GoogleCodeExporter]

An empty collection is the most useful scenario when there are no possible 
elements for the collection.

null could mean that injection is just not working and a null pointer of use 
would be picked up immediately by running the tests

with an empty collection if its an error for it to be empty then you could 
assert in @PostConstruct but thats the decision of the code not the IOC 
framework - which could add validation metadata to do this automatically

Original comment by mich...@redengine.co.nz on 5 Sep 2012 at 11:17

[GoogleCodeExporter]

This is implementation-specific behavior. Talk to Guice or Weld or whichever 
project you're using to configure your container. I know Guice can do this.

Original comment by limpbizkit on 6 Sep 2012 at 12:56

• Changed state: WontFix

[GoogleCodeExporter]

We want declarative optional injection!
@Inject(optional = true)

Is this really the "home of JSR-330: Dependency Injection for Java" as it is 
told on the front page ??

The only thing you are doing by rejecting this feature (when so many tickets 
were open for it) is that you prevent @Inject wide adoption. We decided at work 
to stay to proprietary @Autowired because @Inject is not mature! I can't 
understand why you all are so stubborn and can't give any real/rational 
explanation for the denial of the importance of such a feature.

Original comment by ptit...@gmail.com on 6 Sep 2012 at 1:11

[GoogleCodeExporter]

I accept that it's an implementation detail, but doesn't it concern you that 
implementors are free to interpret injection into collections in so many 
different ways? The spec lacks any guidance for how to handle this, it clearly 
hasn't been considered.

Look at it this way, if I write a piece of framework code that says:

@Inject
Collection<Listener> listeners;

I have no way of knowing at run time if this is going to be null, an empty 
collection, or if it will throw an exception. It's all down to which provider 
the client of my framework chooses to use. That's unacceptable.

Original comment by rjs...@gmail.com on 6 Sep 2012 at 8:14