Refresh this page because I am probably still making changes to it.
Bookmark these resources, as you'll be referring to them as you learn the basics of Spring Boot Applications:
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).
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:
| Book |
| - 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:
| Book 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.
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.
This is simply an overview of the various terms and technologies you'll be using in this course.
See also Model View Controller Design Pattern.
For Java Web Apps:
As usual, we try to keep each part as independent as possible.