We have Core profile where implementations are free to ship Core profile(+) if they want to have a Jakarta EE compatible “legacy free” runtime.
Exactly. I'm not sure what problem we're solving that isn't already solved by the Core Profile and the ability to add on top. One could argue we should actually encourage implementations to use the Core Profile for exactly this kind of pursuit -- that is what it's for.
Btw I don’t agree with the messaging that EJB is legacy as there is no current replacement. Jakarta EE developers out there are still building new applications using @Stateless as it just works and is simpler than the current alternative.
I agree CDI needs to become the foundational “bean” component for the platform but it isn’t there yet.
Also completely agree. We see many people using @Stateless, @Schedule, @Startup as well as the remote capabilities (though not part of EJB-lite). There is no equivalent in other specs.
My likely less popular opinion is that since this topic always finds its way to listing functionality EJB provides that we should keep and get working on CDI, it does somewhat validate that much of what EJB provides is valid and we do want/like the functionality, we just don't like the brand.
Here's our current status:
- We don't legally have an EJB spec to remove, we have Jakarta Enterprise Beans
- Every Jakarta EE release has featured us removing something from Jakarta Enterprise Beans (CMP/BMP, CORBA, legacy Home/Remote interfaces, JAX-RPC ties, use of deprecated Security APIs, etc)
The only thing left is the good stuff and that good stuff isn't legally "EJB". How much work do we want to put into moving the good stuff into yet another spec not called EJB?
If we want the good stuff to also work on CDI, let's do that and make this easy on ourselves.
-David
_______________________________________________