I have been doing Java SE for some years now and moving on to Java EE. However, I have some trouble understanding some aspects of Java EE.
Is Java EE just a specification? What I mean is: Is EJB Java EE?
Are EJB/Spring different implementations of Java EE?
I am sorry to ask but I have some difficulties to understand what Java EE is.
Could someone explain what Java EE is? And EJB?
(Updated Feb 2022)
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 term "Java EE" covered versions 5 until 8. See also Jakarta EE, 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:
Where can I find a list of all the reference implementations for Java EE 6?
Java / Jakarta EE web development, where do I start and what skills do I need?
What to learn for making Java web applications in Java EE 6?
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:
When is it necessary or convenient to use Spring or EJB3 or all of them together?
Java EE 6 vs. Spring 3 stack
Using JSF as view technology of Spring MVC
Java Enterprise Edition (Java EE) is an umbrella specification that references a number of other more detailed specifications, of which Enterprise JavaBeans (EJB) is one of the more important ones.
Read this - it explains the difference between Java EE and Spring
Thanks...
Source -- Java 2 Platform, Enterprise Edition (J2EE) defines the standard for developing component-based multitier enterprise applications. J2EE simplifies building enterprise applications that are portable, scalable, and that integrate easily with legacy applications and data .
Source -- Enterprise JavaBeans (EJB) technology is the server-side component architecture for Java Platform, Enterprise Edition (Java EE). EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology.
Is Java EE just a specification? What I mean is: Is EJB Java EE?
Java EE is a specification.
EJB is server side component architecture for Java EE
Are EJB/Spring different implementations of Java EE?
Both EJB and Spring are different frameworks following Java EE.
J2EE/JEE/Jakarta EE
Java Enterprise Edition (JEE) is used to develop distributed application &
web services.
It’s a component based approach to develop web app.
JEE web apps are considered as 3 tiered apps, since it is divided on 3
different machines/tiers
Client (Presentation)
J2EE sever (Application/Business)
Database (Data Access)
Everything you need to know about Java EE may be found by starting # Oracle official website, among other. You may also find interesting to read the specification APIs for release 8. It is worth taking the time to go through the Java EE 8 tutorial. You may want to start with it actually, because it provides a very good overview of the whole platform.
To put simply - JavaEE is a platform.
It is made up of many specifications which are just APIs. The specific concrete implementations of these APIs are the so called 'Reference Implementation'
EJB is just one specification within the JavaEE platform
No, Spring is a application framework that can allow you/has support for you to develop JavaEE applications
EJB is Enterprise Java Beans
Related
I spent the last few days trying to wrap my head around the Java ecosystem, looking at the components (JVM, JRE, JDK, SE, EE, etc.), licensing and others.
As far as I understand, Jakarta EE (formerly Java EE, J2EE) is an API on top of Java SE with lots of enterprise-grade features and lots of (mostly deprecated) web technologies. Spring has similar goals but a different approach and runs on "standard" Java SE.
But then what about Tomcat? Tomcat is defined as an implementation of Jakarta EE features. I understand that TomEE is a "superset" of Tomcat with more Jakarta EE features.
Nevertheless, Spring (needs / requires) Tomcat as a runtime. Does that mean that Spring uses Jakarta EE features? Could you please clarify these differences?
Tomcat 10 offers JakartaEE, but no JEE.
Versions lower than 10 implement JEE but no JakartaEE. Here's the overview
To my knowledge, spring works on JEE, but not JakartaEE (at the time of writing this answer). So if you want to use tomcat with spring, pick version 9 (as of today), or another JEE container.
Spring does not implement most of the JakartaEE/JavaEE specification. One of the Spring project that implements a JSR defined in JavaEE that I can think of is spring-batch (see this).
Instead, Spring mainly provides support to integrate with a carefully selected individual specifications from JavaEE to allow developers to work with the implementation of these specifications using the Spring programming model (See this for more detail.)
Tomcat is the implementation of the Servlet API which is one of the specification that is included in JakartaEE/JavaEE. To me , the most useful and modern support provided by Spring for it is spring-boot allows to package the application using an embeddable Tomcat such that we can simply deploy and run the application as a JAR without install a Tomcat server separately and deploy the WAR to it.
I've noticed recently about some APIs that are supposed to be part of Java EE, but seem to be implemented in Java SE. For example, there's JAX-WS, which is a Java EE API, but can be used completely in a Java SE project.
Is there anything I'm getting wrong? There are some APIs from Java EE implemented in Java SE out of the box? Where can I find information about what JEE APIs are available in JSE as well?
Java SE APIs are basically the Java Standard Library. There's a nice diagram on the Java Platform Docs
And here is a list of the "Base Libraries": https://docs.oracle.com/javase/8/docs/technotes/guides/index.html#langutil
which includes java.lang, math, collections, reflection, concurrency, logging, preferences, io, net .... (notice that many of these are not even widely used by the Java community, like logging - where slf4j-api is the de-factor standard).
Then, there's also the "Integration Libraries" that include things like JDBC (Database Access) and JNDI (things like LDAP), and "User Interface Libraries" (used to be Swing and JavaFX, but now it's back to only Swing).
The Java EE APIs include many other things, like email and JAX-RS as you mention, which extend the Java libraries and in theory, should interact and work on top of the SE APIs, providing a comprehensive whole suited for enterprisey development.
They are not implemented by the JavaSE runtime!
However, each JavaEE API can be implemented independently by independent organisations (or anyone that has enough spare time to spend on the effort) and be used from a mostly Java SE application on their own. This is why there's lots of Servlet containers (Tomcat, Jetty, GlassFish and many others) available which implement the Servlet API and not much else!
It should be noted that quite recently, JavaEE has become officially the JakartaEE project. There's a searchable list of projects here.
I'd also like to mention there's another big set of APIs that were developed in parallel with JavaEE in the OSGi world, by the OSGi Alliance, that focussed on modularity of dynamic Java applications.
Finally, a competing framework, Spring is quite dominant in the Java world (and has actually influenced a lot the development of JavaEE itself), and even today, with beginner-friendly projects like Spring Boot is probably more popular than JavaEE itself!
Myself, I like to stick with only Java SE, a few EE APIs like Servlets and JDBC (EDIT: jdbc is in the standard lib!) for essentials, and community driven projects (see for example Micronaut and Vert.x) which are really cool stuff and are not based on any standards at all!
In summary, the Java world is big and there's a lot of variety! JavaEE is but a small part of it.
In the section "Java EE 7 architecture" (page 11) of Java EE 7 Developer Handbook, it says (emphasis mine):
Java EE architecture can be thought of as four separate containers.
The first one is called the EJB container for lifecycle management of
Enterprise Java Beans and the second container is the web container
for lifecycle management of Java Servlets and managed beans. The third
container is called the Application Client container, which manages
the lifecycle of the client-side components. Finally, the fourth
container is reserved for Java Applets and their lifecycle.
[something about jars]
A fully conformant Java EE product, such as Glassfish or JBoss
Application Server has both containers.
Which containers is it referring to when it says "both containers"? Are these the same set of four containers mentioned in the above paragraph?
Less importantly, the paragraph before all this ends with:
For a beginner, reading this section is frankly essential.
What does it mean by "frankly"?
I am Peter A. Pilgrim, the author of the Java EE 7 Developer Handbook. GlassFish and Java EE 7 application servers generally have at least two containers in the running configuration: EJB and Web. There is a third container for CDI.
For beginners, I appreciate this is very confusing and comes down to the history of Java EE (J2EE) and the Java web JSRs [standards] in the last 10-15 years. Generally, if you want to use EJB then you need an application server that has an EJB container, if you want to use Java Servlets, JSP, JSF, JAX-RS, and Java WebSocket then you may need an application server that has a Servlet container and if you want to use CDI (Context and Dependency Injection) beans then you need an application server that has a CDI container.
Lucky there are open source servers available for Java EE 6 and Java EE 7. The other greats news in 2013 is that you will start to have more Java EE 7 choices. GlassFish 4 is the reference implementation for Java EE 7, but it is closely followed by JBoss Wildfly and in the medium term Tomitribe's TomEE server has pledged to support Java EE 7.
If you discover any errata in the book, then can you please submit it to Packt Pub.
HTH
I know this is a stupid question. But I really have very limited knowledge in programming. I've experience writing PHP code back in school, and I know that there is a framework called codeigniter, which includes very basic functions and libraries used for facilitating PHP programming.
Is Java EE to Java and WebLogic like codeigniter to PHP and some php-based web application (e.g., a forum)? I mean, is Java EE a framework or something like that?
Java EE is not a framework. It is a seperate edition of java for Web development process. for deploy(run) web application we need a server. Weblogic is one of the server.
Java EE is a standard. According to this
Java Platform, Enterprise Edition (Java EE) 6 is the industry standard for enterprise Java computing. Utilize the new, lightweight Java EE 6 Web Profile to create next-generation web applications, and the full power of the Java EE 6 platform for enterprise applications. Developers will benefit from productivity improvements with more annotations, more POJOs, simplified packaging, and less XML configuration.
WebSphere Application Server, JBoss Application Server and other are implementations of the above mentioned standards.
Google really helps a lot, please look into it before posting :)
CDI and Bean Validation are Java EE 6 Standard Specifications. Nevertheless, I can use both within Java EE 5 Application Servers (and also within Java SE) by just adding the libraries to the project.
Is this correct?
Are there any disadvantages of using both in Java EE 5 application servers instead of Java EE 6 application servers?
I have to use the Oracle 11 g Suite and JDeveloper. In the meantime, JDeveloper supports JSF 2.0, but I cannot find any support for Bean Validation or CDI. Nevertheless, this is not a problem. There is no IDE support (for code-generation, a step-by-step-guide, or whatever), but I can use these libraries by using the simple java editor. Right?
Java EE 6 is basically a collection of APIs. An application server is Java EE 6 compliant if it implements all those specifications. But you can still use the APIs in an Java EE 5 compliant application server. Some people even put EJBs into Tomcat, so technically that's possible. Still it makes sense to use a compliant AS, as it also provides all the services related to the specs.
I believe that's correct.
The disadvantage is that you're a version behind. You may have to modify your code if and when you decide to upgrade to Java EE 6 (e.g. new imports, etc.)
You can pretty easily add Apache OpenWebBeans or JBoss Weld (choose one of the 2 CDI implementations) to your WEB-INF/lib and register the servlet listeners in your web.xml manually. Voila, then you have CDI support!
For JSR-303 Bean Validation it's a bit more tricky, because only JPA2 and JSF2 makes use of it. So you would need to add Myfaces2 and Hibernate-3.5, EclipseLink2 or OpenJPA2 to your local jars and disable the container provided variants.