I promised you that I would not bore you with Java Server Pages because that is a technology of the past. Even though it is the past, it is still not history as there are many programs running that still use JSP and contain JSP code.
JSP pages are web pages that contain HTML and Java code mixed. When an HTTP request is served by a JSP page, the servlet container reads the JSP page, executes the Java parts, takes the HTML parts as they are, and in this way, mixing the two together, creates an HTML page that is sent to the browser.
<%@ page language="java"
contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<html>
<body>
<% for( int i = 0 ; i < 5 ; i ++ ){ %>
hallo<br/>
<% } %>
</body>
</html>
The preceding page will create an HTML page that contains the text hallo five times, each in a new line separated by the tag br. Behind the scenes, the servlet container converts the JSP page to a Java servlet, then compiles the servlet using the Java compiler, and then runs the servlet. It does it every time there is some change in the source JSP file; therefore, it is very easy to incrementally craft some simple code using JSP. The code that is generated from the preceding JSP file is 138 lines long (on the Tomcat 8.5.5 version), which is simply long and boring to list here, but the part that may help to understand how the Java file generation works is only a few lines.
Here are the few interesting lines generated from the preceding code:
out.write("
");
out.write("<html>
");
out.write("<body>
");
for( int i = 0 ; i < 5 ; i ++ ){
out.write("
");
out.write(" hallo<br/>
");
}
out.write("
");
out.write("</body>
");
out.write("</html>
");
The JSP compiler moves the inside of the JSP code out and the outside in. In the JSP code, Java is surrounded by HTML, and in the generated servlet Java source, the HTML is surrounded by Java. It is like when you want to mend clothes: the first thing is to turn the dress inside out.
It is not only the Java code that you can mix into HTML in the JSP pages but also the so-called tags. Tags are collected into tag libraries, implemented in Java, and packaged into JAR files, and they should be available on the classpath to be used. The JSP page using the tags from some library should declare the use:
<%@ taglib prefix="c"
uri="http://java.sun.com/jsp/jstl/core" %>
The tags look like HTML tags, but they are processed by the JSP compiler and executed by the code implemented in the taglib library. JSP may also refer to the value of the Java objects that are available in the scope of the JSP. To do this inside the HTML page, the JSP expression language could be used.
JSP was originally created to ease the development of a web application. The main advantage is the fast startup of development. There is no lengthy time for configuration, setup, and so on in the development, and when there is any change in the JSP page, there is no need to compile the whole application again: the servlet container generates the Java code, compiles it to class file, loads the code into memory, and executes. JSP was a competitor of Microsoft ASP pages, which mixed HTML with VisualBasic code.
When the application starts to grow big, using the JSP technology causes more problems than are good. The code that mixes the business logic and the view of the application, how it is rendered in the browser, becomes messy. Developing JSP requires frontend technology knowledge. A Java developer is expected to know some frontend technology but is rarely a design expert and CSS guru. Modern code also contains JavaScript, many times embedded in the HTML page. After all, the big advantage of JSP is that it contains code that runs on the server as well as on the client-side code. The developers follow the paradigm many times, so do not be surprised to see some legacy code that contains Java, HTML, CSS, and JavaScript all mixed in a JSP file. Since Java and JavaScript are syntactically similar sometimes, it is not obvious to see what is executed on the server and what is executed on the client. I have even seen code that created JavaScript code from Java code in a JSP file. That is a total mix of different responsibilities and a mess that is nearly impossible to maintain. This led to the total deprecation of JSP as of today.
To mend the messy situation, there were technologies that advocated the separation of the server code and the client functionality more and more. These technologies include Wicket, Vaadin, JSF, and different Java templating engines, such as Freemarker, Apache Velocity, and Thymeleaf. These latter technologies can also be interesting when you generate textual output from Java even when the code is not web-related at all.
These technologies, with discipline, helped control the development and maintenance costs of moderate and large web projects, but the basic problem of the architecture was still there: no clear separation of concerns.
Today, modern applications implement the code of a web application in separate projects: one for the client, using HTML, CSS and JavaScript, and a separate one to implement server functionality in Java (or in something else, but we focus here on Java). The communication between the two is the REST protocol, which we will cover in the subsequent chapters.