Spring is a very widely used framework in the Java, and increasingly Kotlin, worlds.
Originally developed by Rod Jonson as an alternative to the Java Enterprise Edition approach to building enterprise level applications; the framework was released with the publication of the book ‘Expert One-on-One J2EE Design and Development’ back in October 2002.
Since then there have been several major releases of the framework, with Spring 5.2.7 being the current GA (General Access) release.
At the core of Spring is the concept of Dependency Injection (or DI for short). DI is the idea that an object should have its dependencies injected into it rather than be directly responsible for them. This allows for greater flexibility, easier maintenance and testing; as well as promoting the Separation of Concerns design criteria.
However, Spring is not just about DI. It has grown hugely into an ecosystem of related projects and modules from CRUD based data systems, web applications and web services, cloud-based computing, integration infrastructure, messaging systems, batch processing systems and even security to name just a few.
With this power and flexibility comes some level of complexity. This complexity can act as a barrier to entry to the Spring world and tends to be associated with:
Dependency Management. In some situations, it can be unclear what dependencies / libraries are required to use specific features that are outside of the core Spring modules. At other times it can be difficult to know which version of a set of modules are compatible / required for a given application.
Configuration Confusion. As the number and range of additional Spring modules used in an application grows; the number of configuration classes and / or configuration files can also grow significantly. It can then become difficult to understand how all the components are related and how they interact.
Boiler Plate Code. There can be multiple situations in which it is necessary to provide Boiler Plate code merely to initialise / configure Spring to use a specific feature or module.
Web Based Systems. Such systems need to be able to respond to HTTP requests. To do this, they need to employ Web Application Servers such as Apache’s Tomcat, IBM’s Websphere or Oracle’s WebLogic. The applications being developed must then conform to the Java Web Application format with the correct directory and file structure. Spring Web must also be configured to handle routing the web requests through to the application.
Standalone Applications. In many situations it is desirable to create a standalone Spring application that can be easily run from the command line. Such applications need all the relevant dependencies, required for the application, in a single Jar file. For web-based applications this may require the use of an embedded Web Application Server such as Tomcat or Jetty. This can of course be handled by a developer themselves; but work is required to integrate Spring Web or Spring Web Services with an embedded Tomcat or Jetty server.
Getting Started. Even for relatively simple Spring applications, the overhead associated with just getting started can be significant in terms of project structure, dependencies, configurations etc. This can stop smaller development teams adopting Spring who might otherwise have benefited from it.
None of the above issues are insurmountable and all have been repeatedly solved by every successful Spring project in existence. However, the solutions can be time consuming, confusing for new developers and often involve repeating patterns.
The motivation behind Spring Boot was to standardise, simplify and speed up Spring Application Development. To that end Spring Boot takes an opinionated view of Spring projects. Spring Boot thus assumes a default project structure appropriate to the type of application being developed. It therefore provides a predefined set of library dependencies, auto configures many features, provides a default application launcher and simplifies application deployment.
One of the key features that simplifies Spring Boot application configuration, is the idea of auto-configuration. This is based on two concepts:
To handle library dependencies and lifecycle operations, associated with an application’s build process, Spring can use Maven or Gradle. To kick start the creation of a new project, Spring Boot makes available starter projects that provide an initial set of Maven or Gradle setup. Each Starter project is oriented around a particular Spring module such as a Spring Web, or Spring Data etc. These can be combined together to allow more complex applications to be set up, for example, a Spring Web and Data oriented project. In fact, there are a whole range of Spring Starter projects including Spring JDBC, Spring Data JPA, Spring Data MongoDB, Spring Integration, Spring REST Repositories, Spring Web Services, Spring Security and more.
The creation of a Spring Boot project can by handled in several ways:
The availability of the CLI, and the Spring Initialzr web application, makes it very easy to create a new Spring Boot project and be up and running in a very short space of time.
To Summarise then, the benefits of using Spring Boot over plain old Spring is that it:
