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

Thu Jul 3 09:37:33 EDT 2014

Interesting. Well unless he's self-employed freelancer now, that makes it
even more unpredictable as to what his status as JSR 330 MR (or possible
Spec Lead of a successor) is or would be...
(unless he plans to return to Google or join let's say Red Hat;-)

On Thu, Jul 3, 2014 at 3:20 PM, Pete Muir <pmuir at redhat.com> wrote:

> Bob did leave square a few months ago.
>
> On 3 Jul 2014, at 14:17, Werner Keil <werner.keil at gmail.com> wrote:
>
> > I know, back then it was sort of legitimate, see Greg Luck and 107, but
> the whole idea of JCP.next and JSRs between 148 and 164 is to ensure,
> "Individual Members" contribute only on their own behalf, and in most cases
> (especially for the Spec Lead Role, it might be a bit less critical if you
> just submit a pull-request every once in a while or contribute via Gerrit,
> etc.) that is a conflict if he or others work for another company like Bob
> does at Square now.
> >
> > On Thu, Jul 3, 2014 at 3:05 PM, Pete Muir <pmuir at redhat.com> wrote:
> > BTW it’s actually Bob Lee who owns JSR-330, he took it with him
> personally when left Google.
> >
> > On 3 Jul 2014, at 10:02, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
> >
> > > FYI - I've sent a note to the various folks from Google, Pivotal et
> al, I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure
> they'll either join this mailing list / discussion or we'll quickly find
> out there's no appetite and we can move on.
> > >
> > > Cheers,
> > > Martijn
> > >
> > >
> > > On 3 July 2014 09:51, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
> > > Hi All,
> > >
> > > To be blunt, this is a social/community issue - not a technical one.
>  We simply need to get hold of the folks at Pivotal, Google (and other 330
> EG members) and get them around the virtual table.  If they subsequently
> aren't interested then fine, you should forge your own path.
> > >
> > > There's an absolute mega ton of 330 based DI code out there and 330
> compliant containers, if CDI 2.0 wants to be the defacto std going forwards
> it simply can't afford ignore that.
> > >
> > > @Antoine - let's put our heads together and see who we need to get
> hold of in the 330 group, I think CDI 2.0 has strong merits and should be
> explored.
> > >
> > > @Werner - your comments about Bob's commitment (considering what he's
> done for the tech community at large, let alone Java) are highly
> inappropriate, please refrain from personal attacks on this or any other
> public forum.
> > >
> > >
> > > Cheers,
> > > Martijn
> > >
> > >
> > > On 3 July 2014 09:02, Antonio Goncalves <antonio.goncalves at gmail.com>
> wrote:
> > > > 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?<329.gif>)
> > >
> > > 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > >
> > >
> > > _______________________________________________
> > > 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/814a581a/attachment-0001.html 