Then why not consider putting the 'light' or whatever part into the 'I' which is Jakarta Injection and out of CDI?
Jigsaw is there whether you like how it’s done or not. It may not be as visible as OSGi in Eclipse and other OSGi containers, but many large and popular frameworks like Spring do, although most of them shy away from declaring module-info, but stick to the Automatic-Module-Name in the MANIFEST.
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.
While I generally like splitting out well defined core functionality, like e.g. _expression_ Language was split out from Faces & Pages, we may have to be careful here to not create a layering with names that make CDI incredibly confusing for all but the in crowd.
We already have Jakarta DI (previously AtInject) on which CDI Core is layered and on which CDI EE on its turn is layered:
1. Jakarta DI - Small set of annotations, previously shared with Guice, HK2, Spring, etc now privately used by Jakarta CDI
2. Jakarta CDI Core - Beans, qualifiers, scopes, alternatives, stereotypes, decorators, portable extensions
3. Jakarta CDI EE - Mostly rules for Enterprise Beans, but also some rules for servlet components, bean names and scope in _expression_ language, specifically including Faces and Pages and build-in beans for Jakarta Transaction, Jakarta Security, Jakarta Servlet
That would now become:
1. Jakarta DI - small set of annotations, previously shared with Guice, HK2, Spring, etc now privately used by Jakarta CDI.
2. Jakarta CDI Lite - Beans, qualifiers, scopes, stereotypes, buildtime portable extensions
3. Jakarta CDI Core - Alternatives, Decorators, runtime portable extensions
4. Jakarta CDI EE - Rules for EJB beans and servlet components, bean names and scope in _expression_ language, specifically including Faces and Pages, build-in beans for Jakarta Transaction, Jakarta Security, Jakarta Servlet
Give these 4 layers of functionality, are the names really still representative of what each layer offers?
Just a few ideas but what about:
1. Jakarta DI
2. Jakarta CDI Core
3. Jakarta CDI Dynamic
4. Jakarta CDI EE
or
1. Jakarta DI (previous Jakarta DI + Jakarta CDI Lite)
2. Jakarta Dynamic DI
3. Jakarta Dynamic DI EE
Thoughts?
Kind regards,
Arjan Tijms
