We've discussed the EJB issue before so don't really want to beat a dead horse too much again (you'll forgive the pun). I think the consensus was that we need to get it done and it was mostly a question of who was going to do the work.
It has long been my opinion that we should have replaced EJB in Java EE 7 and deprecated it in Java EE 8. It's water under the bridge now, but not doing this has hurt due Java EE adoption in a way I have repeatedly seen first hand. I do hope we can focus
on putting this problem finally behind us quickly in Jakarta EE. The problem with EJB is both technical and marketing oriented.
Hi,
EJB was just an example, as could be JSP. EJB has indeed a lot of unique features like you said (as has SOAP over REST). I don't think there is much interest in developing the EJB spec further, which makes the API a candidate for the "stable spec". Most people
I've talked to would like to see its good features available as CDI extensions. Apparently Oracle didn't have much interest on that lately, but the Concurrency Utilities project is now led by Steve Millidge (Payara) [1] and EJB and JMS will be led by David
Blevins (TomiTribe) [2].
That makes me hope we'll be able to move the required features soon. As shown by Arjan, most is already achievable right now with the existing APIs.
Even then, we might not want to *deprecate* EJBs, but new users should be encouraged to use CDI, where the effort will be centered.
We can replace the "deprecated" or "stable" term with "not-so-cool-right-now". My emphasis is that we need a way to move users forward without forgetting existing investings.
Deprecating a spec might not be the right way to achieve it. In fact, to my knowledge, the JCP didn't deprecate specs, but it was Java EE which decided that *in its context*, a spec was deprecated or proposed optional. Here I see each committee will have
a different role:
- The technical/steering committee decides that some specific technology is not worth putting much effort into, as it is already well stablished and needs no further development.
- Based on that, the technical/steering committee decides that, in the context of Jakarta EE, that spec isn't on the "bleeding edge" right now, tags it at "stable", and removes them from the proposed "Bleeding Edge Profile", that would be there just for
people who want the latest thing.
- The spec committee won't usually update the spec, not because the project is dead, but because the project is already stable and little updates would be needed. The technology is not deprecated, so one can expect some update eventually if there's enough
interest. The spec itself wouldn't be deprecated nor tagged stable. That just exists in the context of Jakarta EE distributions.
SOAP is still *widely* used. We don't see articles on how cool it is, but most of us still have to deal with it in one way or another. People in need for it could just add the implementation dependency, configure the server to provide the module (if the runtime
supports that kind of modularity), or just use the Full Profile as we've been all doing until now.
Nobody complains the Web Profile doesn't contain JAX-WS or remote EJBs, because that profile it's specifically dedicated to web developments. My opinion is that we need a way to separate what most modern developments need, without implying that a specific technology
is dead and should not be used anymore. Until now we only had the deprecation process, but that doesn't fit all cases.
Hope my opinion is clearer now.
@Guillermo, how can you qualify EJB 3 as deprecated if we don't have any standard alternatives for scheduling, concurrency, pooling, security...
@all, I work in industry where all our integration partners use SOAP :-/ and I think I am not alone.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community