| Re: [ejb-dev] [cu-dev] Jakarta EE 10 and breaking changes |
|
Hi,
I agree that the best way to go is to replace EJB features in other specs by a modern approach rather than just copy the existing functionality from EJB. Otherwise there would be 2 competing ways to do the same things, with EJB and without EJB. And we would
possibly have 2 sets of annotations with the same names but different package names which has been a pain with Java EE in the past (JSF vs. CDI ViewScoped, EJB vs. DI SIngleton, etc.).
It's better to rethink specific EJB features and implement them in other specs so that they fit those specs and ideally use different names for annotations. It would also allow leaving legacy behind in the EJB spec (e.g. XML config) if it's no longer useful.
On the other hand, EJB spec should be regularly updated to support the new functionality in other specs. E.g., it even now it should add support for specifying the executor service to use for running @Asynchronous methods. If the concurrency spec provides a
variant of Asynchronous annotation (hopefully with a different name), the EJB spec should adopt it so that it works seamlessly with EJBs in the same way as the existing @Asynchronous annotation. Users wouldn't need to think about which annotation to use because
both the old and the new one would work in the same way.
This could also lead to a subprofile/subspec of EJB that would only build on top of the features in other specs (e.g. Stateless would be just a stereotype on top of CDI annotations in the concurrency spec and all would run in the CDI container). This subprofile
could remain in the Jakarta EE Platform spec while the rest would become optional or deprecated.
The key point is to synchronize with other specs to make sure that the essential parts of the EJB spec are provided in some way by other specs (mostly CU, JTA, CDI) and that a simple EJB profile can be defined as an aggregation of those specs plus some glue.
Ondro
+1 Tracy!
|