jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: CDI positioning

From: Nitta, Minoru <minoru.nitta_at_jp.fujitsu.com>
Date: Fri, 5 Oct 2012 13:05:13 +0000

Hi all,





CDI is very important technology for Java EE and I can’t imagine Java EE

without CDI. That’s why the technology is widely accepted by many programmers.

CDI should be central technology for Java EE 8 too.



Main features should depend on CDI. I understand some people insist that key features

should run without CDI, but it’s not mandatory for Java EE.





Minoru

> -----Original Message-----

> From: Bill Shannon [mailto:bill.shannon_at_oracle.com]

> Sent: Friday, August 31, 2012 5:59 AM

> To: jsr342-experts_at_javaee-spec.java.net

> Subject: [jsr342-experts] CDI positioning

>

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