Hi all,
Since the first mention of CDI 2.0 preparation work, we've received a lot of comment
about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came
up again. So let me give my point of view on this subject to have an open discussion
here.
When we started to discuss about modularity with Pete in last november, my first idea was
to go see what we could add in JSR 330 to make it a true specification that could be the
first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we
could bring basic concept we have in CDI to AtInject spec. In my mind the main features
would have been:
- Enhance the javax.inject.Provider<T> interface to bring it at the same level than
javax.enterprise.inject.Instance<T>. That would have included support for
AnnotationLiteral and TypeLiteral as well
- Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve
beans instance from outside managed beans
- Add a mechanism to get this Container from non managed beans (like we get access to
BeanManager from JNDI or CDI class)
At that time, I contacted Bob Lee without success (didn’t tried Pivotal since I don’t have
contact there). I checked with JCP what could be done if we’d like to see an evolution of
JSR 330 and the owner doesn’t care, there seems to have solutions but I let it aside since
we were in the middle of CDI 1.2 MR at that time.
Today I’m a bit torn about this point. Working on opening JSR 330 could be like opening
pandora box, since I see 2 scenarios :
1) former JSR 330 owners wake up and are ok to get for a new spec version they lead:
Knowing the history of JSR 330 vs JSR 299 I’m not sure everything we’d need would be heard
and even if the people leading this would be cooperative, a lot of discussion and
negotiation would be needed to be sure that this new AtInject wouldn’t contain features
incompatible with CDI. So it’d be very time consuming with no guarantee to get what we’d
need at the end.
2) former JSR 330 owner don’t mind others take ownership of their spec to enhance it and
we (Red Hat) are the one to take this ownership to secure CDI:
The best solution to minimize risk. But leading a new specification is a lot more work
than just deciding that we have a specific basic inject « part » in CDI 2.0. Leading a
spec is very time consuming, so it could be better on the paper but will impact CDI 2.0
new features.
To sum up, as a Java EE user (like I have been for 10 years) I’d be happy to see this
(scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to
scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0)
Your input, solutions or comment would be appreciated on this point.
Antoine