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

[Werner Keil]

Anatole,

Thanks for the input. Being a proposed Co Spec Lead of a future Config JSR
(which timewise should correlate with CDI 2 more or less, too;-) it's worth
to get you involved which is (aside from your own experienc with both
Google and the not so responsive behavior by Bob Lee) why I invited you to
this discussion.

As mentioned, we need more people like yourself, Antoine, etc. but where
former players or Spec Leads can still act as such it would certainly not
be bad either.
Google while its legal or IP team could hesitate to allow offcial
contribution at this stage is other than Red Hat the only legitimate
candidate to pick up its old JSR 330 or create a separate new "@Inject" JSR
as per 1)

Bob Lee is a permanent employee of Square and therefore not able to
contribute IP or act as Spec Lead on behalf of Google or as Individual. The
last case (those in this list at least casually joining EC or JCP.next
calls will know;-) was JSR 170, JCache. There to give the Spec Lead Greg
Luck an independent touch, Co Spec Lead Oracle allowed him to remain
"Individual Member" despite being permanent employee of at least 2
companies since then, but that was a very old "Legacy JSR" just look at the
number.

If either Pivotal or Square joined the JCP they could revive the old JSR,
otherwise only a similar dodgy deal like with 107 was imaginable, but it
would leave a bad taste and considering how many other JSRs, similar Open
Source projects (e.g. Eclipse, Maven,...) and commercial products use such
technologies, same with CDI, it seems like Oracle Legal, PMO and other
involved players including Red Hat would rather prefer a clean slate here
than risk something worse than we see between Oracle and Android at the
moment.

Cheers,
Werner

On Thu, Jul 3, 2014 at 11:58 AM, Anatole Tresch <atsticks at gmail.com> wrote:

> Hi All
>
> Same from my side. My experience eg with Google guys has been very
> positive and constructive. I would expect there is a real chance to turn
> the former conflict into a widely accepted standard, which would be very
> valuable for any future evolution in the Java eco-system.
>
> Best
> Anatole
>
> -
> Anatole Tresch
> Glärnischweg 10
> 8620 Wetzikon
> Tel +41 (43) 317 05 30
> -
> Send from Mobile
>
> Am 03.07.2014 um 11:02 schrieb Martijn Verburg <martijnverburg at gmail.com>:
>
> 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 <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/36021bb7/attachment-0001.html