On Friday, January 28, 2022, Matej Novotny <manovotn@xxxxxxxxxx> wrote:
I am not much a player in these what-if games. We needed to introduce this new model and question of naming was open for probably over a year since we first started drafting them. No better name was agreed upon and that's how we landed on build compatible extensions. At least it captures the intent of usage (but doesn't limit it to just that).
I can understand that, and it’s fine.
But the key question remains:
What can the portable extensions do what build compatible extensions can not?
There's a couple of events from Portable Extensions that do not have a direct equivalent in Build Compatible Extensions, notably ProcessBeanAttributes, but an equivalent for those could be added if deemed necessary.
The core difference is lifecycle (and reliance on reflection). Portable Extensions are intrinsically intertwined with the lifecycle of the CDI container and the deployment. They can even hold application state (I'd argue it's a bad idea and extensions should arrange for application state to be held in beans, but my opinion doesn't matter much here :-) ).
Build Compatible Extensions don't allow that. On the other hand, they allow completely build-time CDI implementations (where by "build-time CDI implementations", I mean CDI implementations that precompute all dependency wiring and pregenerate all support classes and run extensions and everything during application build, so that there's virtually zero CDI initialization during application startup).
I don't see a good name here really. "Build compatible extensions" is a huge compromise and it sounds ugly, but I can't think of a better one. (I tried, there's a thread on cdi-dev, feel free to resurrect it.)
Buildtime extensions and Runtime extensions would have my vote, although it's indeed not entirely trivial if Builtime extensions are either secretly or explicitly runtime extensions too.
Yes, the trick here is that the new model is, in its function, not build time, it's build compatible. Since Lite is a subset of Full, any CDI Full impl has to support them as well (hence ensuring Lite -> Full portability) but CDI deliberately avoids stating whether those extensions need to be executed during build or run time because that's up to implementation. Existing CDI Full implementations can relatively easily implement build compatible extensions by executing them at runtime (which was one of the goals so as not to create a barrier for integrators). CDI Lite implementations will, typically, execute these new extensions during build time.
In short, a rename to BuildTimeExtension and RuntimeExtension would be wrong.
Which perhaps begs the question then; what sets the current Runtime Compatible extensions apart from the Build compatible extensions? What can the former do that the latter can't? If we can succinctly answer that, we may have our name.
When it comes to current portable extensions, I'd prefer not to rename, simply because the name has been in use for too long. That itself, in my eyes, trumps the other arguments.
That may be exactly the reason to consider a rename, if the only reason to not rename them is that they have been used for too long (yes, I know the reasoning here is somewhat circular ;)).
I am afraid I second Ladislav's opinion here. Renaming them would break compatibility of any existing application implementing them for no gain other than slightly different name.
Naming is important.
We now have two types of extensions; build compatible, and portable. It naturally says now that build compatible is not portable. Why else would the other type of extension be called portable?
I'd be fine calling them Build Compatible Portable Extensions, but I'd also find the name even worse than the current one. Naming is hard.
LT
