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

[Jason Greene <jason.greene@xxxxxxxxxx>]

It’s definitely not a silly question. The basic problem you run into though, is that for it to work, you have to initialize *everything*, there can be nothing left to runtime, and that creates problems. For example, if you have an extension that opens a file or a socket, that portion must be deferred to runtime. So in reality you end up with a split of things that you want to init at build time and runtime, these are the things that don’t change (picture running code in a container, you have all this portable extension logic recomputing everything and always arriving at the same answer on every start), and things which must change (e.g. code establishing a db connection, reading an env var). Further you want the AOT compilation process (or the traditional JVM JIT) to have an easier time reasoning about the actual code. Deferred injection works against this because its difficult for the compiler to determine where a particular value comes from.  Additionally it's desirable to limit the dependency set between these separate initialization phases (for similar reasons)

The only workable solution is two computational phases, a build time phase which computes (and transforms) what the application *is*, and a runtime state that adapts to the environment. 

-Jason

> On Sep 29, 2020, at 6:43 AM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
> 
> Hi,
> 
> Maybe this is a silly question, but what about running the existing CDI extensions at build time, and then capture and export the resulting state?
> 
> If I'm not mistaken, Graal runs static initializers at build time already, so this might not be a terribly big step. Just thinking out loud.
> 
> Kind regards,
> Arjan
> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev