What Is Java Spring?

Perhaps one the hardest parts of explaining Spring is classifying exactly what it is. Typically, Spring is described as a lightweight framework for building Java applications, but that statement brings up two interesting points.

First, you can use Spring to build any application in Java (for example, stand-alone, web, or JEE applications), unlike many other frameworks (such as Apache Struts, which is limited to web applications). Second, the lightweight part of the description doesn’t really refer to the number of classes or the size of the distribution but rather defines the principle of the Spring philosophy as a whole — that is, minimal impact. Spring is lightweight in the sense that you have to make few, if any, changes to your application code to gain the benefits of Spring Core, and should you choose to stop using Spring at any point, you will find doing so quite simple.

Spring 5 is a major release. The entire framework codebase is based on Java 8and is fully compatible with Java 9.

— Support was dropped for Portlet, Velocity, JasperReports, XMLBeans, JDO, Guava, Tiles2, and Hibernate3.

— XML configuration namespaces are now streamed to unversioned schemas; version specific declarations are still supported but validated against the latest XSD schema.

— Overall improvements were introduced by harnessing the full power of Java 8 features.

— The Resource abstraction provides isFile indicator for defensive getFile access.

— Full Servlet 3.1 signature support in Spring-provided Filter implementations.

— Support for Protobuf 3.0.

— Support for JMS 2.0+, JPA 2.1+.

— Introduction of Spring Web Flow, a project that is an alternative to Spring MVC built on a reactive foundation, which means that it is fully asynchronous and non-blocking, intended for use in an event-loop execution model vs. traditional large thread pool with a thread-per-request execution model.

— The web and core modules were adapted to the reactive programming model.

— There are a lot of improvements in the Spring test module. JUnit 5 is now supported, and new annotations were introduced to support the Jupiter programming and extension model such as @SpringJUnitConfig, @SpringJUnitWebConfig, @EnabledIf, @DisabledIf.

— Support for parallel test execution in the Spring TestContext Framework.

Inverting Control or Injecting Dependencies:

The core of the Spring Framework is based on the principle of inversion of control. IoC is a technique that externalizes the creation and management of component dependencies. Consider an example in which class Foo depends on an instance of class Bar to perform some kind of processing. Traditionally, Foo creates an instance of Bar by using the new operator or obtains one from some kind of factory class. Using the IoC approach, an instance of Bar (or a subclass) is provided to Foo at runtime by some external process. Spring’s DI implementation is based on two core Java concepts: JavaBeans and interfaces. When you use Spring as the DI provider, you gain the flexibility of defining dependency configuration within your applications in different ways (for example, XML files, Java configuration classes, annotations within your code. JavaBeans (POJOs) provide a standard mechanism for creating Java resources that are configurable in a number of ways, such as constructors and setter methods.

Interfaces and DI are technologies that are mutually beneficial. Clearly designing and coding an application to interfaces makes for a flexible application, but the complexity of wiring together an application designed using interfaces is quite high and places an additional coding burden on developers.

By using DI, you reduce the amount of code you need to use an interface-based design in your application to almost zero. Likewise, by using interfaces, you can get the most out of DI because your beans can utilize any interface implementation to satisfy their dependency. The use of interfaces also allows Spring to utilize JDK dynamic proxies (the Proxy pattern) to provide powerful concepts such as AOP for crosscutting concerns.

In the context of DI, Spring acts more like a container than a framework — providing instances of your application classes with all the dependencies they need — but it does so in a much less intrusive way. Using Spring for DI relies on nothing more than following the JavaBeans naming conventions within your classes — there are no special classes from which to inherit or proprietary naming schemes to follow. If anything, the only change you make in an application that uses DI is to expose more properties on your JavaBeans, thus allowing more dependencies to be injected at runtime.