Issue 25 in atinject: Support for empty collection injection when there is no injection candidates

[atin...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 25 by ptit...@gmail.com: Support for empty collection injection
when there is no injection candidates
http://code.google.com/p/atinject/issues/detail?id=25

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) {
// ...
}
}
}

[atin...@googlecode.com]

Comment #1 on issue 25 by m...@thebishops.org: Support for empty collection

injection when there is no injection candidates
http://code.google.com/p/atinject/issues/detail?id=25

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.)

[atin...@googlecode.com]

Comment #2 on issue 25 by rjs...@gmail.com: Support for empty collection

injection when there is no injection candidates
http://code.google.com/p/atinject/issues/detail?id=25

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.

[atin...@googlecode.com]

Comment #3 on issue 25 by mich...@redengine.co.nz: Support for empty

collection injection when there is no injection candidates
http://code.google.com/p/atinject/issues/detail?id=25

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

[atin...@googlecode.com]

Updates:
Status: WontFix

Comment #4 on issue 25 by limpbizkit: Support for empty collection

injection when there is no injection candidates
http://code.google.com/p/atinject/issues/detail?id=25

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.

[atin...@googlecode.com]

Comment #5 on issue 25 by ptit...@gmail.com: Support for empty collection

injection when there is no injection candidates
http://code.google.com/p/atinject/issues/detail?id=25

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.

[atin...@googlecode.com]

Comment #6 on issue 25 by rjs...@gmail.com: Support for empty collection

injection when there is no injection candidates
http://code.google.com/p/atinject/issues/detail?id=25

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.