users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: Re: CDI positioning

From: Yoon Kyung Koo <kyungkoo_yoon_at_tmax.co.kr>
Date: Thu, 11 Oct 2012 12:18:34 +0900

Hi, all.
Sorry for late feedback.
I think CDI is more and more important feature of Java EE and should be aligned with annotations in other SPECs.
Though there may be some backward compatibility issues, I prefer the option C.
And I have some concerns in annotations and CDI with respect to deployment performance.
I hope the annotation features can be more finely defined and can be scoped in view of the deployment performance in the future.

-- 
--------------------
 Software Innovation Evangelist
 Researcher & Executive Director / WAS Lab / TmaxSoft R&D Center
 PGP  http://www.javadom.com/personal/yoonforhatgmaildotcom.asc
2012. 9. 21., ¿ÀÈÄ 3:56, Bill Shannon <bill.shannon_at_oracle.com> ÀÛ¼º:
> 
> I've heard from a few of you on this, but I'd like to get feedback
> from the rest of the expert group.  There's 20 people on this
> expert group, surely you all joined the expert group because you had
> opinions about Java EE, right?  You wanted to help us direct the
> future of Java EE.  You wanted to give us the benefit of your experience.
> If you just wanted to watch, you could've joined the users list instead
> of the expert group...
> 
> Let's hear it!  What do you guys think?!?
> 
> (If you already responded to this thread, please resist the temptation
> to jump in again.  Let's let the others have their say.)
> 
> Thanks.
> 
> 
> Bill Shannon wrote on 08/30/2012 01:58 PM:
>> From many of our recent discussions, it seems clear that CDI is
>> becoming more central to the Java EE programming model.  For example:
>> 
>> - The expanded use of @Stereotype in my previous message.
>> 
>> - The use of CDI interceptors to provide container managed
>>  transaction support beyond EJB.
>> 
>> - The potential future use of CDI interceptors to provide container
>>  managed security support beyond EJB.
>> 
>> - The use of CDI interceptors to support Bean Validation method
>>  level validation.
>> 
>> - The discussion of "implicit producers" to allow use of @Inject
>>  instead of @Resource to inject Java EE resources.
>> 
>> - The discussion around alignment of CDI managed beans and the
>>  separate @ManagedBean spec.
>> 
>> - The introduction of a transaction scope and its use in the JMS
>>  spec to simplify the programming model.
>> 
>> - The change being considered by the CDI expert group to enable
>>  CDI by default, making it more attractive to use it for all
>>  the items above.
>> 
>> 
>> At the same time we're finding that some specs, e.g., JAX-RS, are
>> hesitant to introduce a hard, or even soft, dependency on CDI,
>> instead insisting that all their new features must work in an
>> environment where there is no CDI.
>> 
>> In many ways this parallels what we saw with annotations.  In
>> the beginning we found many people who didn't want to use annotations
>> and wanted us to make sure everything worked without use of
>> annotations.  Now we're seeing many things that *only* work with
>> annotations, and annotations are well accepted by Java EE developers.
>> I suppose there's a natural lifecycle to acceptance of new
>> technologies, and I wonder where we are in that lifecycle with CDI?
>> Has CDI become a mature and accepted technology that we should use
>> widely?
>> 
>> 
>> I'd like to get a sense from this group as to what direction we
>> should provide to all the Java EE specs in regards to their use
>> of CDI.  Here's a few obvious options:
>> 
>> A. Technologies that see a significant standalone (non-Java EE) use
>>   should be fully functional without CDI.  If necessary, any
>>   required features that are similar to CDI features should be
>>   defined and implemented in a way that doesn't depend on CDI.
>> 
>> B. Technologies should provide all major features in a way that
>>   works without CDI.  Some features may also be provided in a
>>   different way that works well with CDI.  Some less essential
>>   features may only work with CDI.  The implementation should
>>   only have a soft dependency on CDI at most.
>> 
>> C. Technologies should provide features that work well with CDI
>>   without duplicating any functionality in CDI.  Use CDI wherever
>>   it fits.  The implementation may have a hard dependency on CDI
>>   and may require CDI even when used in a standalone environment.
>> 
>> I'm sure you can think of other options as well.
>> 
>> What advice do you think we should give to other Java EE specs?
>> 
>