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.

[ggam]

The problem starts when this CDI lite is proposed as the solution for MicroProfile. Until Quarkus, everyone expected MP runtimes to contain a full CDI implementation. I don't have a problem with a CDI edition which is the base for other DIs, like AtInject. But AFAIK this whole discussion was inititated because of MP.

Yes, I know there are multiple interpretations of what kind of CDI support Microprofile has. Let's not go into that. This is just my opinion and I think support for extensions is very important for the ecosystem right now. That's all.

[m-reza-rahman]

This is just my opinion and I think support for extensions is very important for the ecosystem right now.

For what it is worth, I think it is fairly obvious the legitimate question to explore together is whether leaving out something like a vendor and implementation neutral way of CDI extensibility is setting the bar too low, even for AOT centric runtimes. For me, the answer is very far from clear in either direction just yet

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[tomas-langer]

An extension capability is I think a core requirement for any platform. The CDI portable extensions allow a lot, and that is probably not (fully) required for a microservice development.
Nevertheless there needs to be a way to extend the environment in a vendor independent way, to be able to:

• add support for new annotations (such as MP's @Traced or @Timed) - interceptors etc.
• add support for a new injection type (such as MP's @ConfigProperty) - in general this would mean adding new producers
• validate that your environment is configured correctly (fail fast principle)

If the above is not supported, the interoperability suffers and makes most of libraries non-portable. This may be fine for implementations of specs that are "platform" in nature (such as the above MP specifications, that may be vendor specific), yet not fine for any party offering a service and integration libraries.

Imagine providing a service (such as messaging) - now you could come up with a CDI portable extension to add support for your product, that ANY CDI implementation can use (and support for injection of message emitters, and support for annotated listeners). If extensions are removed from the specification, you would need to implement a custom extension for EVERY vendor implementation.

TL;DR: I think extensions MUST be part of CDI Lite, maybe with a limited feature list

[mkouba]

The problem starts when this CDI lite is proposed as the solution for MicroProfile.

@ggam I think that MicroProfile does not (and should not) define the contract for integrators but rather the user API.

Nevertheless there needs to be a way to extend the environment in a vendor independent way, to be able to: ...

@tomas-langer There is no doubt that portable way of extending platforms is a "laudable" feature. On the other hand, I don't think it has to be mandatory, esp. for a first version of a "lite" version ;-). @manovotn made a very good point: "Conjuring spec API out of thin air doesn't bode well".

[graemerocher]

Chiming in here as we (Micronaut - https://micronaut.io) may be interested in supporting a CDI light if we were able to achieve spec compliance.

Challenge for us is not so much extensions, I think they are doable using an import capability, it is more the APIs that rely currently on reflection since Micronaut is completely reflection free and we won't consider introducing changes that enforce reflection on users due to the performance and memory consumption downsides of reflection.

Some examples:

• The interceptor API directly exposes java.lang.reflect.Method https://docs.oracle.com/javaee/7/api/javax/interceptor/InvocationContext.html#getMethod--
• The injection point API directly exposes the reflective member https://docs.oracle.com/javaee/7/api/javax/enterprise/inject/spi/InjectionPoint.html#getMember--
• The annotated member API directly exposes the reflective member https://docs.oracle.com/javaee/7/api/javax/enterprise/inject/spi/AnnotatedMember.html

We can for example support these methods by falling back to reflection and throw an exception if they are called or maybe have a mode that logs a warning, however we would need alternative APIs for implementing the functionality they provide without reflection.

[arjantijms]

it is more the APIs that rely currently on reflection since Micronaut is completely reflection free and we won't consider introducing changes that enforce reflection on users due to the performance and memory consumption downsides of reflection.

Just an offhand remark, but maybe EJB 1.0 was right after all ;) It didn't use reflection either and depended on tooling generating thing like proxies at build time.

[keilw]

I'm not that familiar with the DeltaSpike extensions other than config, nor have I ever seen any being used in a real life project, but in today's Java landscape nothing makes a lot of sense without a proper JPMS extension mechanism via provides and uses (https://www.baeldung.com/project-jigsaw-java-modularity) this may not make that much sense.
The whole idea of the CDI "SE Mode" was probably too early because it never produced a real module that was smaller, only some runtime configuration which btw. also needs to be revisited whenever Java SE might completely abandon META-INF/services in favor of module-info declarations for that.

Unfortunately CDI is not quite a good example for a Jigsaw-friendly structure with 2 top-level subpackages and the whole SE functionality which is not big but makes little sense outside an SE container but it was hidden deeply under the "inject" structure.
It seems extremely hard to break it into smaller parts or identify parts that could be optional.

@tomas-langer About extra elements

• MP's @Traced or @Timed) - interceptors are already dead because all of MP Metrics is in serious discussion of replacing all or most of them with Micrometer. So squeezing that into CDI makes little sense now.
• Add support for a new injection type (such as MP's @ConfigProperty) - that might make sense, but also nothing for "core" CDI, possibly some extension similar to the DeltaSpike config which is more or less what MP Config is about with a few stops along the road.

As all are under the Jakarta EE umbrella now, too, wouldn't some of the most basic elements, especially if they're just annotations also work in either https://github.com/eclipse-ee4j/injection-api or https://github.com/eclipse-ee4j/common-annotations-api?

[manovotn]

I am going to close this issue now.
CDI 4 is now out of the door and has CDI Lite support.