Hi,
The strange thing is that the Jakarta Persistence team is supposedly against a dependency on CDI. The fact this is strange is twofold:
1. CDI is supposed to be the core technology of Jakarta EE. It's at the lowest level. Why are we afraid of "ourselves"? As I asked in the platform call, are Spring projects afraid of being dependent on Spring Beans? Are Java applications being afraid to be dependent on Java classes?
It just does not make sense. If Jakarta Persistence is supposedly not willing to depend on anything Jakarta EE, and is supposedly focusing mainly on Java SE, why would it be a Jakarta EE specification to begin with?
Don't get me wrong, I understand there are timing issues and that there are moments in time when a Jakarta EE runtime boots where CDI is not available yet. Of course that needs to be addressed, like in e.g. MicroProfile Config there is a special construct to use at those early stages. But outright not wanting to have any dependency on CDI, even at places where's it's absolutely technically feasible and useful to the user strikes me as... weird.
This also does not make sense at all. How can you be against introducing something that is already there?
Maybe we should recheck our assumptions. Is the Jakarta Persistence team *really* against CDI, or are we just assuming they are?
Kind regards,
Arjan Tijms