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
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)  and EJB and JMS
will be led by David Blevins (TomiTribe) .
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
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
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,
@all, I work in industry where all
our integration partners use SOAP :-/
and I think I am not alone.
jakarta.ee-community mailing list
To change your delivery options, retrieve
your password, or unsubscribe from this