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