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.
This is where Spring Boot comes in.
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:
Convention over Configuration. This states that by convention, certain default configurations should be used.
Auto Discovery of Libraries. The idea behind auto discovery is that, when one or more modules or libraries are available on the classpath, the features or behaviour associated with those modules should be auto configured. For example, if the Spring Web or Spring Web Services modules are on the classpath, then Spring Boot assumes that this is a web-based application and will start up an embedded Web Application server (such as Tomcat or Jetty) and look to handle HTTP requests when they are received. Of course, you can override any of the defaults used by Spring Boot (such as the default port used by Tomcat etc.).
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:
Manually by a developer creating an appropriate project with Maven or Gradle configuration information.
Via the command line using the Spring Boot CLI (Command Line Interface).
Via a web-based tool called Spring Initializr which allows you to interactively set up the language to be used (Java, Kotlin or Groovy), the JVM version, project details and Spring Boot starter dependencies.
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:
Provides an opinionated approach to the structure and configuration of a Spring application.
Handles default library dependencies as required by different types of Spring project.
Includes an easy to use application launcher.
Discovers what libraries are available at runtime and triggers appropriate runtime behaviour.