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
