(Updated Apr 2021)
First of all, "Java EE" has since Sep 2019 been renamed to "Jakarta EE", starting with version 8. Historically, there was also the term "J2EE" which covered versions 1.2 until 1.4. The "Java EE" covered versions 5 until 8. See also Java Platform, Enterprise Edition, History on Wikipedia.
Is Jakarta EE just a specification? What I mean is: Is EJB Jakarta EE?
Jakarta EE is indeed an abstract specification. Anybody is open to develop and provide a working implementation of the specification. The concrete implementations are the so-called application servers, like WildFly, TomEE, GlassFish, Liberty, WebLogic, etc. There are also servlet containers which implement only the JSP/Servlet part of the huge Jakarta EE API, such as Tomcat, Jetty, etc.
We, Jakarta EE developers, should write code utilizing the specification (i.e. import only jakarta.* classes in our code instead of implementation specific classes such as org.jboss.wildfly.*, com.sun.glassfish.*, etc) and then we'll be able to run our code on any implementation (thus, on any application server). If you're familiar with JDBC, it's basically the same concept as how JDBC drivers work. See also a.o. In simplest terms, what is a factory?
EJB is part of the Jakarta EE specification. Look, it's in the Jakarta EE API. Full-fledged Jakarta EE application servers support it out the box, but simple JSP/Servlet containers don't.
See also:
Are EJB/Spring different implementations of Jakarta EE?
No, as said, EJB is part of Jakarta EE. Spring is a standalone framework which substitutes and improves many parts of Jakarta EE. Spring doesn't necessarily require Jakarta EE to run. A bare-bones servlet container like Tomcat is already sufficient. Simply put, Spring is a competitor of Jakarta EE. E.g. "Spring" (standalone) competes EJB/JTA, Spring MVC competes JSF/JAX-RS/MVC, Spring DI/IoC/AOP competes CDI, Spring Security competes JAAS/JASPIC, etc.
Back during the old J2EE/EJB2 times, the EJB2 API was terrible to implement and maintain. Spring was then a much better alternative to EJB2. But since EJB3 (Java EE 5), the EJB API was much improved based on lessons learnt from Spring. Since CDI (Java EE 6), there's not really a reason to look at again another framework like Spring to make the developers more easy as to developing among others the service layer.
Only when you're using a bare-bones servlet container such as Tomcat and can't move on to a Jakarta EE server, then Spring is more attractive as it's easier to install Spring on Tomcat. It isn't possible to install e.g. an EJB container on Tomcat without modifying the server itself, you would basically be reinventing TomEE.
See also:
