CDI lite

[Emily-Jiang]

In light of this discussion on allowing widely adopted by compile-time runtimes, the following use case is requried.

As a implementor of CDI spec, I would like to support the CDI parts, which can be determained at compile time so that my end users can benefit from CDI and AOT.

[aguibert]

I like the idea of a CDI Lite, but we should define it in terms of features/capabilities, rather than what the CDI implementers can figure out what to get working in AOT runtimes.

Perhaps we could start by making a list of features that are very computationally expensive or complex compared to the benefit they provide to end users?

For example, CDI Lite could have the default bean discovery mode be "annotated" and then "all" could be added by the "full" CDI spec, where it could become the default.

[manovotn]

My personal 0.02$ are that I generally think we need a Lite version of CDI spec that will cut out some not-so-used parts and bits that aren't built time friendly. Something like that will help CDI stay up to date with rising technologies/frameworks in Java. However, we need to proceed carefully - first version would definitely have to be just a subset of existing features, the smaller the better, so that we don't include things that aren't necessary and might just keep getting in our way further down the line. Better to underspecify then to overspecify what we want to support, at least in my opinion :)

CDI Lite could have the default bean discovery mode be "annotated"

Yeah, that's for sure, the all mode is just ridiculously expensive to process for the "good" that it brings.

Another candidates for exclusion in Lite (just from the top of my head) would be things like decorators, less used scopes in microservice world (conversation/session). We'd definitely drop any EE integrations from Lite spec as those don't need to be present at all. And probably much more.

[Emily-Jiang]

Here is the list of functionalities I think CDI core should provide:

• Relationships to other specifications: Relationship to Dependency Injection for

• Relationship to Dependency Injection for Java

• Relationship to Java Interceptors

• Concepts

• Dependent, ApplicationScoped, RequestScoped

• Support Alternatives, Stereotypes, Interceptors, Decorators

• Programming model

• Producer methods, Producer fields, Disposer methods

• Injection support: bean constructor, injected fields, Initializer methods

• Events

• Portable extensions

[Cousjava]

I think that portable extensions shouldn't be part of core, however I do think that ConversationScoped and possibly custom scopes should be in core.

[manovotn]

@Emily-Jiang Portable extensions are by nature runtime components; they are very much against any AOT concept. Take a look at this article by Antoine which says explains why - http://www.cdi-spec.org/news/2020/03/09/CDI_for_the_future/
Later on there could (would?) be a way to declare much of what extension can do in a build time manner, but that's hardly a question for first draft.

@Cousjava Custom scopes are not a problem - you can define those (in a slightly different manner) in AOT-friendly environment and specification doesn't need to carry on supporting them for ever. As in, it will support defining them, but it is up to user to make sure his/her scope works in given environment.

ConversationScoped OTOH is very much a legacy these days. Namely in MP and cloud environment this is no longer requested. Again, the article I linked above talks a bit about it. The way to solve this can be to not support conversation scope in CDI-lite and instead have it as a custom scope. That way you could still support it if your desired platform declares support for it, but you don't introduce it to the core as mandatory one for all consumers.

[ggam]

Extensions are the only portable way to register new scopes AFAIK and they are also needed for some advanced integrations. For example, Soteria is built on top of portable extensions.

Most of the usecases can probably be achieved during compilation, as long as all the target classes are on the classpath. Even if we cannot get full support for Extensions, at least basic support is needed IMO.

[Emily-Jiang]

If we remove Portable Extension from the list, we need to solve the issue #434

[manovotn]

Just my personal 0.02$ on that.
While I agree that extensions are very powerful and useful, in their current state they just don't fit the build-time scenario.

I understand we will need to have build time alternatives for extensions (well, bits of their functionality) eventually - even in Quarkus there are some build time oriented extension points for CDI bits. The aforementioned custom scopes are a good example. However, I don't think this API should exist for the first version of Lite spec for several reasons:

• IMO it is better to start minimal and expand as we see the need, you can always add to spec but removing is the problematic part
• We don't really know what the build time extensions API should look like or which parts are actually needed/sought after (probably not all)
• Conjuring spec API out of thin air doesn't bode well, so having some proved implementations in the wild would be neat; ATM the only existing "template" is what Quarkus uses, it would be good to see more of them
  • This is BTW the model that MP uses (or was designed to use anyway) - to see things tested in the wild by impls before writing it down in the specification.
• By starting minimal, you can also release easily. There is a requirement for a compliant impl and when you start with just a subset you automatically have existing implementations passing. From there you can proceed with the experimenting part on impl side like I noted above.

[ggam]

@manovotn you are right, but it's also risky to provide an initial version that doesn't cover user expectations/needs.

One problem we now have is that CDI "EE" already specifies its relationship with Servlets, EJB, JSF, EL, etc and defines scopes that aren't useful for other server environments, like MicroProfile. The spec is already organized in core+EE/SE.

CDI could release a core artifact that can be consumed by "zero-legacy" runtimes. That solves a big part of the problem, while CDI lite is being worked on and problems like build time Extensions are solved.

[mkouba]

you are right, but it's also risky to provide an initial version that doesn't cover user expectations/needs.

So I think that we should disinguish application developers (users consuming API) and integrators (users consuming the current SPI). While developers usually don't (and should not) care about the SPI, integrators rely on SPI and portable extensions.

And the first version of CDI lite could be specified from the app developers point of view and leave the integrator part undefined => non-portable (i.e. a place for innovation).

CDI could release a core artifact that can be consumed by "zero-legacy" runtimes.

I think that the first version of CDI lite can leverage a single "shared" CDI API artifact, like the CDI SE/EE parts do today.

[ggam]

While developers usually don't (and should not) care about the SPI, integrators rely on SPI and portable extensions.

As a user, I don't care about SPI, but I do care about libraries based on CDI extensions (e.g. Deltaspike) that don't happen to work, probably without explanation, as they would just be ignored.

I think that the first version of CDI lite can leverage a single "shared" CDI API artifact, like the CDI SE/EE parts do today.

My point is that it may take a while to agree on the minimum that's needed for the first Lite version, but probably there's consensus on what's not needed. In the long run, all those EE integrations, like injection of HttpServletRequest, should be moved to its corresponding specs. Maybe this can be tackled before work on CDI Lite really starts.

[manovotn]

A lot of the functionality of DeltaSpike has over time poured over to other microservice oriented APIs/frameworks - MP is actually a good example of that. As a matter of fact, while I still see DS used, it is mostly in EE and on long existing apps where people just don't want to (or cannot) rewrite it.

I have seen (on Quarkus discussion, SO, jboss forums, ...) quite a few user questions on how to do XYZ that DS offered with some other means and mostly it was actually quite easy using various MP specs. And maybe other missing features are then candidates to be added into MP specs?

As a user, I don't care about SPI, but I do care about libraries based on CDI extensions

Libraries that are actively developed could leverage some of the emerging ways of integrating with CDI Lite and MP world. Actually this is the one thing that would show us what exactly integrators need and later on we could standardize an API based on that as opposed to guessing what might be good and doable right away. But it is all about accepting the development where you first test things out and only later when you see that it is reasonable and needed, you standardize it.

This path of course favors new application and new integrations rather than porting old/existing ones, but for an emerging spec (or sub-spec if you will) I think it makes a lot of sense to look primarily in that direction.

[m0mus]

I think that portable extensions shouldn't be part of core, however I do think that ConversationScoped and possibly custom scopes should be in core.

I disagree. I think portable extensions must be a part of CDI core.

[ggam]

A lot of the functionality of DeltaSpike has over time poured over to other microservice oriented APIs/frameworks - MP is actually a good example of that. As a matter of fact, while I still see DS used, it is mostly in EE and on long existing apps where people just don't want to (or cannot) rewrite it.

I put DeltaSpike just as an example. I haven't used it myself, but the idea applies to any project that integrated using extensions. Now you just put the JAR on the classpath and you are done. Without extensions, a lot of things aren't really possible.

Libraries that are actively developed could leverage some of the emerging ways of integrating with CDI Lite and MP world.

Some MP specs could be implemented via extensions and plugged into a CDI runtime without any hassle. See Payara implementation of MP JWT: https://github.com/payara/Payara/blob/master/appserver/payara-appserver-modules/microprofile/jwt-auth/src/main/java/fish/payara/microprofile/jwtauth/cdi/CdiExtension.java

I don't think removing that support goes in line with your next statement:

But it is all about accepting the development where you first test things out and only later when you see that it is reasonable and needed, you standardize it.

Without extensions, one can't even add new scopes. I'm not proposing to standarize a new way to integrate with CDI before it has been experimented. I just ask not to create a new profile without such feature just because it can be added later once we know how to do it. Better experiment with in implementations and propose that new profile when the idea is mature and provides all the needed functionality.

[mkouba]

I put DeltaSpike just as an example. I haven't used it myself, but the idea applies to any project that integrated using extensions.

@ggam Apps that depend on libs that integrate with CDI by means of extensions will just continue using CDI as it is today. Apps targeting a build-time oriented platform could rely on platform-specific CDI integration and continue using the CDI API. I'm sorry but I don't see a problem here.