49,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
This book takes readers on a comprehensive journey through Spring Boot 3 and Spring Framework 6, starting with the essentials of dependency injection and Spring-managed containers. It then explores core modules and proxies to establish a strong foundation for Java application development. Early chapters guide readers through configuring Spring Boot projects and managing dependencies efficiently.
The middle sections focus heavily on database integration, including relational databases using Spring JDBC, Jakarta Persistence, and advanced Spring Data JPA techniques. Readers will also learn to work with NoSQL databases like MongoDB and Elasticsearch, enhancing their ability to handle various data storage solutions. The book covers the development of web applications using Spring MVC, RESTful API design, and securing web endpoints.
The final chapters emphasize application monitoring with Spring Boot Actuator, logging strategies, and practical deployment options including containerization. Alongside the core content, a dedicated migration chapter assists developers transitioning from Spring Boot 2 to version 3, ensuring they stay current with evolving best practices. This structured approach prepares readers to confidently build, monitor, and deploy modern, production-ready Java applications.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Veröffentlichungsjahr: 2025
Ähnliche
Christian Ullenboom
Spring Boot 3 and Spring Framework 6
Imprint
This e-book is a publication many contributed to, specifically:
Editor Meagan WhiteGerman Edition Editor Patricia SchiewaldCopyeditor Julie McNameeTranslation Christian UllenboomCover Design Graham Geary Shutterstock: 110415056/© liewluck; 65652385/© concept wProduction E-Book Hannah LaneTypesetting E-Book III-satz, Germany
We hope that you liked this e-book. Please share your feedback with us and read the Service Pages to find out how to contact us.
The Library of Congress Cataloging-in-Publication Control Number for the printed edition is as follows: 2023945877
ISBN 978-1-4932-2475-3 (print)ISBN 978-1-4932-2476-0 (e-book)ISBN 978-1-4932-2477-7 (print and e-book)
© 2024 by Rheinwerk Publishing Inc., Boston (MA)1st edition 2024
Notes on Usage
This e-book is protected by copyright. By purchasing this e-book, you have agreed to accept and adhere to the copyrights. You are entitled to use this e-book for personal purposes. You may print and copy it, too, but also only for personal use. Sharing an electronic or printed copy with others, however, is not permitted, neither as a whole nor in parts. Of course, making them available on the internet or in a company network is illegal as well.
For detailed and legally binding usage conditions, please refer to the section Legal Notes.
This e-book copy contains a digital watermark, a signature that indicates which person may use this copy:
Notes on the Screen Presentation
You are reading this e-book in a file format (EPUB or Mobi) that makes the book content adaptable to the display options of your reading device and to your personal needs. That’s a great thing; but unfortunately not every device displays the content in the same way and the rendering of features such as pictures and tables or hyphenation can lead to difficulties. This e-book was optimized for the presentation on as many common reading devices as possible.
If you want to zoom in on a figure (especially in iBooks on the iPad), tap the respective figure once. By tapping once again, you return to the previous screen. You can find more recommendations on the customization of the screen layout on the Service Pages.
Table of Contents
1 Introduction
Spring is a comprehensive framework, so we want to approach it step by step. The first thing you need to do is make sure that the project has the right dependencies. At the end of this chapter, we will have built your first Spring boot project that can be compiled and launched. In the following chapters, we’ll continue to expand this project and fill it with life.
1.1 History of Spring Framework and Your First Spring Project
To begin, let’s take a brief look at the history of the Spring Framework and how Spring Boot came to be. We’ll start with the question of why Java Platform, Standard Edition (Java SE) often isn’t sufficient for enterprise applications.
1.1.1 Tasks of Java Platform, Standard Edition
Java SE provides a solid foundation for creating a wide range of applications. The platform includes essential features and functionalities such as input/output operations, data structures, networking capabilities, date and time calculations, concurrency support, and basic security features. In addition, Java SE includes two libraries, AWT and Swing, that provide graphical user interface components. While Java SE offers a wide range of functionalities, larger tasks may require the use of additional libraries.
1.1.2 Enterprise Requirements
Developing complex business applications often requires a wide range of additional functionalities and technologies beyond what Java SE provides. These additional requirements may include the need for RESTful web services, dynamic web page generation, database access (both relational and nonrelational), messaging systems, application monitoring, emailing, and more.
While Java SE provides a solid foundation for building applications, it doesn’t include all the necessary technologies and tools required for enterprise-level development. To meet these additional requirements, an extended technology stack is needed.
1.1.3 Development of Java Enterprise Frameworks
Sun Microsystems released the first version of Java in the mid-1990s. At that time, the internet was becoming popular, and the demand for dynamically generated web content was increasing. Sun Microsystems quickly responded to this demand by introducing the Servlet API in 1996. This application programming interface (API) allowed developers to write programs that could be executed on web servers and respond to HTTP requests.
The Servlet standard defines an API with which you can ensure your own programs reside in the web server and can be addressed. The Servlet API still plays an important role today and is implemented, for example, by the popular Tomcat servlet container. While the Servlet API is only about reacting to HTTP requests, Sun then introduced the Java Platform, Enterprise Edition at the end of 1999, that is, just under five years after the release of Java SE. This specification is implemented by an application server, which can administer reusable components called Enterprise JavaBeans (now Jakarta Enterprise Beans) on the server side.
The Java 2 Platform, Enterprise Edition(J2EE), had an interesting start, but there were numerous problems with it. For example, the first generation of application servers were memory intensive and had a long startup time. Another problem arose because the business logic was very closely interwoven with the Java Enterprise API. The use of invasive technologies in this context was troublesome because, for example, any J2EE interfaces had to be implemented when implementing the business logic. Another problem was that applications were difficult to test, usually only within the running application server.
The long startup time also meant that automated execution of tests or deployments took a long time. In addition, the Java language didn’t yet have as many features as it has today; for example, annotations weren’t introduced until Java 5. Spring uses a strongly declarative approach to build applications as flexibly as possible. If you go back to 1999, there were no annotations yet. Instead, much had to be coded in XML files, which was the only way to express something declaratively at the time.
Another problem with J2EE was that the specification was a good start, but it didn’t cover many cases. The manufacturers of the application servers were quick to offer their own solution for these problems; the only dilemma was that the application then no longer ran on every application server, of course, but was tied to a technical implementation, creating a vendor lock.
1.1.4 Rod Johnson Develops a Framework
These shortcomings were well known, and one person in particular—Rod Johnson—wanted to improve the situation. He developed a new framework called Interface 21 for his book J2EE Design and Development (Wrox, 2002). This framework was already quite extensive at the time, with around 30,000 lines of code, and was pompously described as the “interface for the 21st century.” The name “Spring,” under which we know it today, came a little later. The interesting thing is that Rod Johnson didn’t plan to write a framework: at the time, he saw himself more as a book author who wanted to show how modern enterprise applications could be developed using J2EE.
Like other authors in this field, Johnson offered the source code of his framework for download on the publisher’s website.[ 2 ] In the Wrox forum, the framework attracted the interest of Jürgen Höller and Yann Caroff in particular. They discussed the code in the Wrox forum and motivated Rod Johnson to put the code on SourceForge. In early 2003, the source code moved from a Wrox publisher download to a project on SourceForge. Caroff also suggested a new name, Spring, which is basically as full-bodied as “Interface 21”; it was supposed to be the new spring for J2EE applications. You can still find the old artifacts and contributions at https://sourceforge.net/projects/springframework/.
A little later, Johnson, Höller, and Caroff founded a company called Interface 21. In March 2004, the first release of the Spring Framework appeared (see Figure 1.1).
Figure 1.1 2004 Spring Web Page Announcing the 1.0 Release[ 3 ]
For a few years, Interface 21 earned money by consulting and implementing software projects. In 2007, Benchmark Capital invested $10 million in Interface 21, which was later renamed SpringSource. VMware acquired SpringSource in August 2009 for about $420 million. Johnson had to be pleased; in mid-2012, he left VMware and withdrew from Spring development.
To sum it up, the Spring Framework is now a serious business endeavor and no longer just a personal project or an offshoot of a book. Thanks to the support of VMware, there are dedicated developers working on improving the framework, and it has become a reliable foundation for creating enterprise-level Java applications.
1.1.5 Spring Framework: Many Configurations Are Required
The Spring Framework was developed in response to the heavyweight J2EE applications that required complex configurations.[ 4 ] The project was initiated around 2002, and in March 2004, the first release, Spring Framework 1.0, was made available. The early versions of the Spring Framework were also complex to set up, but they offered a lighter weight alternative to J2EE. Examples of Spring Framework 1.0 can be found, for example, on GitHub page https://github.com/ullenboom/spring-framework-1.0-samples. There are quite a few projects, including the fairly well-known petclinic. The example, in a modernized form, still exists today.
In the mirrored directory https://github.com/ullenboom/spring-framework-1.0-samples/tree/main/petclinic/war/WEB-INF, several XML files can be made out; this is typical for the former configuration. We have to keep in mind that there were no annotations in the Java language at that time, and whoever wanted to work declaratively had no alternative but to configure the application via XML files.
Let’s look at a (somewhat reformatted) snippet of applicationContext-jdbc.xml to see how components were configured under Spring:
The code excerpt demonstrates how to define and configure Spring-managed beans in the Spring context. The <bean> element specifies the bean ID, class, name, and type. The nested <property> element later leads to the invocation of the bean’s setter. For instance, database connections require details such as the Java Database Connectivity (JDBC) driver’s name, JDBC URL, username, and password, which are declared through an extensive series of property declarations. The <ref local="dataSource"/> element indicates an injection where the Spring-managed bean, transactionManager, requires a dataSource, for instance.
As XML files grew in size, configuring applications became increasingly complicated. However, because there were no other alternatives at the time, configuring applications with XML files was the only option. Fortunately, Spring Framework 2.5 supports Java annotations and configuration, enabling developers to define Spring components in Java rather than XML. This simplified the configuration process considerably, providing a more manageable and streamlined approach to application development.
While the Spring Framework’s flexibility in configuration is an advantage, it also creates a problem. The extensive configurability of Spring programs necessitates configuring everything before the programs can be executed. Setting up a new Spring Framework project from scratch can be time-consuming and challenging, requiring a significant ramp-up time. This issue required a solution, which came in the form of Spring Boot. Spring Boot streamlines the configuration process and reduces ramp-up time, making it easier to set up and run Spring Framework applications.
1.2 Spring Boot
In 2012, Mike Youngstrom suggested on the mailing list that Spring applications should actually be much easier to configure. Here is a small snippet of the message (https://jira.spring.io/browse/SPR-9888):
I think that Spring’s web application architecture can be significantly simplified if it were to provide tools and a reference architecture that leveraged the Spring component and configuration model from top to bottom. Embedding and unifying the configuration of those common web container services within a Spring container bootstrapped from a simple main() method.
The idea of not needing a servlet container to deploy a Spring application was also tempting to others. Instead, the Spring application would have its own main(…) method and could optionally launch an embedded servlet container itself, especially for web applications.
Today, when we refer to Spring applications, we mostly mean Spring applications configured via Spring Boot. The Spring Framework provides the actual capabilities, with certain components added, such as testing and database access, among others. However, all of these components require configuration before they can be used. This is where Spring Boot comes in. It acts as a ring around the framework and creates an appropriate default configuration for all the components, allowing developers to start working right away without worrying about the configuration details. Merely by having a class or setting a few properties, Spring Boot magically provides complex services in context, which is called auto-configuration.[ 5 ]
Currently, Spring Boot has become the de facto standard for building Spring applications. Therefore, from now on, we’ll use the term “Spring” to refer to the combination of Spring Boot and Spring Framework. When we refer to technologies specifically from Spring Framework or Spring Boot, we’ll make that clear. Today, Spring applications are typically configured automatically through Spring Boot.
1.2.1 Spring Boot Versions
The developments on Spring Boot started in 2013. The first release, Spring Boot1.0, appeared in 2014, followed about four years later by the second major release, Spring Boot 2.0. The last minor release, Spring Boot 2.7, has been around since the end of May 2022. Spring Boot 3 appeared in November 2022 and is based on Spring Framework 6, which was completed shortly before.
There are two major lines in the releases so far (see Figure 1.2). The first version of Spring Boot has long been deprecated, and the version 2 branch is the one that is most widely used today. It’s not possible to predict as of today how quickly Spring Boot version 3 will be adopted.
Updates appear regularly. While there used to be a strong focus on feature releases, as in the early years of Java SE and Jakarta Enterprise Edition (Jakarta EE), the Spring Boot team has now also moved away from releasing by feature, to releasing in regular increments. With the Spring Framework, about six to eight weeks pass from one release to the next. That’s why the intervals between Spring Boot releases 2.2, 2.3 . . . are about the same. Additionally, following major or minor updates, regular patches are consistently released. This can be seen quite well by the small dots in the circles in Figure 1.2; in the early days of version 2, there were still patches for version 1, until around the middle of 2019, when the version 1 series was phased out; since then, it has only continued with the version 2 release. From version 2.3 on, there are updates every month.
Figure 1.2 Release Data of the Spring Boot Versions
Regularly updating the Spring Boot version is crucial as it defines a set of sub-versions for libraries that are automatically updated by the Spring team. Therefore, we don’t have to worry about updating these versions ourselves. It’s essential to keep the Spring Boot version up-to-date to take advantage of all the sub-updates.
1.2.2 Support Period
The Spring Framework and also Spring Boot are open source and are under Apache license 2.0. Nevertheless, there is commercial support from VMware; the advantages are documented at https://tanzu.vmware.com/spring-runtime. Support is appropriate when an older version needs to continue to be supported, as is apparent for Spring Boot 2, which will no longer receive support after November 18, 2023. Customers with commercial support currently have until February 18, 2025, to make the switch. Many organizations won’t be able to switch to Java 17 for Spring Boot 3, making commercial support the only safe option. An overview of support time frames is provided at https://spring.io/projects/spring-boot#support (see Figure 1.3).
Figure 1.3 Support Periods of the Different Spring Boot Versions
The yellow shading on the web page shows the commercial support; the green shading shows the bug fixes and updates of the open-source versions.
1.2.3 Alternatives to Spring
The Spring Framework was initially created in response to the complexity and inconvenience of J2EE at the time. However, it has been more than a decade since then, and it’s worth considering whether the criticisms still hold true for the current Java Enterprise Edition. Additionally, it’s worth exploring whether there are viable alternatives to the Spring Framework and whether Spring itself has kept up with modern developments in software development.
J2EE later became Java Enterprise Edition (Java EE), and after some wrangling (Oracle didn’t want to give up the right to the name “Java”), then Jakarta EE. Jakarta EE is a comprehensive continuation of the original J2EE and has little in common with the original. Today, Jakarta EE is a good model for developing large enterprise Java applications.
In addition to the aforementioned alternatives to Spring, there are quite a few other enterprise frameworks on the market:
Dropwizard, www.dropwizard.io (V1, July 2016)
Micronaut, https://micronaut.io (V1, May 2018)
Helidon, https://helidon.io (V1, February 2019)
Quarkus, https://quarkus.io (V1, March 2019)
[»] Note
Mike Youngstrom himself uses Dropwizard as a model for Spring Boot.
To summarize, in principle, there are exciting alternatives to Spring. Jakarta EE also fulfills all the important requirements of an enterprise framework today so that you can write business applications with it. So, why still use Spring?
A comparison between Jakarta EE and Spring isn’t really possible, but a comparison between a Jakarta EE application server and a Spring application makes more sense. We must not forget that Jakarta EE is basically just a bundle of about 20 sub-specifications that an application server fully implements. The parts include the following:
Jakarta Bean Validation
Jakarta Concurrency
Jakarta Enterprise Beans
Jakarta Enterprise Web Services
Jakarta Expression Language
Jakarta Faces
Jakarta Mail
Jakarta Persistence
Jakarta RESTful Web Services
Jakarta Server Pages (JSP)
Jakarta Servlet
There are many more as well, so we have a whole set of part specifications. Spring also uses a lot of these parts, for example, Jakarta Bean Validation. Spring uses this good standard and reference implementation because there’s no reason for the Spring makers to develop something entirely new. The same is true with the Mail API—there is no reason to disdain the Mail API because sending and receiving email isn’t exactly trivial. That is, in the Spring universe, you don’t just develop new standards when the problem is already solved. Another example is the Jakarta Persistence API. O/R mapping with the Jakarta Persistence API is complex enough, and there are mature implementations.
That’s why the comparison is difficult because if we look at the Spring framework, it’s more of an integration framework that encompasses different technologies. If you look for a difference between Jakarta EE and Spring, it’s the application server. The application server is started and runs along all day long, while applications are added, removed, and swapped out all the time. An application server contains a web server that is also always running. A Spring application usually contains an embedded web server, which means that Spring applications usually aren’t deployed in a container, but contain all server components.
Jakarta EE and its application servers aren’t really competitors for the Spring Framework, but there are other developments where alternative frameworks are a bit ahead. Modern frameworks, such as Quarkus, are optimized for microservices and use native compilation. This means that there is no traditional Java virtual machine that is started, reads in the byte code at runtime, and translates it into machine code in several iterations at runtime. The translation is done before the execution and is therefore also called ahead-of-time compilation (AOT compilation). Oracle offers such a compiler, and the technology is part of GraalVM Native Image. This results in a directly executable file at the end, for example, an .exe file in Windows, which we can start by double-clicking on it. Native Java applications have radically reduced startup time and lowered memory consumption. Spring has taken a long time to support native compilation; during that time, other solutions such as Quarkus have found fans. But since Spring Framework 6 and Spring Boot 3, native compilation has also moved in. In addition, other features favor Spring.
The big advantage of the Spring framework is the capability to integrate everything. Let’s compare it again with Jakarta EE: While in the Jakarta environment, we have exactly one API for a task (e.g., email or object-relational mapping [ORM]) with different implementations. In Spring, however, it’s the other way around: there are different APIs and therefore also different implementations. This is well illustrated by the example of an object-relational mapper (O/R mapper). The Jakarta Persistence defines an API for object-relational mapping, but there are definitely alternative approaches, for example, with jOOQ, Querydsl, or Spring Data JDBC, there is more than just one O/R mapper.
While it’s true that a Spring application can use all Jakarta technologies, Spring goes much further. For example, while only Jakarta Faces and JSP are standardized in Jakarta EE, any template engine can be used in the Spring universe. These include Thymeleaf, FreeMarker, Velocity, and, of course, Jakarta Faces. One of Spring’s central approaches is to be noninvasive, that is, not to mix Spring-specific data types with business logic. In the Spring environment, we rarely have any connection to an actual technology; instead, it’s often encapsulated by an abstraction of Spring.
Spring also offers solutions for which there is nothing in the Jakarta EE standard. If you look at the projects on the Spring site, you’ll find many solutions in the cloud environment that can be used to easily develop and manage microservices.
Spring is still one of the best ways to build enterprise applications today, and different surveys show that. JRebel regularly surveys which technologies are used in software development (see Figure 1.4); Spring Boot is at the top of the list (actually up 12 percentage points from last year).[ 6 ]
The combination of Spring Boot and the Tomcat servlet container is what most teams use today for modern Java enterprise applications. Of course, other Java enterprise frameworks are also used, but the share isn’t high at the moment.
Figure 1.4 Spring Boot Penetration according to a Survey by JRebel
[»] Note
The progression of the development of Java applications is somewhat peculiar: Initially, Java programs were executed within a container—the enterprise application server. Then, containers were deemed obsolete, and applications had to contain all components. However, in the present scenario, there is a trend of moving back toward some form of container, where applications are typically hosted in the cloud per the serverless model.
1.2.4 Setting Up a Spring Boot Project
There are several ways to build new Spring Boot projects. A Spring Boot project is essentially a Java project that includes a few classes in its classpath. Nowadays, dependencies aren’t manually added to the classpath; instead, build tools such as Maven or Gradle are commonly used to manage them. While building a Spring Boot project manually isn’t complicated, it’s advisable to use a project generator.
Spring Initializr
With the Initializr, there is a web-based service that we can use directly in the browser. In most modern development environments, this is also directly integrated via dialogs. Let’s take a look at the Initializr at https://start.spring.io/ (see Figure 1.5).
We can choose whether a Maven or a Gradle project as desired; in this case, we choose Maven. Next, we can set the programming language. Language options include Java, Kotlin, and Groovy, with Spring’s reference documentation featuring examples in both Java and Kotlin, highlighting the importance of Kotlin in backend development. Java is the default language, and we'll keep it that way.
Figure 1.5 Spring Initializr Website
