The "blocker" is the current extension model which is incompatible with build time approaches and overreach that exists within the API (ConversionScope anyone?).
I understand that you have a concern of processing the bean annotations at runtime (impact the startup time of the container) of the current CDI implementations.
Apart from the implementation details, what I believe is that most of the concepts in Micronaut (as read from https://docs.micronaut.io/latest/guide/index.html) comes from CDI specifications (JSR-330 or CDI 2.0/3.0) including Scopes, Factories (Producer in CDI), Conditional Beans (Alternatives, Vetos), Bean Introspection, Bean Events, Qualifiers, InjectionPoints etc. I remember the born of JSR330 , there were really interesting discussions between the parties :)
Is there any reason why one can not use the CDI API contract which is already defined and used more than 10 years? Just use the API but implement or process it according to your runtime performance requirements.
IMHO the current CDI API contract may be used by different frameworks/programming models/etc. and if it is not enough (to add specific features), this can be discussed in CDI specification level and integrated. Therefore, there is only __One__ clear CDI API which can be consumed by different frameworks including Spring, Micronaut, Quarkus, etc. Every different vendor tries to invent the same ideas with different APIs which confuses the developers.
Also, for comparing the performance of different implementations such as Micronaut vs OpenWebBeans, do you have any report/blog etc? Is it really a big performance improvements?
By the way, I am not a big fan of profiles. Profile is an overloaded world already. Jakarta EE itself has the concept of Web Profile, Full Profile, etc. Now, in CDI, we are trying to define many profiles. This would cause a lot of confusion.
Me too :)
I am with Mark on the points of - CDI Lite needs to be the subset of CDI if we call it CDI Lite; We should not change the defined behaviour (I am against the idea of ignoring the content of beans.xml and scan jars regardless of the bean-discovery-mode setting).
Exactly, CDI lite is naturally means that it is the subset of the full CDI API.
If you want to introduce new APIs and totally different processing model than CDI ( processing annotations at build time, removing extension points, etc.), then I think we need to call it a different name, spec etc. It is not a CDI.
In the meantime, there are different types of DI providers (Spring, Micronaut, Quarkus, etc…). Each of them has different set of APIs.
Why don’t we integrate these ideas into the current CDI specification? What is the blocker?
So when we started Micronaut we decided to only support JSR-330 because there are concepts within the CDI that enforce the use of techniques that are bad for memory consumption and startup performance (reflection, runtime byte generation, runtime proxies, dynamic classloading etc.)
We knew from the beginning we could not be spec compliant and I believe the same conclusion has emerged from Quarkus although the Red Hat team took a different approach of claiming partial compliance.
Many of these problems are not as apparent when you deploy to a traditional container on a single JVM because the JVM has a fair opportunity to share memory and optimize redeploy performance between applications. Modern architectures are based on embedded servers on unique JVMs, sometimes running containers and sometimes running on VMs. The opportunity to share memory and optimize via JIT is gone in this scenario, so you have to be more efficient at the framework level.
Note that we came to these conclusions regardless of GraalVM, AOT and native image because it is irrelevant whether or not you are using AOT or not. Compare the startup time and memory performance of a large CDI application based on something like Weld vs. Quarkus and Micronaut and you will be able draw your own conclusions.
The "blocker" is the current extension model which is incompatible with build time approaches and overreach that exists within the API (ConversionScope anyone?).
The hostility from some on this mailing list is actually not particularly surprising given vested interests but disappointing nonetheless. The folks interested in seeing this advance are not trying to undermine CDI or break compatibility. We are merely interested in CDI potentially being usable in other cases beyond the JakartaEE application server.
Currently nobody would use a reflection based CDI container on mobile or on Serverless or on IoT devices or for Kubernetes operators. There is a world beyond the Jakarta EE server that has the opportunity to benefit from the ideas in CDI if there was a subset or profile of it that was appropriate for these cases.
If not IMO things will continue as they are and CDI will continue to fracture anyway as Quarkus, Micronaut, Spring and others go in different directions which is a shame.
By the way, I am not a big fan of profiles. Profile is an overloaded world already. Jakarta EE itself has the concept of Web Profile, Full Profile, etc. Now, in CDI, we are trying to define many profiles. This would cause a lot of confusion.
I am with Mark on the points of - CDI Lite needs to be the subset of CDI if we call it CDI Lite; We should not change the defined behaviour (I am against the idea of ignoring the content of beans.xml and scan jars regardless of the bean-discovery-mode setting).
Thanks
Emily
On Tue, Jan 26, 2021 at 4:18 PM Ladislav Thon <lthon@xxxxxxxxxx> wrote:
Hi,
I think that's very nice, and quite close to what we've just
discussed on the call. (Meeting minutes coming :-) )
I'd like to get back to the "defining feature", if I may. I have
probably misunderstood you completely. At this point, there's no
new _feature_ proposed, no new API, no new configuration, etc.
(except the new extension API, which is just inevitable fact of
life and I guess we would all be happier if we didn't have to do
them :-) ). It's mostly about restructuring or redefining of
what's already there, in a way that doesn't break existing CDI
users yet allows CDI to be used in more environments (notably, in
an environment that "pre-wires" beans during application build).
Hope that I said it better than the last time.
LT
On 26. 01. 21 16:22, Manfred Riem
wrote:
Hi,
As it is clear that we are NOT gravitating
towards a solution here I would like to pivot and propose an
alternative that could be hopefully acceptable to all parties
involved.
Drop the
notion of CDI Lite
Introduce
the notion of CDI profiles
Define 3
profiles for the CDI specification
CDI
CDI – CP
(Core Profile)
CDI – BTF
(Build Time Profile)
Make 3c an
optional profile as far as the specification is concerned
(EE runtimes should not have to be required to support 3c)
Where 3b is a proper subset of 3a and 3c is
a subgroup of 3b (or in other words 3c uses 3b and it is
allowed to add its own incompatible “sugar”).
Thoughts?
Thanks!
Kind regards,
Manfred Riem
From: cdi-dev
<cdi-dev-bounces@xxxxxxxxxxx>On Behalf Of
Ladislav Thon Sent: Tuesday, January 26, 2021 7:59 AM To:cdi-dev@xxxxxxxxxxx Subject: Re: [cdi-dev] About parsing beans.xml
files in Lite
Hi,
On 26. 01. 21 15:27, Manfred Riem wrote:
I am sorry you think me asking for the
one defining feature is inconvenient and make you feel like
going around and around, but from my perspective it is a
very important question to answer.
no, that's not inconvenient, I understand
the desire to have a "defining feature" -- I'm just pointing
out that we already went through a very similar discussion
(here on this mailing list).
What is the one defining feature for CDI
itself? I would argue when most folks think about CDI they
think Dependency Injection.
So my question stands! What would most
folks think this to be named variant would stand for?
Everything I have heard so far does not
tell me that as I have only heard implementation concerns.
I don't think it's an implementation concern. If the
specification can't be implemented under certain constraints,
then either such implementation doesn't make any sense, or the
specification needs to change. I personally believe it's the
latter.
_______________________________________________ cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
