Re: [cdi-dev] CDI Lite compatible extension lead

[Jason Greene <jason.greene@xxxxxxxxxx>]

On Sep 29, 2020, at 1:32 PM, Laird Nelson <ljnelson@xxxxxxxxx> wrote:

On Tue, Sep 29, 2020 at 11:03 AM Jason Greene <jason.greene@xxxxxxxxxx> wrote:

Did you see Antoine’s blog in March?: 

http://www.cdi-spec.org/news/2020/03/09/CDI_for_the_future/

Yes.  With (truly!!) all respect to Antoine, it's a bit all over the place and not a list of use cases or goals.

Can we just put down here, in simple bullet point formats, what at least the goals of this effort are?

I don't mean to suggest this is a trivial exercise, because it is not, and Emily certainly tried to get it rolling before (mostly unsuccessfully) with issue #425 (https://github.com/eclipse-ee4j/cdi/issues/425; and I applaud her attempt to start with the use cases).  But let's try again, here, publicly, on this list.

For the record, I'm definitely aware of {handwave} build time {handwave} no reflection {handwave} but I'm quite sure we can do better than that as a group.  Here is an incomplete sketch of one example of the sort of thing I had in mind.

Meta-goal: disrupt the specification as little as humanly possible (true of all specifications everywhere that are this old)

Goal: permit a CDI SeContainer to run a precomputed set of beans without having to run portable extensions

Why: certain products create their beans at build time/ahead of time: we want them to be part of the CDI fold as well

Hindrance: the SeContainerInitializer/portable extension APIs, even with something like SeContainerInitializer.disableDiscovery().addExtension(new Extension() { /* add beans here however they are generated/created */ }) is insufficient because of X, Y and Z

Hindrance: all (not just some) portable extensions must be available at runtime via BeanManager#getExtension()

…etc. and so on.  I can see the germs of something like this lurking in your posts and others' and in Antoine's blog article and elsewhere but I think it is necessary that we have small, traceable, actionable goals spelled out here before we try to solve them.

So I think we have explained the why quite a bit, and importantly we are talking about fundamental compatibility differences (two-phase multi-VM execution vs one phase), so you are already at the point of having to start anew. It’s not something that a simple API tweak here and there is going to solve.

-Jason