The goal of this course is to master the design and development challenges of a single application instance to be deployed in an enterprise-ready Java application framework. This course provides the bedrock for materializing broader architectural solutions within the body of a single instance.

This comprehensive course explores core application aspects for developing, configuring, securing, deploying, and testing a Java-based service using a layered set of modern frameworks and libraries that can be used to develop full services and microservices to be deployed within a container. The emphasis of this course is on the center of the application (e.g., Spring, Spring Boot, Spring Data, and Spring Security) and will lay the foundation for other aspects (e.g., API, SQL and NoSQL data tiers, distributed services) covered in related courses.

Students will learn thru lecture, examples, and hands-on experience in building multi-tier enterprise services using a configurable set of server-side technologies.

Students will learn to:

Using modern development tools students will design and implement several significant programming projects using the above-mentioned technologies in an environment that they will manage.

The course is continually updated and currently based on Java 21, Maven 3, Spring 6.x, and Spring Boot 3.x.

The course uses no mandatory text. The course comes with many examples, course notes for each topic, and references to other free Internet resources.

Students are required to establish a local development environment.

Lectures are conducted live each week and reflect recent/ongoing student activity. Students may optionally attend the lecture live at JHU, online, and/or watch the recording based on their personal schedule and review. There is no required attendance for the live lecture. Emphasis will be made to make the recorded video a valuable asset in all cases.

The course materials consist of a large set of examples that you will download, build, and work with locally. The course also provides a set of detailed course notes for each lecture and an associated assignment active at all times during the semester. Topics and assignments have been grouped into application development, service/API tier, containers, and data tier. Each group consists of multiple topics that span one or more weeks.

The examples are available in a Gitlab public repository. The course notes are available in HTML and PDF format for download. All content or links to content is published on the course public website (https://jcs.ep.jhu.edu/ejava-springboot/). To help you locate and focus on current content and not be overwhelmed with the entire semester, examples and links to content are activated as the semester progresses. A list of "What is new" and "Student TODOs" is published weekly before class to help you keep up to date and locate relevant material. The complete set of content from the previous semester is always available from the legacy link (https://jcs.ep.jhu.edu/legacy-ejava-springboot/)

Collaboration of ideas and approaches are strongly encouraged. You may use partial solutions provided by others as a part of your project submission. However, the bulk usage of another students implementation or project will result in a 0 for the project. There is a difference between sharing ideas/code snippets and turning in someone else’s work as your own. When in doubt, document your sources.

Do not host your course assignments in a public Internet repository.

I am available at least 20min before class, breaks, and most times after class for extra discussion. I monitor/respond to e-mails and the newsgroup discussions and hold ad-hoc office hours via Zoom in the evening and early morning hours (EST) plus weekends.

I provide detailed answers to assignment and technical questions through the course newsgroup. You can get individual, non-technical questions answered via the instructor email.

I provide detailed answers to assignment and technical questions through the course newsgroup. You can get individual, non-technical questions answered via email but please direct all technical and assignment questions to the newsgroup. If you have a question or make a discovery — it is likely pertinent to most of the class and you are the first to identify.

I typically respond to all e-mails and newsgroup posts in the evening and early morning hours (EST). Rarely will a response take longer than 24 hours. It is very common for me to ask for a copy of your broken project so that I can provide more analysis and precise feedback. This is commonly transmitted as an early submission in Canvas.

Students needing further assistance are welcome to schedule a web meeting using Zoom Conferencing. Most conference times will be between 8 and 10pm EST and 6am to 5pm EST weekends.

You should test your application prior to submission by

The student will:

At the conclusion of these instructions, the student will have:

You will need a JDK 21 compiler and its accompanying JRE environment immediately in class. Everything we do will revolve around a JVM.

After installing and placing the bin directory in your PATH, you should be able to execute the following commands and output a version 21.x of the JRE and compiler.

You will need a Git client immediately in class. Note that most IDEs have a built-in/internal Git client capability, so the command line client shown here may not be absolutely necessary. If you chose to use your built-in IDE Git client, just translate any command-line instructions to GUI commands. If you have git already installed, it is highly unlikely you need to upgrade.

Download and install a Git Client.

Checkout the course baseline.

Each week you will want to update your copy of the examples as I updated and release changes.

You will need Maven immediately in class. We use Maven to create repeatable and portable builds in class. This software build system is rivaled by Gradle. However, everything presented in this course is based on Maven and there is no feasible way to make that optional.

Download and install Maven 3.

Place the $MAVEN_HOME/bin directory in your $PATH so that the mvn command can be found.

Setup any custom settings in $HOME/.m2/settings.xml. This is an area where you and I can define environment-specific values referenced by the build.

Attempt to build the source tree. Report any issues to the course newsgroup.

You will realistically need a Java IDE very early in class. If you are a die-hard vi, emacs, or text editor user — you can do a lot with your current toolset and Maven. However, when it comes to code refactoring, inspecting framework API classes, and debugging, there is no substitute for a good IDE. I have used Eclipse/STS for many years and some students in previous semester have used Eclipse installations from a previous Java-development course or work experience. They are free and work well. I will actively be using IntelliJ IDEA Community Edition. The community edition is free and contains most of the needed support. The professional edition is available free for 1 year (plus renewals) to anyone supplying a .edu e-mail.

Download and install an IDE for Java development.

Load an attempt to run the examples in

Within the first month of the course, it will be helpful for you to have a client that can issue POST, PUT, and DELETE commands in addition to GET commands over HTTP. This will not be necessary until a few weeks into the semester.

Some options include:

We will cover and make use of Docker since it is highly likely that anything you develop professionally will be deployed with Docker or will leverage it in some way. Spring/Spring Boot has also embraced Docker and Testcontainers as their preferred integration environment. There will be time-savings setup of backend databases as well as options in assignments where Docker desired. Once the initial investment of installing Docker has been tackled — software deployments, installation, and executions become very portable and easy to achieve.

Docker can serve three purposes in class:

Without Docker installation, you will

Download and install Docker (called "Docker Desktop" these days).

You will need MongoDB in the later 1/3 of the course. It is somewhat easy to install locally, but a mindless snap — configured exactly the way we need it to be — if we use Docker. Feel free to activate a free Atlas account if you wish, but what gets turned in for grading should either use a standard local URL (using Flapdoodle (via Maven), Docker, or Testcontainers).

If you have not and will not be installing Docker, you will need to install and set up a local instance of Mongo.

The student will learn:

At the conclusion of this lecture, the student will be able to:

On the positive side, we do this because we have confidence that we can delegate a portion of our job to code that has been proven to work. We should not need to again test what we are using.

On the negative side, reuse can add dependencies bringing additional size, complexity, and risk to our solution. If all you need is a spoon — do you need to bring the entire kitchen?

A successful software framework is a body code that has been developed from the skeletons of successful and unsuccessful solutions of the past and present within a common domain of challenge. A framework is a generalization of solutions that provides for key abstractions, opportunity for specialization, and supplies default behavior to make the on-ramp easier and also appropriate for simpler solutions.

A framework is much bigger than a pattern instantiation. A pattern is commonly at the level of specific object interactions. We typically have created or commanded something at the completion of a pattern — but we have a long way to go in order to complete our overall solution goal.

A successful framework is more than many patterns grouped together. Many patterns together is just a sea of calls — like a large city street at rush hour. There is a pattern of when people stop and go, make turns, speed up, or yield to let someone into traffic. Individual tasks are accomplished, but even if you could step back a bit — there is little to be understood by all the interactions.

A framework normally has a complex purpose. We have typically accomplished something of significance or difficulty once we have harnessed a framework to perform a specific goal. Users of frameworks are commonly not alone. Similar accomplishments are achieved by others with similar challenges but varying requirements.

Well-designed and popular frameworks can operate at different scale — not just a one-size-fits-all all-of-the-time. This could be for different sized environments or simply for developers to have a workbench to learn with, demonstrate, or develop components for specific areas.

The following distinguishing features for a framework are listed on Wikipedia. ^[3] I will use them to structure some further explanations.

A process to enable Inversion of Control (IoC), whereby objects define their dependencies ^[4] and the manager assembles and connects the objects according to definitions.

The "manager" can be your setup code ("POJO" setup) or in realistic cases a "container" (see later definition)

A Plain Old Java Object (POJO) is what the name says it is. It is nothing more than an instantiated Java class.

A POJO normally will address the main purpose of the object and can be missing details or dependencies that give it complete functionality. Those details or dependencies are normally for specialization and extensibility that is considered outside the main purpose of the object.

A component is a fully assembled set of code (one or more POJOs) that can perform its duties for its clients. A component will normally have a well-defined interface and a well-defined set of functions it can perform.

A component can have zero or more dependencies on other components, but there should be no further mandatory assembly once your client code gains access to it.

A container is the assembler and manager of components.

Both Docker and Spring are two popular containers that work at two different levels but share the same core responsibility.

(Framework/Spring) Containers do more than just configure and assemble simple POJOs. Containers can apply layers of functionality onto beans when wrapping them into components. Examples:

Java 8 brought in lambdas and functional processing, which from a strictly syntactical viewpoint is primarily a shorthand for writing an implementation to an interface (or abstract class) with only one abstract method.

You will find many instances in modern libraries where a call will accept a lambda function to implement core business functionality within the scope of the called method. Although — as stated — this is primarily syntactical sugar, it has made method definitions so simple that many more calls take optional lambdas to provide convenient extensions.

The Common Gateway Interface (CGI) was the cornerstone web framework when Java started coming onto the scene. ^[7] CGI was created in 1993 and, for the most part, was a framework for accepting HTTP calls, serving up static content and calling scripts to return dynamic content results. ^[8]

The important part to remember is that CGI was 100% stateless relative to backend resources. Each dynamic script called was a new, heavyweight operating system process and new connection to the database. Java programs were shoehorned into this framework as scripts.

Spring 1.0 was released in 2004 and was an offshoot of a book written by Rod Johnson "Expert One-on-One J2EE Design and Development" that was originally meant to explain how to be successful with J2EE. ^[10]

In a nutshell, Rod Johnson and the other designers of Spring thought that rather than starting with a large architecture like J2EE, one should start with a simple bean and scale up from there without boundaries. Small Spring applications were quickly achieved and gave birth to other frameworks like the Hibernate persistence framework (first released in 2003) which significantly influenced the EJB3/JPA standard. ^[11]

Spring and Spring Boot use many JavaEE(javax)/Jakarta libraries. Spring 6 / Spring Boot 3 updated to Jakarta Maven artifact versions that renamed classes/properties to the jakarta package naming.

The Jakarta Persistence API (JPA), formerly the Java Persistence API, was developed as a part of the JavaEE community and provided a framework definition for persisting objects in a relational database. JPA fully replaced the original EJB Entity Beans standards of earlier releases. It has an API, provider, and user extensions. ^[12] The main providers of JPA were EclipseLink (formerly TopLink from Oracle) and Hibernate.

JPA has been a wildly productive API. It provides simple API access and many extension points for DB/SQL-aware developers to supply more efficient implementations. JPA’s primary downside is likely that it allows Java developers to develop persistent objects without thinking of database concerns first. One could hardly blame that on the framework.

Spring Boot was first released in 2014. Rather than take the "build anything you want, any way you want" approach in Spring, Spring Boot provides a framework for providing an opinionated view of how to build applications. ^[14]

There is no external container in Spring Boot. Everything gets boiled down to an executable JAR and launched by a simple Java main (and a lot of other intelligent code).

Our focus will be on Spring Boot, Spring, and lower-level Spring and external frameworks.

The student will learn:

At the conclusion of this lecture and related exercises, the student will be able to:

Define plugin versions so the module can be deterministically built in multiple environments

The jar packaging will automatically activate the maven-compiler-plugin and maven-jar-plugin. Our definition above identifies the version of the plugin to be used (if used) and any desired configuration of the plugin(s).

One way to surgically add that property is through the maven-jar-plugin

The student will learn:

At the conclusion of this lecture and related exercises, the student will be able to:

I am using a technique below of defining the value in a property so that it is easy to locate and change as well as re-use elsewhere if necessary.

Import springboot-dependencies-plugin. This will define dependencyManagement for us for many artifacts that are relevant to our Spring Boot development.

Realize the parent definition of the spring-boot-starter dependency by declaring it within the child dependencies section. For where we are in this introduction, only the above dependency will be necessary. The imported spring-boot-dependencies will take care of declaring the version#

The figure below shows the parent poms being the source of the passive dependency definitions and the child being the source of the active dependency declarations.

An upgrade to a future dependency version should not require a change of a child module declaration if this pattern is followed.

We saw earlier how we could build a standard executable JAR using the maven-jar-plugin. However, there were some limitations to that approach — especially the fact that a standard Java JAR cannot house dependencies to form a self-contained classpath and Spring Boot will need additional JARs to complete the application bootstrap. Spring Boot uses a custom executable JAR format that can be built with the aid of the spring-boot-maven-plugin. Let’s extend our pom.xml file to enhance the standard JAR to be a Spring Boot executable JAR.

The spring-boot-maven-plugin augmented the standard JAR by adding a few properties to the MANIFEST.MF file

Notice that the size of the Spring Boot executable JAR is significantly larger than the original standard JAR.

Ref: spring.io Appendix E. The Executable Jar Format

Unlike WARs, a standard Java JAR does not provide a way to embed dependency JARs. Common approaches to embed dependencies within a single JAR include a "shaded" JAR where all dependency JAR are unwound and packaged as a single "uber" JAR

Spring Boot creates a custom WAR-like structure

Classes can be configured to have their instances managed by Spring. Class annotations can be used to express the purpose of a class and to trigger Spring into managing them in specific ways. The most generic form of component annotation is @Component. Others will include @Controller, @Service, @Repository, etc. Classes directly annotated with a @Component (or other annotation) indicates that Spring can instantiate instances of this class with no additional assistance from a @Bean factory.

By default, the @SpringBootApplication annotation configured Spring to look at and below the Java package for our SpringBootApp class. I chose to place this component class in the same Java package as the application class

In this portion of the assignment, you will demonstrate your knowledge of building a module containing a pure Java application. You will:

In this portion of the assignment you are going to implement a JAR with a Java main class and execute it.

Your solution will be evaluated on:

In this portion of the assignment you will demonstrate your knowledge of building a simple Spring Boot Application. You will:

In this portion of the assignment, you are going to implement a Spring Boot executable JAR with a Spring Boot application and execute it.

Your solution will be evaluated on:

The student will learn:

At the conclusion of this lecture and related exercises, the student will be able to:

We make the Hello Service visible to our application by adding a dependency on the hello-service-api and hello-service-stdout artifacts. Since the implementation already declares a compile dependency on the interface, we can get away with only declaring a direct dependency just on the implementation.

You can verify the dependencies exist using the tree goal of the dependency plugin.

Next, we add a reference to the Hello interface and define how we can get it injected. In this case, we are using contructor injection where the instance is supplied to the class through a parameter to the constructor.

The @Autowired(required=…​) annotation

There are more details to learn about injection and the lifecycle of a bean. However, we know that we are using constructor injection at this point in time since the dependency is required for the instance to be valid.

In our example:

We can solve this in at least two (2) ways.

To demonstrate, I created an example POJO that identifies its instance and tracks its component lifecycle.

To further demonstrate, I have added a @Configuration class with some options that will be changed during the example.

There are two pairs of Example-consuming @Bean factories: calling and injected.

By default:

That means that:

If we change component scope created by the bean() method to "prototype"…​

…​we get a unique POJO instance/component for each consumer (calling and injected) while proxyBeanMethods is still true.

If we drop the CGLIB proxy, our configuration instance gets lighter, but …​

…​only injected consumers are given "component" beans. The "calling" consumers are given "POJO" beans that lack the potential for interpose.

Keeping the proxy eliminated and reverting back to the default singleton scope for the bean …​

…​shows that only the injected consumers are receiving a singleton instance — initialized as a component, with the potential for interpose.

The student will learn:

At the conclusion of this lecture and related exercises, the student will be able to: