Java EE vs Spring Framework

The Java community has always seen a debate sparked when Spring and Java EE are mentioned. Such an argument sees no end when there are developers, evangelists or nerds that support either framework. However, there are definitely aspects of each framework that appeal to the needs of a developer, team, and project, in different situations. In this article, we’ll break down the differences between these two famous Java frameworks - EE and Spring. 

Spring’s Emergence and Reasons

The Spring framework emerged in the year 2004, developed by Rod Johnson. The motivation behind the Spring framework was the inherent complexities of the Java 2 Platform Enterprise Edition, and the Enterprise Java Beans. When Spring was introduced, along with Hibernate, there were shockwaves in the Java EE developer force, and that led to EJB 3 as well as JPA 1, being included in the EE5, reducing its clutter a bit. 

Spring has been appealing to a large number of developers as they work on discrete java projects and assignments, owing to the fact that it is pragmatic in its outlook, while having a highly respectable time-to-market. This makes it much easier to shift towards technological innovations, such as microservices, cloud-based applications, AMQP, and NoSQL, to name a few.

The impact of Spring on Java EE has been seen since 2006, where EE has started to lay emphasis on simplicity and being easier to incorporate for developers. However, the time-to-market for Java EE has been slower nevertheless. 

Spring vs. Java EE - Standard and Framework

Spring is essentially a framework that is used for quickly getting an application up and running. Java Spring was developed by Rod Johnson and made available to the public under the Apache license version 2.0. This framework offers a number of core features that can be used for creating any Java-based application. One of the main reasons why developers flock towards Spring is its highly organized packages and classes. This makes it much easier for developers as they only have to be concerned with the packages and classes they require, ignoring the remaining ones they don’t need. 

Spring follows a Model-View-Controller (MVC) design pattern that offers an alternate choice to other web frameworks. On the other hand, Java Enterprise Edition is essentially just a set of specifications, not a framework in itself. EE provides specifications that are suited for enterprise-level functionality, which includes web services, and distributed computing. Applications built with Java EE are executed on reference runtimes, such as application servers, that are responsible for security, concurrency, scalability, and transactions.

The Java Enterprise Edition is essentially an attribute of the specifications that govern it. This specification revolves around providing a definition of the Application Programming Interfaces (APIs) that are part of it, along with their interactions. 

Every Java Community Process set of specifications demand that an application needs to meet a set of conformance benchmarks so that it can be referred to as Java EE compliant. Java EE defines the specifications for a number of applications and types, with each of them serving various purposes. Web specifications, enterprise applications, web service specifications, among others, are what all defined by the Java EE standard. 

So, now it’s clear that Java Spring and EE are fairly different for the primary reason that they are designed differently i.e. Spring is an MVC framework, while EE is a set of standards. 

Frequently asked Java Spring Interview Questions & Answers

Portability

Java EE has a number of issues when it comes to portability, owing to its strict set of specifications. The components that are used in an application can be drawn into a compatible container that is chosen by the developer. 

To keep things simple, you as a developer can provide a wrapper for the business logic in a certain manner as well as offer persistence for the purpose of reading, write, and update and delete operation. The choice available is for 14 such vendors. It is expected that an application should be portable in nature, which can be moved from one application server to another without hassle. However, this ideal situation only exists on certain occasions with EE. There are presently just three vendors that actually offer compliance with EE 7. 

In certain cases, the implementation may actually be specific to a particular provider and hence, migrating the application to another environment would drain a lot of resources as well as time. The factor to consider here that the issues discussed above, just grow with the complexity of an app. It is very understandable that a small sample application can be easily ported on a different platform, as the dependencies are virtually nil. 

However, Spring is just dependent on VMWare, which makes this just so much simpler. This is primarily due to the fact that VMWare works like a wrapper by bringing together several libraries in a single space, which offers quicker access along with the ability to configure. Spring’s flexibility is worth considering here, as Spring applications can also be deployed on a pure JEE server. Several lightweight containers, such as Netty, Tomcat, and Jetty, may also be used for deploying Spring applications, which lowers the strain on a project’s budget.

Testing

Testing is critical for even the smallest of applications, and every developer should follow the best practices to do so. Unit tests are the most common, but in the case of managed environments, such as Spring or Java EE, they’re almost pointless. 

In this case, it is preferred to write integration tests. If we look at Java EE, we have quite a few to choose from - TomEE APIs, Payara APIs, and Arquillian. Arquillian is considered really useful when it comes to integration testing. It is believed that writing tests for initiating containers, checking for components, available services, initiating code, and more, would be much simpler if there exists one container and hence, one API for that container. 

In the Java EE specification, there exist no such standards about using APIs for handling containers. Integration testing would require proprietary APIs, such as Payara, TomEE, and Aquillian. Since there are varied opinions when it comes to using proprietary APIs for integration testing, and there are no clear guidelines, it is understood that testing is not a standard in Java EE. 

Testing is at the core of the Spring framework. The developer of Spring, Rod Johnson, mentions about testing J2EE applications in his book, Expert One-on-One J2EE Design and Development, and how he created Spring with testing being the primary focus. If we go about conducting an integration test using Spring, we could compare the complexity of both. 

Here’s some sample code below that consists of a Main class in Spring:

@SpringBootApplication
public class SpringApp{

  public static void main(String[] args) {
    SpringApplication.run(SpringApp.class, args);
  }
}

It is worth considering that testing this application is extremely simple, as all that needs to be done is to include a JUnit runner. This is done in the code below:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = SpringApp.class)
public class AddressEndpointTest {
 
  @Test
  public void anyMethod() throws Exception {
    // Program code to be inserted
  }
}

Testing in Spring is much simpler, in comparison to the Arquillian API for EE. Arquillian requires the developer to add their class files to an archive, along with the associated dependencies. This archive is then taken and placed inside a container. 

Learning Curve

The learning curve in the case of both frameworks is steep. But, the complexity of Spring is definitely less than that of EE. Developers find it fairly easier to get adapted to the coding style of Spring.