Re: [cdi-dev] CDI future - problems and proposal

[Matej Novotny <manovotn@xxxxxxxxxx>]

I don't have an answer either but this also goes into how we decide to define the link between Full and Lite.
I.e. if they are closely related, we would probably want to keep the same APIs. However, that's confusing because there would be classes where some methods would work and others would blow up while in Lite env.

If we decide it's too different from Full to do that, there is the two APIs option Ladislav mentioned. It is indeed fragile but at least it gives the user a complete API where everything that's in there works.
Thinking out loud - maybe an implementation would be able to blow up at build/boot time if incorrect or both API was present? You could detect presence/absence of some classes or parts of API. In newer JDKs, and with the unfortunate concept called jigsaw, you'd even blow up just because equal packages would be in two JARs.

The third option (splitting classes) is something I would hugely prefer to avoid as it would break even existing apps (which the other 2 options would not) and in the end might still be confusing for same reason as first option (as in, some classes would need to be partially used by Lite and fully utilized by Full).

If I were to choose from these, option 2 would make most sense to me. Not only is the resulting JAR fully usable for user but it also gives us way more freedom in how Lite works. Most user-facing APIs would be the same anyway, but several parties have already acknowledged the need to use a) different extensions and b) different metamodel in order to work properly in build time environment. Doing it this was gives us the freedom to perform it without bringing the burden of dual metamodels back to original CDI Full. The downside is obviously that of having to maintain two versions. OTOH, we would then have two versions, each dedicated to very different environment (runtime/build) and being able to further evolve in that direction with more freedom.

Just my 0.02$, your mileage may vary ;-)
Matej

----- Original Message -----
> From: "Ladislav Thon" <lthon@xxxxxxxxxx>
> To: cdi-dev@xxxxxxxxxxx
> Sent: Thursday, November 12, 2020 10:08:58 AM
> Subject: Re: [cdi-dev] CDI future - problems and proposal
> 
> 
> 
> Good question, and I don't have an answer. Wanna help?
> 
> Thinking out loud:
> 
> 
> One option is to not split anything, just let Lite implementations fail (or
> ignore) if non-Lite API is used.
> 
> Another option is to release 2 overlapping API artifacts and insist that they
> shouldn't be used at the same time, but that is way too fragile in my
> opinion.
> 
> Yet another option is to move classes around, but that would cause a huge
> pain, so I'd rather not do that either.
> 
> Any other ideas?
> 
> LT
> On 12. 11. 20 9:50, Mark Struberg wrote:
> 
> 
> 
> How would splitting out the API work?
> Since Java9 splitting up the same package into different jars is not a good
> idea (actually never was, but technically the JVM did not complain unless
> one of the jars was sealed).
> 
> LieGrue,
> strub
> 
> 
> 
> 
> Am 12.11.2020 um 08:45 schrieb Ladislav Thon < lthon@xxxxxxxxxx >:
> 
> 
> 
> Hi,
> 
> Jason already said that, but I'll reiterate so that this doesn't fall through
> the cracks.
> On 11. 11. 20 21:52, Mark Struberg wrote:
> 
> 
> 
> CDI core and CDI lite are different things. After reading the CDI-light
> proposal it appears to me, that it shares just the name 'CDI', but not much
> more.
> It feels a bit like a different spec with main focus on running well on Graal
> and not needing any reflection or dynamic handling.
> 
> E.g. the wish to get rid of Contextual NormalScope proxies will kill CDI.
> This is literally the C in CDI !
> 
> 
> Isn't it good that noone actually proposes to do that?! See for example
> https://docs.google.com/document/d/1jS7EbHnyBBvZZxa56LmthKeoixm2FEHmqHwITGRLljQ/edit
> where I list what I think could/should be in the CDI Lite API.
> 
> What I propose to "remove" is, on the API level: - decorators
> - specialization
> - conversations
> - session scope
> - non-contextual injection
> - Portable Extensions
> 
> 
> There's obviously more to it than the API, but it should give you an idea.
> 
> A lot of the dynamism of CDI can be achieved by generating code at build
> time. I haven't seen anyone wanting to "cripple" the essence of CDI -- it's
> all about being able to implement it under a different set of architectural
> constraints.
> 
> LT
> 
> 
> 
> 
> 
> 
> 
> I've added some comments.
> And to clarify upfront: I'm not against such a spec. But it imo would not be
> CDI anymore. With removing all the dynamics we are back to Apache Avalon.
> 
> Werner: imo the jigsaw modularity only works well for the JDK itself. Never
> have seen it used in production due to various reasons.
> 
> LieGrue,
> strub
> 
> 
> 
> 
> Am 09.11.2020 um 13:06 schrieb Werner Keil < werner.keil@xxxxxxx >:
> 
> Unfortunately this was done in a rather clumsy way particularly the "
> independent " SE Elements that make no sense in an EE context and vice
> versa.
> While this was not in scope or targeted by around a third of all Jakarta EE 9
> specs (and because of these issues I don’t recall CDI even bothered
> declaring a module in the MANIFEST yet) "Jigsaw" modularity that was
> archieved for the JDK itself will come as soon as Jakarta EE 9.1, so CDI2
> was not the answer to a "CDI Lite" yet, it should be a "CDI Core" or
> whatever module in a future CDI Version that has other EE specific modules
> on top of it.
> Werner
> Von: Mark Struberg
> Gesendet: Montag, 9. November 2020 07:36
> An: cdi developer discussions
> Betreff: Re: [cdi-dev] CDI future - problems and proposal
> But this already got addressed in CDI-2.0 with the split into SE and EE parts
> of the spec.
> A container not intended for JavaEE is free to not implement those Beans.
> Or like we do it in Apache OpenWebBeans - keep it modular with a core which
> is just 700kB in size and all the integration is added on top of it.
> LieGrue,
> strub
> 
> 
> 
> 
> 
> Am 22.10.2020 um 18:00 schrieb arjan tijms < arjan.tijms@xxxxxxxxx >:
> Hi,
> On Thu, Oct 22, 2020 at 12:09 PM Ladislav Thon < lthon@xxxxxxxxxx > wrote:
> 
> 
> 
> or in retrospect shouldn't be in CDI
> in the first place. Things like:
> 
> - decorators
> - specialization
> - session scope
> - conversation scope
> - passivation
> - non-contextual injection
> I always felt that just JSR 330/AtInject was way too small, while JSR 299/CDI
> might have been a tad too big. My personal pet peeve is the fact that CDI
> includes build-in beans for several Servlet types, such as
> HttpServletRequest. We tried hard before to get that out of CDI and into
> Servlet. Likewise, the build-in bean for Principal should likely belong in
> Jakarta Security, etc.
> Though the conversation scope is technically not bound to Faces, maybe we
> should consider moving it to Faces anyway?
> Thoughts?
> Kind regards,
> Arjan Tijms
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
> 
> 
> _______________________________________________
> cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
> 
> 
> _______________________________________________
> cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>