Hi, - I hear you, and this has been a concern indeed. There are more examples like the @RequestScoped etc annotations in CDI and JSF. With the above I didn't mean though to necessarily use the same names, but at least the semantically equivalent service that these annotations stand for.
I would avoid introducing new annotations unless absolutely necessary. From usability perspective, developers don’t care about package names, they just want things to work. So it’s important to make the annotations, which now work only in EJBs, work also in any CDI bean. The exact same annotations, even if inside package with ejb in it's name. It's a good idea to deprecated EJB-specific annotations like @Stateless or @Stateful once there’s an alternative. But I wouldn't introduce new annotations for timers – deprecation doesn’t remove old annotations and IDEs will keep suggesting them in imports, which is very confusing already for annotations like Singleton, ManagedBean, etc as mentioned by David earlier. Ondro Hi, On Sat, Oct 14, 2017 at 10:44 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote: > On Oct 14, 2017, at 11:24 AM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote: > > > The former EJB should just be services that could be applied to any CDI bean. > > By that do you mean that you'd like to see @Asynchronous to remain in the EJB spec, but in a CDI version? > > Since @Transactional moved to JTA, I think it might be a better idea to move @Asynchronous to the Concurrency spec. Not sure about @Pooled though, but @Schedule and @Lock probably should be best at home in the Concurrency spec as well.
I'm not entirely sure. I have very mixed feelings about simply moving annotations around. @Transactional is at least a different name than @TransactionAttribute.
I hear you, and this has been a concern indeed. There are more examples like the @RequestScoped etc annotations in CDI and JSF. With the above I didn't mean though to necessarily use the same names, but at least the semantically equivalent service that these annotations stand for. Probably we should not introduce annotations with the same name before deprecating the similarly named old one. At least I've added the deprecated annotation to the JSF ones for JSF 2.3, so the IDE should warn about them. I repeatedly mistakenly import JAX-RS's @Produces when I meant to use CDI's @Produces and don't notice till deploy time. If I'm sleepy it takes me a while to put it together because imports are collapsed and hidden in the way IntelliJ is configured by default.
True, but as mentioned deprecation of the older ones should help with that in cases where they actually are similar things. JAX-RS' @Produces is something totally different from CDI's one, so that's quite an unfortunate situation. Many people frequently import the Java EE @ManagedBean when they mean to import the JSF @ManagedBean.
People should not want to import JSF's @ManagedBean ;) It's very much deprecated :P The concern I'd have is we could easily poison the well of EE by moving annotations around and improving them in a new package leaving an increasingly large number of confusing traps for people fall into, get frustrated with and drive them away. Doing this because we don't like the EJB package feels like EJB creating one more mess for us. A mess that only people in the know will understand.
Totally pruning EJB would probably be the solution for that particular problem. |