[cdi-dev] About JSR 330.Next and CDI 2.0

[Kito Mann]

My $0.02 is that it's worth the effort to evolve JSR-330 for the community
as a whole. I've been on projects where they tend to use those annotations
even in a CDI environment, and it makes it much easier to switch between
Spring and CDI if necessary.


On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> 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
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/dc223d88/attachment.html