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

Thu Jul 3 04:02:43 EDT 2014

> 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)

Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 ;o)

But on the other hand, I think there is so much work to be done around CDI
2.0, parts, and taking those parts to other specifications that battling
with JSR 330 might be time consuming. I would go for scenario 1.... and
cross fingers

On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil <werner.keil at gmail.com> wrote:

> Dear Antoine/all,
>
> Thanks for the detailed overview and trying to reach out to the former
> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354,
> since Bob Lee is officially in his EG, but has practically never provided
> input there either (like we tend to see sometimes from others considered
> "Rock Stars" of the Java Community but since then seemingly resting on
> their laurels or just too busy counting their stock options?[?])
>
> Given CDI already was the public perception of "javax.inject" for most
> parts, I don't necessarily see that it had to be an MR to the original JSR,
> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could
> probably check with the PMO how to handle a case where the Maintenance Lead
> of a JSR was not in the position to continue. I last met Jürgen Höller
> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I
> guess he or the likes of Josh Long could be best to speak to. Happy to get
> you in touch with them if you want.
>
> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was
> there (I remember him from conversations where Mike Keith and I took part
> in synergy discussions between 330 and CDI 1.0) at the time could also help
> you with this.
>
> In theory this could also be part of a new JSR (CDI 2) as long as none of
> the enhancements you have in mind break the existing API of JSR 330. The
> scope of CDI 2 to work in an SE/standalone or more lightweight environment
> than Java EE environment raises a good question of package names like " javax.enterprise.inject.*"
> So maybe there is room for synergies in a package namespace other than
> "javax.enterprise" at least for new things you have in mind.
>
> Kind Regards,
>
>  Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>
> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social |
> #DevOps
>  Skype werner.keil | Google+ gplus.to/wernerkeil
>
> * Developer Week: 14/15 Jul 2014, Nürnberg, Germany. Werner Keil, JCP EC
> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class
> Continuous Delivery", "JSR 363 and IoT" (GER)
>
> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member,
> JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and
> the Internet of Everything"
>
> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC
> Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or
> FOE"
>
> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC
> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class
> DevOps", "JSR 363"
>
> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany.
> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache
> DeviceMap" (GER)
>
>
> On Wed, Jul 2, 2014 at 10: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
>>
>>
>>
>

-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/a34e1a7e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 329.gif
Type: image/gif
Size: 257 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/a34e1a7e/attachment-0001.gif 