Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Tomitribe commitment to EE4J


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.

Kind regards,
Arjan Tijms



ee4j-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top