|Re: [ee4j-community] Deprecating EJB in Favor of CDI Services|
|I’m a bit late to this fast-moving thread (and not caught up yet). This is a general brain dump regarding this thread up to this point.|
1) Keep in mind that it is probably 5-6 months before EE4J is an established project with its first release available. As a part of that, the “expert groups” need to be set up, which implies a process for defining how expert group members are defined. We also need to define an EE4J release process where specs can evolve. In other words, we have to walk before we run :-)
2) Switching specifically to this topic, I think the over-arching goal is to get to one enterprise component model to simplify Java EE altogether. Explaining the intricacies of CDI vs EJB complicates the platform. In that context, I love this discussion. However, we need to execute on 1) before we execute on this.
2) Not that anyone is advocating this, but I do worry that simply taking the remaining EJB functionality and pushing it into the CDI spec just complicates the CDI spec. We’ve spent years trying to simplify and decompose the EJB spec. For example, when I see “@Monitored”, I naturally wonder if that should be moved to the MicroProfile Metrics spec.
3) We are going to constantly have this push and pull of moving quickly with pent-up desired features and retaining backwards compatibility within EE4J. Perhaps this is a good area to prove out how we do this. Or, is there lower-hanging fruit?
4) As I think Kevin brought up earlier, perhaps this should be covered in the existing EJB & CDI email aliases while we figure out 1) here first.
Back to the top