Reading Old Java Books So You Don’t Have To (But You Should)

While I was studying Java Spring Boot, ofc documentation is great. There's a whole set of 900+ pages PDF available by the Spring project itself as a guide and reference, which is great. But idk how relevant it is to learn old stuff sometimes, just to view the world those authors did while writing, let's say, a decade ago. I'm talking about the book I recently read Servlets and JavaServer Pages: The J2EE™ Technology Web Tier by Jayson Falkner and Kevin Jones and it blew my mind. Book published back in 2003, literally the year I was born, and viewing it from that POV feels fresh to me (I think I have a bit of autism here, like fresh and talking about 2 decades ago). But isn't it crazy that Java wasn't originally Oracle's property until 2010 and it was owned by Sun Microsystems?

In my recent interview for software, I was asked questions on HTTP versions like HTTP/1.0 and HTTP/2.0, and I thought that time, even though I read a lot of articles what was before this? Crazy because I had no time in the interview and I was thinking this. But yes, after the interview, I forgot, and this book made me closer to that question.

Right now, at least the time I'm writing this blog or piece of something, we are using Tomcat 11.x. Java 24 was recently released too, but the book talked about JSP (JavaServer Pages) 2.0, Servlets 2.4, and J2EE and J2SE. Idk which age group is reading this right now, but I was amazed by it, cuz if it's experienced devs, I think it's so cool to work on something which wasn’t even public that time. Whatever I'm going to cover here is basically a very abstracted way of the concepts, not too in-depth, and more like fun facts to know about WWW before my generation was born, and ofc not to teach here.

Now as we read this book, I came to know about CGI scripts Common Gateway Interface. Most of them were Perl scripts or compiled binaries executed for every request. My understanding was, as this is a very backend-intensive script, since we focused on dynamic servers, it became very heavy and later it lacked any real scalability. Every time a user loaded a page, the web server had a whole new process. After this CGI, Servlets came into picture. So now Servlets would create a few threads and reuse them, making the request handling faster. I'd say it was a great leap, as we know how fast we want our websites to load today.

Coming to JSPs now (JavaServer Pages), they allowed developers to embed Java directly into HTML. Now the problem is, Java into HTML looks very messy, you can say similar to XML scripting. Also tools like Ant, which was the dominant build tool before Maven and Gradle. Imagine XML build scripts for every task - clean, compile, jar, and deploy. Everything was like building from scratch.

But why bother reading such old books when the world is talking about AI? Well, uk, the more I study from books and then we code, I realise how we stand on giants (or whatever the quote was). Basically everything, every hard, possible thing is already built, and we are using it. The WAR file, @ServletComponentScan in Spring, why Tomcat is so tightly coupled with Java web apps; Well, that's what makes reading crazy books like this is so much fun.

Now let’s get into some hands-on practices given in the book my favorite part is Tomcat 11. While the book explained Tomcat 5 in full detail with images, I almost couldn’t recognize the Mozilla Firefox browser because it looked so different and hard to use back then.

Tomcat is a robust JSP and Servlet container, with crazy good support for JSP, and it can even act as a standalone server. Usually, when we start a Java server or backend, we get port 8080 as the default. As per the book, they taught how to manually change it to the default HTTP port 80 instead.

While I tried configuring the files myself, I realized there are a lot of files to be wary of including the configuration file called web.xml, which is private from outside visitors and provides space for config info. The most important folder is WEB-INF, and inside that, the web.xml file (exactly named as such) must be placed. This configuration file contains the application’s metadata like the default page, servlets to load, and security restrictions.

Now, you might be wondering where all of this is created. As per the book, I’m creating it under the Tomcat download folder (after it’s extracted from the .jar file taken from the official site). All the work is done inside the webapps directory. The application is loaded using the Catalina command with startup.sh and shutdown.sh, which will run the scripts present in the TOMCAT_HOME/bin directory and perform as the name suggests.

After these settings, you can add the required index.html static files to see the content. Start the server and open it in a browser using: http://127.0.0.1/index (or any other name as per your setup).

Hello World Servlet & Servlet Basics

As we move further, the deployment of a simple *Hello World Servlet was illustrated in the book. I’d like to share the client/server servlet programming part mentioned there.

A servlet request and response is represented by the javax.servlet.ServletRequest and javax.servlet.ServletResponse objects. For HTTP servlets, the corresponding classes are HttpServletRequest and HttpServletResponse.

HttpServletResponse

The first and perhaps most important functionality to discuss is how to send information back to a client. As its name implies, the HttpServletResponse object is responsible for this functionality.

By itself, the HttpServletResponse object only produces an empty HTTP response. Sending back custom content requires using either the getWriter() or getOutputStream() method to obtain an output stream for writing content. These two methods return suitable objects for sending either text or binary content to a client, respectively.

Note: Only one of the two methods may be used with a given HttpServletResponse object. Attempting to call both methods causes an exception to be thrown.

HttpServletRequest

A client’s HTTP request is represented by an HttpServletRequest object. This object is primarily used for getting request headers, parameters, and files or data sent by a client.

However, the Servlet specification enhances this object to also interact with a Web Application. Some of the most helpful features include:

• Session management
• Forwarding of requests between Servlets

Next up is the JSP 2.0 specification. It’s crazy how JSP might not be relevant in today’s modern web development scenario, but given it was released back in 1999, it was mainly focused on dynamic code embedding with static markup.

When a request is sent for the content of a JSP, a container interprets the JSP and executes any embedded code, resulting in a response.

If you’ve studied Java Spring, you’ll know JavaBeans (or just Beans). While these JavaBeans aren’t defined by the JSP specification, JSP did provide support for them. These objects are used on the server side of a web app.

JSP Syntaxes

JSP comes in two different syntaxes:

1. Original / Classic JSP – uses free-form syntax
2. JSP 1.2 and later (JSP Documents) – uses XML-based syntax

Both these syntaxes provide the same functionality and advantages.
So now we know why XML has actually never left us when it comes to Java programming.

Final Thoughts

While I haven’t finished the book yet, I’m yet to discover more of it. It’s full of crazy inventions and hard work all of which made it possible for us to directly call functions today without knowing what’s actually going on underneath.

While I sometimes face problems with Eclipse and IntelliJ, I now feel maybe that’s still better than using Ant and compiling the entire pile over and over again.

Look forward to my next few blogs (or whatever this is — is it an article tho? I’m not sure). Or, if you're lucky (and the algorithm works its magic), maybe you'll get recommended this and I’ll have written something more for everyone to read.

“JSP and Servlets walked so Spring Boot could auto-configure.”