Overview of This Lesson

Refresh this page because I am probably still making changes to it.

Important Resources

Bookmark these resources, as you'll be referring to them as you learn the basics of Spring Boot Applications:


Java Beans and Bean Law

Before getting int more Java programming, it's important to understand a couple of terms. They may or may not be new to you, depending on how much extra reading you've been doing, but they're terms for things you've actually already been coding in Java! You've already written POJOs and Java Beans!

POJO stands for Plain Old Java Object. A POJO is a Java class that's simple and doesn't extend any classes or implement any interfaces. It's generally a re-usable class used to perform simple tasks in a program. A POJO has the following characterisitcs:

A Java Bean is a type of POJO that models business objects. A Java Bean MUST follow these rules in order to be considered a Java Bean:

Why have such strict rules for Java Beans? Because it means that other components and frameworks are able to use beans, knowing that the bean will have a certain kind of structure (e.g. a default constructor, accessors, mutators, etc). For example, a component might be able to take any bean object and display the object's state in the component's area on a GUI. For this to work, the component needs to be able to take the bean (requiring Java to invoke the bean's default constructor with no arguments), set the values of the object's data members to create its state (calling the bean's mutator methods for each data member), and then retrieve the data member values to display on the GUI (requiring Java to call the bean's accessor methods to retrieve each data member's value).

What is java.io.Serializable?

The Serializable interface is used to take an object and its state and convert it into a series of bytes so that it can be saved to a file. That process is called "serialization". Later, a program can read those bytes and "deserialize" them into the object, with its state intact. For example, say you have the following Java Bean:

- isbn : String
- title: String
- author : String
- year : int
- publisher : String
- price : double
+ Book()
+ Book(isbn : String, title : String, author : String, year : int, publisher : String, price : double)
+ getIsbn() : String
+ setIsbn(isbn : String) : void
+ getTitle() : String
+ setTitle(title : String) : void
+ getAuthor() : String
+ setAuthor(author : String) : void
+ getYear() : int
+ setYear(year : int) : void
+ getPublisher() : String
+ setPublisher(publisher : String)
+ getPrice() : price
+ setPrice(price : double)
+ toString() : String
+ equals(Object o) : boolean

Now, say you have the following book object:

isbn: 978-9920002123
title: How to Write Code No One Else Can Read
author: Dick Coder
year: 2014
publisher: Sydney House Publishers
price: $61.49

Assuming Book implements Serializable (it must, since this is a valid Java Bean), you can then use an ObjectOutputStream to convert the above book object and its state into a stream of bytes that are then saved to a file (serialization). You can also use an ObjectInputStream to read the stream of bytes and convert it back into the above book object, with its state intact (deserialization).

In some cases, serialization and deserialization might be easier or more efficient than simply saving each field value as a record of text in a flat file, XML file, JSON file, or as a record in a database.

You won't need to override any methods when you implement serializable on your Java Bean. For this course, we won't even be using it for anything, except to ensure that our beans follow the rules for Java Beans.

When you make a bean serializable, you'll need to add an extra data member called serialVersionUID. serialVersionUID is always a long integer, and it should be static final. Other than that, it can have any modifier (public, private, etc) although usually it's private.

The serialVersionUID variable is always initialized to a long integer. This value is a unique ID (UID). The JVM uses this ID to make sure that the class you used to serialze an object is the exact same class you're using to deserialize the object. Imagine serializing an object with ClassA and then accidentally deserializing it with ClassB!! That could result in some problems in your application, especially since ClassB probably has different data members from ClassA. The JVM won't let this happen because it checks the serialVersionUID when you deserialize, to make sure it matches the same serialVersionUID on the classed that serialized the object.

serialVersionUID should then be assigned a random long integer, and most editors will have some kind of shortcut that will make up a very large random value for you. When we're not going to be serializing or deserializing instances of our class, we just assign it the literal 1L (that's the number 1, followed by upper-case L, since 1 is by default an int).

private static final long serialVersionUID = 1L;
// or
private static final long serialVersionUID = 86749450483745054673L;

You won't need to create accessors and mutators for serialVersionUID.

Where Would You Use Serialization?

You would use serialization any time you needed to store an object and its state.

Example 1

You are writing software to manage drivers and customers of a ride-sharing service. Whenever a new customer requests a ride, a Trip object is constructed. A Trip object contains data for the customer, the pick up location, the date and time, the requested destination, and the driver assigned to the trip. Once the driver has driven and dropped off the customer, the Trip object is no longer needed in the program, but it does need to be saved to a file in case it needs to be reconstructed later (e.g. when a driver or customer wants to view a history of their trips). You can use serialization to save the Trip object to the file and then reconstruct it later.

If you didn't use serialization, you could keep a database table of trips and have columns for customer, pick up location, date and time, requested destination, and driver. Then when you save a Trip object, you simply call the accessor method for each data member and write the return value into a row of the table.

Example 2

A program is used to keep track of players that are currently logged into an online game. Whenever a player starts a new session, a PlayerSession object is created. A PlayerSession object stores the player's name, the date/time they logged in, their current activity (e.g. idle, engaged in a task, editing their character, etc), and their virtual location within the game grid. When the game server needs to do a restart, a program runs that saves all the active PlayerSession objects to a file, right before the game shuts down, so that when the game starts back up, all the players can be reconstructed exactly as they were, doing what they were doing, before the shut down began.

Overview of Terms/Technologies

This is simply an overview of the various terms and technologies you'll be using in this course.

Writing Spring Boot Applications

Java EE (JEE)


Spring, Spring Boot



JDBC - Java Database Connectivity

Architecture of a Java Web Application

MVC - Model View Controller

See also Model View Controller Design Pattern.

For Java Web Apps:

As usual, we try to keep each part as independent as possible.