| Re: [jakarta.ee-spec] [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan |
I agree with you, Reza. My point was that alternatives to EJB are often more cumbersome than just using EJBs. The sad reality is that some things now work only with CDI, some work only in EJBs, and things work in both but often are easier with EJBs.Examples of things that still require EJBs:- a single annotation that turns on transactions, synchronous access, dependency injection, bean pooling - with CDI you need a separate annotation for each- security with @RolesAllowed, etc - this simply doesn’t work in CDI in general, only some implementations support itExamples of things that are much more complicated without EJBs- cron-like timers - with EJB it’s a method with a single annotation and cron _expression_. Without EJBs, concurrency in EE 11 will allow something similar but still require to execute the method at startup, which is again much more code without EJBs- run a method on startup - just a single annotation on EJB and a postConstruct method, with CDI it’s an observer with a long complicated set of annotationsI’d like to address these things in EE 12. Thrn I would be comfortable with suggesting people to avoid EJBs completely. Then it would be really easy to start with Jakarta EE even for newcomers and be productive for advanced decelopers.Ondro_______________________________________________On Mon, 28 Oct 2024 at 23:25, Reza Rahman <Reza.Rahman@xxxxxxxxxxxxx> wrote:To be honest, I figured there was a high probability this debate would be inevitable. I kept it deliberately brief in the write up in the hopes that this is a subject pretty much all of the stakeholders are already well aligned on. Nonetheless, I will take this opportunity to more fully share my perspective on this. Perhaps it helps, perhaps it does not.
I have tried very hard to convince users and customers to use EJB for more than fifteen years now. The outcome for me is now firmly established. A small percentage (let's say 5-10%) get convinced and inevitably become ardent advocates. The rest immediately make the decision to choose Spring/Spring Boot instead. For this vast majority, EJB is well understood to be outdated, heavyweight, and bloated. As a result, the practical reality is that Jakarta EE as a whole consistently loses users and customers. If we continue to insist on clutching tightly to EJB, I have no doubt whatsoever that Jakarta EE adoption will never grow enough to sustain a critical mass of stakeholders that will be able to keep investing in it. Continuing the irreparably damaged EJB brand was a mistake in Java EE 5, 6, 7 and 8. It's a mistake I have personally paid a very high price for.
For me, the critical question in EE 12 is how much work can be done to convincingly tell the market they can finally use Jakarta EE without needing to use EJB. I understand the most ardent advocates of Jakarta EE are likely EJB fans (in fact count me in that crowd, I even wrote a book on EJB). I also understand for these users we need a graceful "off ramp" that will take some time and effort including early signals that we need to move on now, education on what the alternative approach is (i.e. the model that has successfully worked for Spring users/customers for years now), migration paths, guides, and tools.
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.