Re: [cdi-dev] CDI profiles (was RE: About parsing beans.xml files in Lit

[Jason Greene <jason.greene@xxxxxxxxxx>]

> On Jan 27, 2021, at 5:01 AM, Gurkan Erdogdu <gerdogdu@xxxxxxxxxxxxx> wrote:
> 
> 

-snip-

> 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. 

Unfortunatly no. At least, not in a compliant way. The portable extension SPI is an open ended contract and leaky abstraction that makes a lot of assumptions around the execution environment, and greatly limits implementation variation. Even in a runtime setting, since extensions are able to do virtually anything and everything, runtime implementations are hampered in areas of optimization (they can’t precompute or assume anything since everything can change out from under them). The holes in this contract even imply you can do things that won’t work in existing EE implementations. For example a portable extension could theoretically generate arbitrary EE components with new metadata defined and controlled by other (non CDI) spec implementations, but in practice this does not work reliably since every individual spec typically has its own metadata processing of some form vs pulling all its info from CDI. 

If we were starting from day one we would have likely come up with a better contract with strong encapsulation but it's hard to see the future, in particular 10 years into the future. 

Theres also just general structuring of the spec as well that leads to compliance murkiness. Right now the full CDI API has a hard dep on things like EL and JSF, even though some environments would like to not provide those technologies. So as an example, MicroProfile actually describes an augmentation to the CDI API (as JSF is not required). So basically the status quo you have to choose between no integration (SE profile) or a full EE container env to be strictly compliant. 

The remit of any spec group is to update the standard to reflect how users and implementors are actually using and applying the technology, ideally supporting a diverse ecosystem (if we want the spec to have any real value as a standard).Of course if you wanted to artificially limit yourself to a spec that never evolves, or supports new users, the solution is simple, stay on an old version. However, then we wouldn’t need to have moved the specs to Jakarta in the first place.

Also, its worth saying that artificially restricting the spec won’t change anything (other than hurting participation and adoption). Existing portable extensions are not going to work in build-time oriented environments no matter what we do. The question is how do we move forward in a way that makes everyone happy. Supporting compatibility with existing full platforms and enabling a lite variant that is build (and runtime compatible) is a very nice trade off that results in pure net gain.

-Jason