[cdi-dev] CDI-127: Support for Enums

[Pete Muir]

https://issues.jboss.org/browse/CDI-127

I have written up a proposal for how to add support for enums:

================================================

Notes
-------

Enums are somewhat different to normal classes, as Java guarantees that any instances are singletons. Therefore we cannot treat them as classes. Furthermore, do we want to support them as beans, allowing them to be injected?

Differences are:

* No callback on instantiation, when do we inject?
* Shared between deployments as singletons, how do we handle dependent scoped injections?
* We do not control instantiation, cannot perform constructor injection


Proposal
------------

We should support enums as non-contextual objects, performing field and method injection only. Enums should be assumed to be injected only after the application is fully initialized for portability.

If an enum is on a shared classloader, any injections should correctly resolve to the deployment of the calling context. In other words, if a shared library or installed library has an enum A:

    enum A {

       FOO, BAR;

       @Inject B b;

       String getName() {
          return b.name;
       }
    }

where B is a class defined in the shared library

    @ApplicationScoped
    class B {
   
       String name;
    }

Then assuming that the name has been set to Pete in deployment 1, and Marius in deployment 2, when the enum A is used in deployment 1, the method getName() should return Pete, and in deployment 2 it should return Marius.

================================================

In my opinion, it's fairly obvious that supporting only field and method injection for enums makes sense, as does injecting them at application startup. This proposal also won't allow you to inject enum instances into other beans (this seems to go against the point of enums to me).

How we handle enums in shared libraries (as the instances are shared between all apps then) is tricker, and the only way I can see to handle this is to 

a) say this results in non-portable behavior - punt on it
b) require that the container can bridge to the correct calling context

I believe it's possible to implement (b) in a non-pathological fashion, but would love to hear from Stuart, Siva, and the OWB team on how this would work for JBoss AS, GlassFIsh etc.

Thoughts?

Pete