Dependency Injection Wishlist

Work in progress list of enhancements to javax.enterprise.inject and javax.enterprise.context for the CDI 1.0 maintenance release and CDI 1.1.

Clarify that scope types should not have members

The spec should mention that @ScopeType annotations should not have annotation members. Perhaps this should be a definition error. javax.inject.Scope already mentions this.

Static injection

Injection for static members has a couple of problems:

• A class can be shared between multiple applications, and the Java EE spec does not define rules for this.
• Outside Java EE, it's difficult to define exactly when a static member is injected.

Nevertheless, there are a couple of great usecases for this:

• logger injection,
• injection for entity classes, and
• injection into objects with a passivating scope.

So we do need to support something here. Perhaps it would be enough to say:

• no static injection in shared libraries, and
• static fields are injected before the very first instance of a bean is instantiated (but then static injection would not be supported for non-bean classes).

Additional ambiguous dependency resolution rules

Currently CDI is extremely dependent upon the use of qualifiers for resolving ambiguous dependencies. This is not a bad thing, since too much implicit behavior can result in difficult to trace bugs. However, we should discuss the following:

• resolving ambiguities in favor of beans in the same module, and/or
• allowing declaration of alternatives at the package or bean level, in addition to the module level.

Producer constructors

We can allow a bean to be defined by annotating a constructor @Produces, for example:

@Produces @SessionScoped @Special
Foo(@Special Bar bar) { ... }

A class with a @Producer constructor might not have a normal bean constructor.

Abstract producer methods

An abstract method or interface method could define an alias for a bean:

@Produces @Foo Baz foo(@Bar Baz bar);

is a shortcut for @Produces @Foo Baz foo(@Bar Baz bar) { return bar; }. And:

@Produces @Foo Baz foo();

is a shortcut for @Produces @Foo Baz foo(@New Baz bar) { return bar; }.

Limit scanning using beans.xml

We could allow certain packages/classes to be excluded from bean discovery using globs in beans.xml.

Allow a producer to specialize a regular bean

Currently, producers may specialize producers, and regular beans may specialize regular beans. We should allow a producer to specialize a regular bean. The following options seem to work out:

Option 1:

Add a value() to @Specializes.

@Specializes(Foo.class) 
@Produces Foo foo(@New Foo foo) { ..... }

Option 2:

Support @Specializes on any injection point annotated @New.

@Produces Foo foo(@Specializes @New Foo foo) { .... }

Allow injection of Bean object for a bean

Currently we allow injected dependent objects to inject an InjectionPoint. We should also allow beans to inject their own Bean (and Module?), and, in the case of dependent objects, the Bean of the object to which they belong (not all dependent objects are injected).

Support producers with a type variable bean type

The spec says that you can't have a type variable be a bean type. But we can in theory use InjectionPoint to overcome Java's lack of reified generics, to allow the following:

@Produces @Parameter("") 
<T> T getParameter(FacesContext fc, InjectionPoint ip) {
  Class<T> type = (Class<T>) ip.getType();
  String paramName = ip.getAnnotated().getAnnotation(Parameter.class).value();
  //get the parameter value and convert it to the right type
  ...
}

Note that we would have to think extra-hard before relaxing the complementary restriction that an injection point type may not be a type variable (since then you would need the whole stack of InjectionPoints).