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

[Werner Keil]

I guess with only 5 or 6 annotations (and that's all the JSR consists of;-)
if changing/improving only one or two of these was what's needed, this
could be easiest as MR, otherwise 330 is history as it would require a new
JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there,
I don't think it can move to a newer version of the JCP:
https://jcp.org/en/resources/guide-maintenance#2_7

The trouble is, both Spec Leads seem unresponsive or no longer around (Rod
Johnson left Pivotal, Pivotal in its current form does not even seem JCP
member and VMware may not be able or interested to step in for them) maybe
Pete knows best if Bob was, as until JSR 364 or even a new version of the
JSPA are finalized he could probably do it if he wants and has the time for
this right now (especially if another JSR like CDI 2 depends on it, that
can't be delayed even if this JSR may technically still be unaffected by
JCP 2.8+)

Except for active corporate members Oracle, Red Hat or IBM the whole EG
practically disintegrated. Doug Lea and Tim Peirls may be involved
elsewhere (mostly OpenJDK from all I heard) but they have not been active
in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead
in the first place, so it is unlikely under the current circumstances it
will play an active role. Jason VanZyl and Maven I know they at least use
JSR 330 quite a bit, so they should at least be interested in its future
direction. Thoughtworks I don't recall them to be involved and Martin
Fowler himself told me of his "allergy" against such form of
standardization, so I would not count on them here either.

So assuming a separate @Inject spec shall be maintained there are 3 options:

   1. Bob Lee (or the other Spec Lead) responds in a timely manner to
   contact attempts by Antoine and ultimately the PMO (who needs to handle
   such situations) in which case a simple MR was possible
   2. A replacement of Maintenance Lead, along the lines of
   https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the
   case for an MR, but should work pretty much the same way here, so the main
   candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM
   or Oracle for most part;-) If such condition can't be resolved, both PMO
   and JCP EC would be able to help find a suitable replacement, too
   3. A whole new JSR is filed. Although it is often the case that the Spec
   Lead(s) are the same, that is not necessary, especially if the old ones
   moved on or can't do this any more right now.

HTH,
Werner


On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann <kito-public at virtua.com> wrote:

> 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/6b6f0fd2/attachment.html